Tools and MCP

Tools are how agents act on your workspace: query data, edit workflows, search the Knowledge Graph, run canvas changes, call external systems, and complete governed procedures. Fontana exposes one unified catalog of built-in capabilities and Model Context Protocol (MCP) integrations. You assign tools per agent in AI → Agents; the model never receives open-ended access to your estate. Every invocation is audited for compliance review.

MCP

Use MCP to access external data sources, perform financial data lookups, or communicate directly with your firm's tooling.

What is MCP?

An open protocol for connecting AI applications to data sources, tools, and workflows (modelcontextprotocol.io). In Fontana, agents invoke allowlisted MCP tools over HTTP or SSE. Hosted OAuth completes in the browser; bearer tokens and client credentials stay write-only in Vault. MCP connects agents to tools and context; peer-agent delegation is Agent Interop, a separate integration model.

Built-in tools

Built-in tools run server-side inside your workspace. They do not require an external MCP server. You allowlist them per agent; Fontana executes them on the server and returns results into the same chat thread.

Typical built-in capabilities include:

Area	What agents can do
Workflows and data	List resources, query workflow configuration, inspect run datasets, start workflow runs, and list, get, or update Exception Management tickets and setup (workflow_listExceptions, workflow_getException, workflow_updateException, workflow_getExceptionManagement, workflow_updateExceptionManagement)
Knowledge Graph	Search governed corpora, fetch documents by slug, and manage agent memory where permitted
Canvas	Query and mutate workflow graphs (nodes, edges, ports, and canvas config) through typed canvas tools, often via Skills playbooks
Documents	Create, read, update, and rename workflow documents (specs, design notes, reports) tied to a workflow
Chat orchestration	Ask humans structured questions (Human in the Loop), show a clickable Open link for a Flow path or web URL (this does not browse live pages; use Fontana Browser for that), manage task lists, compact thread context into a summary (or omit a labeled order range), delegate to sub-agents, and hand off threads
Skills runtime	Activate and close skill sessions and read bundled skill files (activate_skill, close_skill, read_skill_file)
VFS file tools	Read and search the source file itself, not derived Knowledge Graph retrieval: vfs_file_info, vfs_read (ranged for large files), vfs_grep, and the opt-in vfs_update
Email	Operator-created agents with Communication Receive Email / Send Email on can list, search, read, draft, and send from a tenant mailbox. Send is whitelist-only and fail-closed. See Agent email
Public web (Fontana Browser)	Browse live pages through Fontana Browser tools you assign on the agent. Each session starts on demand in an isolated environment and is deleted when the agent releases it (from this thread or another). You see a screenshot under each browser tool call in chat, and a Fontana Browser preview in the Agents chat right column. Maximize expands that preview over the chat content area. The title bar shows the live page URL. Close releases the session. Take control lets you drive the session; Resume agent hands it back. If a page is still loading or no session slot is free, the agent waits and retries instead of stopping on the first busy signal. Chat completions use your approved gateway only; they do not attach a hosted search plugin

Built-in tools are the default surface for day-to-day Flow work. Prefer them when the capability already exists in Fontana so execution stays in-tenant, audited, and aligned with RBAC.

Fontana Browser sessions

A Fontana Browser session is created when the agent starts browsing and torn down when it releases the session. One person can hold one active session at a time. If the shared session capacity is full, or a page has not finished loading, the agent uses the wait tool, then retries. Close on the preview, or Release from any of your threads, frees that session so a new one can start.

When thread history is compacted, you see a dashed Content above has been compacted boundary with an expandable summary at the point the summary covers. The compaction itself appears where it runs, as an ordinary tool row you can expand: it reads Compacting thread context while passes run and Compacted thread context when it finishes, and expanding it shows why compaction was triggered, what each pass covered, and the token count before and after. Fontana also auto-compacts the oldest prefix when estimated tokens would exceed the agent or model limit, before the next model call. Chat agents have chat_compactThreadContext so they can compact a labeled [order=N] range themselves.

When an agent launches several built-in or MCP tools in the same turn, each call has a bounded wait. If one call stalls or fails, Fontana records a clear error for that call and the thread leaves the analysing state instead of waiting on the rest of the batch forever. You can stop one pending tool from its row in the chat transcript. Fontana records a cancelled result for that call and continues the thread. The whole-run Stop control remains a separate action.

VFS file tools versus Knowledge Graph retrieval

vfs_file_info, vfs_read, vfs_grep, and vfs_update give an agent verbatim access to a source file on the unified workspace filesystem, for example filling in a template, reading a config file exactly as written, or grepping a large CSV, none of which need the derived graph. They are scope-aware (knowledge-graph or skills) and independent of Knowledge Graph retrieval. Reads stay query-shaped rather than unbounded dumps: small files return bounded, token-capped content, large files use ranged byte or line windows, and binary files return metadata with a typed refusal instead of raw bytes. vfs_update writes a new file version (full replace or targeted string replacement) and is never bundled into a wildcard tool default; you enable it explicitly per agent, and every write is RBAC-checked and versioned through the same audit trail as manual edits. Use Knowledge Graph retrieval instead when you want hybrid search, outline navigation, or entity navigation over the derived graph rather than the file’s exact bytes.

MCP connections

