Model Context Protocol
Put an approval gate in front of your MCP server
An MCP server describes its own capabilities, so connecting one imports every tool it exposes along with the argument schemas it declares. It is the least configuration of any connection: a URL, and a token if the server wants one.
What you get
MCP server capabilities, under your rules
- ✓ Tools, arguments and descriptions preserved
- ✓ Re-sync when the server changes
- ✓ Streamable HTTP transport
- ✓ An operation type inferred from each tool’s name and hints, erring towards caution
- ✓ An unrecognised verb is treated as an action rather than a read
- ✓ Correct a tool’s risk on the tools page
What you need to connect it
- Server URL — the MCP endpoint, usually ending in /mcp
- Bearer token, if the server is authenticated
- Additional headers, such as a tenant or workspace id
Discovered tools
What a MCP server connection turns into
discovery · MCP server
ready- search_tickets read
- create_ticket create
- refund_payment execute Approval
- delete_ticket delete Approval
Illustrative. MCP does not say how dangerous a tool is, so an unrecognised verb like “refund” is treated as an action — riskier, and caught by an approval rule.
Human approval
Destructive work waits for a person
approval
waiting- Tool
- delete_ticket
- Operation
- DELETE
- Runs against
- Helpdesk MCP
- Agent
- Support Agent
Exactly these values
{
"ticket_id": "T-2048"
}
Your decision applies to these values only. If anything about the call changes, it stops for approval again.
The approval covers this call with these arguments. If the model re-plans, it has to ask again.
Connect MCP server to your first agent
Connect one system and read the agent Caterfli writes from it. There is a demo connection too, if you would rather look before you wire anything up.