AdministrationTalon Studio v1.0.2-beta

MCP Servers

Connect Model Context Protocol servers so Talon Claw agents can use their tools — default-deny, with write actions held for human approval — and expose Talon itself as an MCP server.

What MCP adds

MCP works in two directions in Talon Studio. Talon as host: it connects out to MCP servers you register so Talon Claw agents can use their tools beside the built-in ones, whatever AI provider you use. Talon as server: your own MCP client can connect in to /api/v1/mcp and use Talon's tools.

Register and govern servers on Settings → MCP (/settings/mcp, admin only), which has a Servers tab and an Actions tab. The old /settings/mcp-servers and /settings/mcp-actions addresses redirect there.

Read tools run when an agent calls them and return data to it.

Action tools never auto-execute — calling one queues the exact call for a human to approve.

Connecting external servers works on the Community Edition. Serving Talon's own tools at /api/v1/mcp needs an Enterprise key.

Registering a server

On the Servers tab, click Add server for your own, or Add built-in for a preset: GitHub (its hosted server at https://api.githubcopilot.com/mcp/), or self-hosted Splunk, Elastic, Microsoft Sentinel, GitLab, Grafana or Sentry servers, where you supply the URL.

Give it a Name, choose the Transport — Streamable HTTP (the default) or SSE (legacy) — and enter the Server URL and, if the server needs one, a Bearer token.

Run Test to connect and discover the server's tools. Expand the row to switch each tool on and classify it as Read or Action.

Edit the server to set its Agent access, and optionally Restrict to specific agents. Then switch the server Enabled.

Secure by default

A newly registered server — preset or custom — starts disabled with agent access off, and every tool it reports arrives switched off. No agent can touch its tools until you enable the server, the access level and each tool.

Agent access has three levels: Off (agents can't use the server), Read (enabled read tools only) and Read + propose actions (read tools, plus proposing action tools for approval).

Newly discovered tools are classified Action — the stricter envelope — until an admin reclassifies one as Read. Running Test again refreshes the list and drops tools the server no longer offers.

The bearer token is encrypted at rest, resolved on the server at call time, and never returned to a browser or shown to the model.

The server URL must be http(s) and passes the same private-address check as a custom AI provider endpoint: in production a private or local address is refused unless TALON_ALLOW_PRIVATE_AI_BASE_URLS=true.

A server added from this page is org-wide: any agent may use it, subject to the agent allow-list.

Every read call is re-checked at the moment it runs — server enabled, access level, agent allow-list, tool enabled and classified Read — times out after 20 seconds, and returns at most 60,000 characters, handed to the model as untrusted data. Each call is logged as a tool-call line in App Logs.

Talon offers MCP tools only in sessions whose role can edit — analyst and above.

Settings → MCP → Servers

A registered server expanded — the Enabled switch, and each discovered tool with its Read / Action classification and its own allow switch. Agent access (Off / Read / Read + propose actions) is set from the server's edit dialog.

Human-approved actions

MCP is zero-trust by design. Read tools return data, but any tool classified Action can only be proposed, and only on a server whose access is Read + propose actions.

Nothing runs without a human

Action tools never auto-execute. They queue the exact call, which an admin must approve before Talon runs the underlying MCP tool — so an agent can propose a change, but only a person authorises it. The queue is the Actions tab; see MCP Actions.

Talon as an MCP server

Point any MCP client at https://<your-instance>/api/v1/mcp with an API token as its bearer credential; the Auth tab of Settings → API shows the URL with a copy button. It speaks stateless Streamable HTTP: every request re-authenticates the token and rebuilds the tool list from the token's current scopes, so a tool appears only when the token holds its scope. It needs an Enterprise key; without one every request is refused with 403.

Read tools

33 tools across the read scopes — among them me, list_workspaces, list_detections, get_detection, get_coverage, list_technique_gaps, list_adversaries, get_navigator_layer, list_change_requests, list_alerts, list_cases, list_deployment_targets, get_deployment_state, list_agent_runs, get_license, list_blueprints, get_validation_summary and list_search_sources, plus list_audit_logs (audit:read) and list_users (users:read). The tools behind view scopes are annotated read-only for clients.

execute_search

search:execute. Runs a governed federated log search.

propose_detection

detections:propose. Stages a draft change request from Sigma or SPL; a Personal token only.

dismiss_alert

alerts:write.

promote_alert_to_case

cases:write.

create_kanban_card

kanban:write.

With a Personal token, every tool beyond the view scopes needs the token's owner to hold at least engineer on the workspace it touches. None of the tools writes to git or deploys. The API reference has the request details.