Use MCP when an agent must reach an external system you operate: SaaS APIs, databases, search services, calculators, or firm-specific HTTP tool servers.

In AI → Tools, you register MCP connections (HTTP or SSE transport), test connectivity, and refresh the discovered tool list. Add new MCP starts from one connection object (name, type, url). You can paste a Cursor mcpServers (or servers) catalog and Fontana splits it into individual connections. Edit stays one MCP. Approved tools appear in the agent catalog under namespaced ids (mcp_<connectionSlug>_<toolName>). You can assign individual tools or a connection wildcard (mcp_<connectionSlug>.*) that expands against the cached snapshot at runtime.

You can also ask Fontana Agent (or Tools Agent on /ai/tools) to add, update, test, or remove MCP connections. Those built-in calls are tools_listMcpConnections, tools_getMcpConnection, tools_upsertMcpConnection, tools_deleteMcpConnection, tools_testMcpConnection, tools_importMcpConnections, tools_listMcpConnectionAgents, and tools_setMcpConnectionForAgent. They require agents:read / agents:write, return public connection fields only (no bearer tokens), and cannot finish hosted OAuth: create the OAuth connection, then Connect in the browser on AI → Tools.

On AI → Tools, each MCP card has an Agents column beside the discovered tools. You select or unselect agents there; that writes mcp_<slug>.* on the agent’s AGENT.md tools list, the same persist as the extra MCP tiles on the agent card. Seeded Knowledge and Coding connections stay on their dedicated agent-card tiles. Channels is assigned from the Communication Messaging toggle. You can still assign any of these from the Tools column.

Topic	What you should know
Authentication	Bearer tokens and OAuth app credentials (including BYOK Client ID/Secret) are stored write-only in Vault and used only during discovery and execution
OAuth providers	Hosted flows (for example Notion-style MCP URLs) use browser OAuth with PKCE; redirect URIs are shown in the admin UI
Discovery	Fontana-seeded connections (Knowledge Graph, Fontana Files, Fontana Browser, OpenSandbox, Channels) refresh their tool catalogs when you apply a Fontana version. Connections you add yourself refresh when you test them on AI → Tools; assign those tools after a successful refresh
Transport	Remote HTTP/SSE only; local stdio MCP servers are not supported from hosted agents
Governance	Agent assignment is the approval boundary in V1; unassigned MCP tools are not callable

For external systems, Fontana acts as an MCP client: your agents call tools on servers you register. Fontana also ships first-party Knowledge Graph and Fontana Files MCP servers on your tenant origin so agents and approved external clients can reach namespace-scoped graph evidence and git-backed Collections. See Knowledge Graph → MCP and Fontana Files → MCP for tool catalogs, ACL rules, and external client setup.

When you open AI → Tools with nothing selected, you see a welcome landing. Select Knowledge Graph or Fontana Files to copy the public Streamable HTTP URL and Authorization: Bearer header for ChatGPT, Claude, Cursor, and other clients.

Configure tools for agents

Tool governance spans three admin surfaces that work together:

1. AI → Tools - register MCP connections, inspect schemas, refresh discovery, manage credentials, and assign the connection to agents from the inverse Agents column
2. AI → Agents - allowlist built-in and MCP tools for each persona. Each extra MCP connection you add appears as a Tools tile on the agent card, including connections whose last test failed or that have no discovered tools yet (Knowledge and Coding keep their dedicated tiles; Channels, Fontana Browser, and Human in the loop live on Communication). Advanced view still lists every tool and wildcard. Assign Skills packages on the same card
3. Skills (sidebar) - author and upload skill folders; each package can declare allowed-tools that expand only while a skill session is active

Skills can union additional tools for the duration of an active playbook without permanently widening an agent’s baseline allowlist.

OpenSandbox (isolated code execution)

When agents need to run commands, scripts, or exploratory code safely, OpenSandbox provides isolated execution as a shared platform service. Each workspace reaches OpenSandbox through a single shared MCP connection seeded at deploy time; sandboxes are ephemeral, TTL-bound, and scoped with per-workspace bearer authentication.

What is OpenSandbox?

Shared platform-cluster service for isolated agent code execution. Agents reach it via MCP; each workspace uses its own bearer token; sandboxes are ephemeral pods with no cross-tenant persistence.

Agent (MCP) → OpenSandbox platform → Ephemeral sandbox pod

Exploratory compute stays separated from your tenant data plane while remaining available to allowlisted agents through the same audited tool pipeline as other MCP calls.

Audit and review

Every built-in and MCP tool invocation writes to tool-call audit records with protocol metadata, latency, and outcomes. Operators with appropriate permissions can review agent tool usage in Flow admin surfaces and correlate activity with the immutable audit trail where your deployment enables it. See Observability, Compliance evidence, and Security (OpenSandbox controls in Workspace isolation).

Tools, MCP, and Agent Interop

Integration	Connects agents to	Configure in
Built-in tools	Fontana workflows, data, canvas, Knowledge Graph, chat orchestration	Admin → Agents (plus Skills for temporary expansion)
MCP	External tool and context servers (HTTP/SSE)	Admin → Tools + Admin → Agents
Agent Interop	Peer agents on other platforms (A2A, ACP, and related protocols)	Admin → Agent Interop

Do not confuse MCP tool servers with peer-agent federation. For delegation and handoff between agents, see Agent Interop.