AdministrationTalon Studio v1.0.2-beta
MCP Actions
The human approval queue for MCP write actions an agent wants to take — read the exact call, then execute or reject it.
What it is
The Actions tab of Settings → MCP (/settings/mcp?tab=actions, admin only) is the review queue for MCP tool calls that change state — sending a message, opening an issue, writing to another system. Read tools run inline and just return data; anything classified as an action is captured here as a proposal first. The Servers tab, where you register the servers those tools come from, is covered in MCP Servers.
The approval flow
1
Propose. An agent calls an enabled action tool on a server whose access is Read + propose actions. Instead of running, the call is stored as a pending proposal — the server, the tool, a snapshot of the arguments and who asked — and the agent is told it is queued for human review. Talon sends an "MCP action awaiting approval" System notice to Slack or Teams destinations that have System notices switched on; none do by default, so add it to one you watch.
2
Review. Each proposal shows the MCP server, the tool, its status, who requested it, when, and the full JSON arguments.
3
Decide. Execute re-checks that the server still exists and is enabled, still allows proposed actions, and still has the tool enabled as an action; then it resolves the server's credential on the server side, runs the tool and stores the first 500 characters of the result. Reject marks it rejected; it never runs.
Execute isn't one-shot
An MCP call runs under a 20-second timeout. If it fails — the server is unreachable, say — the proposal stays pending with a "Failed: …" summary (secret-redacted, at most 500 characters), so you can retry Execute or Reject it later. If an admin has since disabled the server, lowered its access or switched the tool off, Execute is refused and the proposal also stays pending.
Reviewing actions
The queue opens on Pending. Executed and Rejected proposals stay listed, with an executed call's result summary; they aren't deleted.
Proposals carry a frozen snapshot of the arguments — executing runs exactly what you see, even if the agent's run has since moved on.
An org-wide server's actions can be proposed by any agent allowed to use it; a server scoped to one workspace only by that workspace's agents.
Tip
Read the arguments before executing, not just the tool name — the proposal is the exact call that will run with real credentials. If anything looks off, reject it and let the agent propose again; there's no undo once an outbound action has fired.