For coding agents

Set up CortexDB

One machine-readable manifest, one supported release profile, one safe first-value path. Your agent should not have to guess a package name, a version, an endpoint, or whether a command is safe to run.

Paste this into your coding agent

Set up CortexDB for this project using the official CortexDB agent instructions.

1. Fetch https://cortexdb.ai/agent/manifest.json and https://cortexdb.ai/agent/SKILL.md, and follow the Skill.
2. Ask me which use case I want before choosing anything: coding memory, semantic search, application memory, or a source integration.
3. Use the hosted evaluation profile first. It is anonymous and low-quota.
4. Install only the package names the manifest lists as canonical.
5. Show me a plan and wait for my approval before anything the manifest marks as an approval gate.
6. Finish by writing one synthetic memory, recalling it, verifying it, and cleaning it up. Report the exact versions you installed and anything the manifest marks not_tested or blocked.

What the agent reads

/agent/manifest.json — versions, package identity, capability states, error contract, limits.
/agent/SKILL.md — the procedure, as plain markdown.
/llms.txt — the discovery pointer, mirrored at /.well-known/llms.txt.

Generated 2026-08-22T05:45:39+00:00 from release snapshot sha256:bebd1f6ab85b3c71…

Known-broken published artifact

These are what the registries serve right now. Do not install them as-is — the manifest carries the same warning so your agent sees it too.

cortexdb-mcp 0.6.1 — The published 0.6.1 declares an unbounded `mcp>=1.0`. Upstream mcp 2.0.0 removed `mcp.server.fastmcp`, so a fresh install resolves to 2.x and crashes with ModuleNotFoundError at import time — before main() runs and before any network call. Workaround: pip install "mcp>=1.0,<2.0" alongside it. Fixed in 0.7.1 (unreleased).

Supported profiles

A profile marked not_tested or blocked has not been proven — we say so rather than letting an agent infer that it works.

hosted_evaluationtestedstart here

Anonymous, low-quota, TTL-bound identity from /v1/auth/signup. The correct starting point for every agent-driven install.

hosted_productionnot_testedrequires human approval

Production authority, billing and ownership. An agent must never assign this to an identity it created itself.

No clean-agent matrix has been run against a frozen hosted profile.

self_hostedblockedrequires human approval

Operator-run server from the published image.

No isolated Docker execution environment has been restored since Phase 0.

connectorsnot_testedrequires human approval

Third-party source sync. Each connector carries its own readiness verdict; hosted results say nothing about them.

Per-connector readiness verdicts do not exist yet.

Approval checkpoints

The agent must stop and ask you before any of these. Least privilege is the default, and elevation is never silent.

production_credentials
Using or minting credentials with production authority.
billing
Anything that creates a charge or changes a plan.
external_oauth
Authorizing against a third-party system.
expanded_scopes
Requesting capabilities beyond the least-privilege default.
destructive_actions
Any forget/erasure outside the agent's own verify subtree.
ownership_transfer
Claiming or reassigning an identity to a real owner.
self_hosting
Standing up a server the user will have to operate.

Least-privilege recall

View	Anonymous	Requires	Notes
raw	yes	—	Layer arrays, no composed context block.
granular	yes	—	Per-event hits. The least-privilege default for verification.
holistic	no	scope.read.holistic	Synthesised context block across layers.
structured	no	scope.read.holistic	Structured synthesis over the pack.

A 403 naming scope.read.holistic is a documented capability boundary, not an outage. Agents should use raw or granular to verify.

Prefer to do it yourself?

The CLI is the same actuator the agent drives: apply, cleanup, doctor, plan, preflight, resume, status, verify. Or start at the quickstart.