What the MCP server exposes

The tool catalog is capability-gated: a client is offered exactly the tools its token's operations unlock, and nothing else appears in the list.

Orient and read

Unlocked by the read operation, except effective_scope, which is always offered because a client that cannot ask what it holds is a client that guesses.

• effective_scope — what this session actually holds. Requires no operation.
• status, read_file, list_conflicts, log, diff
• symbol_context, symbol_relations, search_symbols, change_impact — the semantic layer, scope-pruned by the engine.
• project_context — a merged pre-write briefing for a set of paths: relevant symbols, matching conventions, and any overlapping peer intents. Worth having an agent call before it starts editing.
• provenance_graph — the derivation graph for a change, task or session handle. The MCP sibling of tovio audit graph.

Write and land

write_file, delete_file, move_file, resolve_conflict, commit. Writes stage into a per-session in-memory change and land on the agent's own agent/<name> lane, with provenance computed server-side. Protected content is sealed only inside the engine's commit path — the MCP layer never touches crypto.

Delegate

issue_sub_token, monotonically narrower, and offered only when the token carries both the delegation flag and the sub-token:issue operation.

Absent by construction

Obliterate, policy modification, key management, and tag force-repoint. Not permission-gated — not present. There is no token that unlocks them, because the tools do not exist on this surface. Unconstrained token issuance is absent too: the only delegation path is issue_sub_token, and it can never mint authority from nothing.

That is the design. Operations that are irreversible, or that change the security model itself, stay human.

Enforcement does not live here

Every tool call re-presents the session token to the engine and re-runs the whole check — validity and chain, scope, operation, then policy. The MCP layer owns no version-control logic and no crypto; it is a thin edge over an engine that assumes nothing about it.

Tool catalog provenance

The catalog is hashed canonically under a versioned encoding, and that hash is bound into the provenance of every commit the session makes. What an agent was offered is recorded, not assumed — so "the tool must have been there" is a checkable claim rather than an argument. The encoding version is bumped deliberately, because bumping it changes every subsequently recorded hash.