Give your agent Torana tools.

Ask your agent how many tokens this chat used, why a plugin withheld a tool result, or what routing mode is active. Torana’s local MCP server gives connected harnesses one interface to the proxy and its plugins.

Traffic plugins act automatically on requests and responses. MCP adds a separate channel: your agent can discover operations and call them explicitly. You do not need MCP to use PII scanning or other traffic hooks.

Connect your harness.

First follow the quickstart so Torana is running and your harness’s model requests pass through it. Enable MCP:

torana mcp enable --yes
torana mcp status

Claude Code

torana harness setup claude-code --yes

Codex

torana harness setup codex --yes

Choose your harness, then restart it to load the connection. Setup defaults to user scope and keeps your harness’s approval and workspace-trust settings unchanged. Add --scope project for a project-local connection or --dry-run to preview the change.

The stdio adapter resolves the running Torana instance and adds authentication itself—no port or token to paste into your harness configuration. Setup records the binary’s absolute path; rerun setup if you move it.

For another MCP client, add a server named torana with command torana (or your binary’s absolute path) and arguments ["mcp", "stdio"]. Torana must already be running with MCP enabled. See the CLI reference ↗ for direct HTTP clients and explicit instance selection.

Try a question in your chat.

The agent can inspect proxy status, aggregate statistics and installed plugin identities. For the current chat, it can read recent request events, recorded usage, suggestions and confirmed-change history. Plugin-specific questions need the corresponding approved, enabled plugin.

Conversation-specific operations need Torana to observe and verify the model’s tool call. Connect both paths: model requests through the proxy, and MCP through the adapter. If you see unbound_conversation, check that routing first; Torana will not guess a conversation from model-supplied IDs.

What the plugins expose.

These are the custom operations in the current official plugin source. Your installed bundle may differ; use discovery to see what is actually callable.

pii

redaction.explain_last

Explain the last fresh replacement in this chat, with categories and relative output lines—not secret values.

pii_guard

redaction.explain_last

Explain the last fresh deterministic replacement in this chat without returning the protected value.

usage_logger

session.usage · status

Read this chat’s recorded token totals, including reported cache usage, or inspect the logging policy.

decision_router

status · conversation.get

Inspect routing readiness and this session’s routing-thread summaries, without exposing prompts or configured model ladders.

compactor

status.get

Inspect configured input limits, expected reuse and policy count. This does not run compaction or test the model.

tool_governor

status · session.allow_tool

Inspect restriction counts or request a confirmed tool allowance for this session. Explicit operator denies still apply; undo stays user-controlled.

otel

status

Inspect plugin identity and metric-emission readiness—not collector delivery or a trace browser.

intent

status

Inspect the intent-field convention and history-fill mode without returning captured intent text.

keyword_compactor

status

Inspect compaction limits and policy count without exposing tool output, patterns or rerun commands.

cache_tier_selector

status

Inspect configured cache-tier mode, idle-gap threshold and retention without changing cache markers.

cache_warmer

status

Inspect configured opt-in count and timing without exposing conversation IDs or sending refresh requests.

Four tools, growing possibilities.

  1. torana_namespaces lists Torana and installed plugin namespaces.
  2. torana_search finds reachable operations by intent.
  3. torana_describe explains inputs and access requirements.
  4. torana_invoke calls a named operation.

For example, the agent can invoke the PII explanation with:

{
  "namespace": "pii",
  "operation": "redaction.explain_last",
  "input": {}
}

Read operations can run directly. Eligible plugin configuration, enable/disable and custom changes require your confirmation. For example, tool_governor.session.allow_tool requests a session allowance for a tool omitted by an allowlist; it cannot override an explicit deny. Changing the model-visible tool list may rebuild its prompt cache.

Torana presents confirmation through supported MCP consent flows or its local controls. If the agent reports pending_confirmation, confirm or decline it in Torana’s UI, CLI or your harness’s consent prompt. The model never receives a code to approve on your behalf.

MCP is intentionally narrower than the operator CLI: it does not return current plugin configuration values or approve arbitrary plugin capabilities. Model-facing changes to pii, pii_guard and auth are blocked by default. A harness with unrestricted shell access can still use the operator CLI; its own permissions remain important.

Build a tool once. Reuse it.

Add agent.json to your plugin with named operations, descriptions, JSON schemas and an access policy. Implement those operations through the SDK’s HTTP hook. Torana discovers and dispatches them in the same WASM runtime—no separate MCP server process for your plugin.

Use model_access: "read" for reads, "confirm" for user-approved changes and "never" for private maintenance. Conversation-scoped operations use a verified host binding. Confirmed changes declare a safe undo companion.

Add plugin operations → · Read a working descriptor ↗

Disconnect when you want.

torana harness teardown claude-code --yes
# Or: torana harness teardown codex --yes
torana mcp disable --yes

Teardown removes the selected harness connection. Disabling MCP closes MCP sessions; it does not stop Torana’s proxy or traffic plugins.