Model Context Protocol (MCP) servers expose tools, resources, and prompts that agents can use. Frona installs them, sandboxes them, and surfaces their tools to your agents, so you can hook up GitHub, Slack, your database, or any of the hundreds of community servers without writing code.

One-click install from the managed registry

Frona ships with a built-in browser for the public MCP registry. Open Settings → MCP, click Install, search by name, and Frona handles the rest:

1. Resolves the server's metadata from the registry.
2. Launches the server in its own per-server sandbox.
3. Handshakes over the chosen transport and agents can access the tools immediately.

The registry index is cached on disk for 24 hours so search is fast and works offline. The result is a sandboxed server tied to your user, ready for agents.

See Installing for the full flow.

Bridge mode

Every conversation is bounded by the model's context window. Tool definitions sit in the system prompt and get re-sent on every turn, so prompt overhead recurs. The standard way to surface MCP tools to an LLM is to advertise each one individually — a single server can publish 20+ schemas, and five servers would burn thousands of tokens before the user has typed a word.

Frona avoids that with bridge mode: it advertises a single tool, a CLI called mcpctl. The agent learns one definition and calls every MCP tool through it:

mcpctl github list_repos --owner octocat
mcpctl slack send_message --channel "#general" --text "hi"

A short <mcpservers> block in the system prompt lists each server with its description and tool count, so the LLM knows what's available. Full schemas are fetched on demand via mcpctl <server> <tool> --help — only for tools the agent actually plans to call. Every bridge call still goes through the policy engine.

Bridge mode is on by default (mcp.bridge_mode: true). See Bridge Mode for the wire-level details and when to turn it off.

Configuration

Each server's detail page lets you configure:

• Environment variables. Plain values for non-sensitive flags.
• Credential bindings. Map env vars to vault items so secrets are pulled fresh on every start and never stored alongside the server config. Three modes — single field, all fields, prefix — see Managing Secrets & API Keys.
• Transport. Pick stdio (default) or streamable-http. See Transports.
• Display name and description. The description is injected into the agent's system prompt so the LLM knows when to call the server's tools.

Server-wide defaults live in mcp.* in the config file: max servers per user, startup timeout, restart attempts, default transport, port range, and the bridge_mode toggle.

Server statuses you'll see on the list:

Status	Meaning
Installed	The package is downloaded but not running
Starting	The process is launching and handshaking
Running	The server is connected and serving tools
Stopped	The server is intentionally not running
Failed	The server crashed or couldn't start. See logs on the detail page.

Sandboxing

Every MCP server is a Policy::Mcp principal in the policy engine and is subject to the same read, write, connect, and bind actions as agents. The server's settings page shows its read/write paths and network destinations with the same UI an agent has.

Common patterns:

• A GitHub MCP server only needs connect to api.github.com:443.
• A Postgres MCP server only needs connect to your database host and port.
• A filesystem MCP server needs read and write on the directories it's meant to manage.

Out of the box, a new server only inherits the platform's managed network access. Tighten further with explicit permit/forbid rules. See Policies for the syntax and Sandbox for the runtime.

Every tool call (in either bridge mode or direct registration) is authorized against the agent's policies. An agent can use an MCP tool only if a policy permits the matching invoke_tool action.

Tips

• Start with one well-known server. GitHub, Slack, or Linear are good first installs to learn the workflow.
• Bind credentials, don't paste them. A vault binding pulls fresh values on every start and survives credential rotation.
• Lock down the sandbox. Pin each server to the one host it actually needs. Cedar's forbid ... unless makes this concise.
• Watch the logs on first start. Most server failures are credential or env-var problems, and the logs say which.
• Leave bridge mode on unless you have a reason to disable it. The token savings on a busy agent are large.

Next steps

• Installing. The full install flow.
• Transports. Stdio vs streamable-http.
• Bridge Mode. What mcpctl is and how it changes the agent's view.
• Policies. How to authorize MCP tool calls and sandbox MCP servers.