MCP

One registry, four agent configs

Every agent CLI has its own idea of where MCP servers are declared and what the entry looks like. TDE keeps a single registry — a SQLite database at ~/.tde/mcp_registry.db — and writes each server out in the four different dialects, so a server you add once is available to whichever agent you happen to be running.

Manage them in Control Center → MCP. The toolbar has three actions: + New, Import and Sync MCP. There is no tde mcp command — the CLI's MCP surface is the servers themselves, not their configuration.

A server entry

Two transports exist.

stdio runs a local process and speaks JSON-RPC over its pipes. You give it a command, arguments and environment pairs.

remote connects to an HTTP URL and you give it header pairs. Both the environment list and the header list are entered in the same KEY=VALUE field, one per line or comma-separated.

{
"mcpServers": {
  "my-tool": {
    "type": "stdio",
    "command": "/usr/local/bin/my-tool",
    "args": ["--serve"],
    "env": { "MY_TOOL_MODE": "readonly" }
  },
  "hosted": {
    "type": "http",
    "url": "https://tools.example.com/mcp",
    "headers": { "Authorization": "Bearer ..." }
  }
}
}

Cursor gets the same JSON minus the type field, which it infers. OpenCode uses its own vocabulary — "type": "local" with the command as a single array, or "type": "remote" — plus an explicit enabled flag. Codex gets a TOML block delimited by # TDE MCP SERVERS START and # TDE MCP SERVERS END markers, so your own hand-written entries above and below survive a sync.

Merge, replace and import

Syncing generic servers merges: TDE inserts and updates the names it owns and never deletes an entry you configured outside TDE. Removing a server from the registry is what removes it from the agent configs, and that is an explicit operation.

Import reads all four config files back and offers the servers it finds, so you can adopt an existing hand-written setup into the registry instead of re-typing it. Entries starting with tde-db- are skipped, and the first occurrence of a name wins.

Lazy schemas for agent CLIs

Tool schemas consume context even when an agent never calls them. When at least three wrapable stdio servers are enabled, TDE collapses them in agent configs into one entry named tde-mcp-lazy. Force the same behavior with TDE_MCP_LAZY=1.

The meta server advertises only three tools:

Remote HTTP servers remain individual entries, and tde-db-* profiles stay on their separate Vault-backed path. Control Center and Inspect still list every upstream; only the generated agent configuration is collapsed.

Drop below the threshold and sync again to restore individual entries, or unset TDE_MCP_LAZY when it was forced. Syncing happens when you save a server, choose Sync MCP, or TDE refreshes its managed configuration.

Database profiles become MCP servers

Every enabled Database profile is materialized as an MCP server automatically. The name is tde-db-p<id> — the numeric profile id, deliberately opaque, so nothing about the database leaks into a config file that an agent reads.

{
"mcpServers": {
  "tde-db-p1": {
    "command": "/opt/tde/current/tde",
    "args": ["database-mcp", "--profile-id", "1"]
  }
}
}

There is no connection string anywhere in that entry. When the agent starts the server, the server opens the registry, reads the profile row, takes the vault entry name from it and resolves the real DSN from ~/.tde/secrets.db — at runtime, in its own process.

Three guarantees follow from the way this is enforced:

• The tde-db- prefix is reserved. Creating your own MCP server under it is rejected.
• If any profile still holds a plaintext connection string, the database sync refuses to write anything at all rather than emitting a half-migrated set. Legacy profiles get the old tde-db-<slug> name and are blocked until migrated.
• The command written is the stable executable path — <install root>/current/tde for a managed install — so agent configs keep working across TDE self-updates.

TDE's own MCP servers

TDE ships five MCP servers as subcommands of the same binary. They are stdio servers: launching one in a shell will look like a hang, because it is waiting for JSON-RPC on stdin.

tde control-mcp

The semantic My Loop API, over the owner-only control socket. Sixteen tools:

Every mutating tool requires a caller-supplied idempotency_key. There is no task_approve and no task_reject — see Security.

tde brain-mcp

Durable memory and the decision graph. Twelve tools: brain_query, brain_read_page, brain_write_page and brain_recent for the wiki; decision_query, decision_get, decision_list_applicable, decision_propose, decision_add_evidence, decision_link_memory, decision_request_approval and decision_events for decision records. There is no tool that accepts a decision. See Brain, decisions and recall.

tde recall-mcp

Two tools scoped to the current working directory's project: recall_search searches indexed code and durable memory, recall_context builds a bounded Markdown context bundle.

tde database-mcp --profile-id <n>

Two tools, profile and query. Described above and in Data apps.

tde graph-mcp

One tool, explore, backed by the structural code graph. Its actions are search, callers, callees, impact, tests, bundle and expand.

What gets registered for you

tde-control is different because it needs the current profile's socket path, which only exists once the Runtime is up. Each ask or chat run upserts it, force-enables it, syncs, and hard-fails if the selected agent's config could not be written — an agent that silently lacked the TDE tools would look like it was working while doing nothing.

Related

• Data apps
• Ask and chat
• System commands
• Security