By default, Frona registers every MCP tool individually with the LLM. With many servers installed, this list grows fast: dozens of tool definitions per agent, costing thousands of tokens before a single message is sent. Bridge mode replaces that with a single CLI tool: mcpctl. The agent learns once how to use the CLI, and from then on calls every MCP tool through it.

Bridge mode is on by default (mcp.bridge_mode: true). You normally don't need to change it.

What changes for the agent

	Without bridge mode	With bridge mode
Tool definitions sent to the LLM	One per MCP tool (mcp__github__create_issue, mcp__github__list_repos, …)	One total: mcpctl
System prompt addition	None	A short MCP.md explainer + <mcpservers> tag listing your installed servers
How the agent invokes a tool	Direct tool call	Shell call: mcpctl github list_repos --owner octocat

The system prompt addition is generated from your installed servers and lists each server's slug, description, and tool count. The agent can then run mcpctl <server> --help to discover individual tools as needed.

How mcpctl works

mcpctl is a small CLI that runs inside the agent's CLI sandbox. It reads two environment variables that Frona injects at process start:

Variable	Value
FRONA_API_URL	Base URL of the engine
FRONA_TOKEN_FILE	Path to a file containing an ephemeral auth token

When the agent runs mcpctl github list_repos --owner octocat, the CLI:

1. Reads the token from FRONA_TOKEN_FILE.
2. Calls GET /api/mcp/bridge/servers/github to fetch the tool list.
3. Validates --owner against the tool's input schema.
4. Calls POST /api/mcp/bridge/github/call/list_repos with the JSON arguments.
5. Prints the result on stdout.

The engine routes the call to the actual MCP server, applies the agent's policies, and returns the result. The agent sees a normal CLI tool result.

Discovery commands

Command	What it shows
mcpctl list	Every MCP server the agent is allowed to call
mcpctl <server> --help	The server's description and its tools
mcpctl <server> <tool> --help	The tool's parameters with types and required flags

The agent uses these on demand, so it only loads schemas for the tools it actually plans to call. This is the main token win.

Authorization

Every bridge call goes through the policy engine just like a normal MCP tool call. The agent must have a permit for invoke_tool on the underlying tool. A tool that the agent isn't allowed to call doesn't appear in mcpctl list for that agent.

When to turn bridge mode off

Switch to direct registration (mcp.bridge_mode: false) when:

• You have only one or two MCP servers and want the LLM to see their tools as first-class definitions.
• You're debugging a specific tool call shape and want to see the exact JSON the model produced.
• You're using a model that performs better with native tool calls than with shell execution.

Otherwise, leave it on.

Tips

• Don't worry about the extra shell hop. mcpctl is a thin client; latency is negligible compared to LLM inference.
• Trust the agent to discover tools. It will run --help when it needs to. You don't have to pre-list everything in the system prompt.
• Sandbox CLI tightly. mcpctl only needs connect to FRONA_API_URL, no other network access.
• Prefer bridge mode for many-server setups. The savings scale linearly with the number of MCP tools you have installed.

Next steps

• MCP. The bigger picture.
• Installing. How to add a server.
• Policies. Authorize bridge calls and limit which tools an agent can use.