MCP servers

The Model Context Protocol is how a system describes its tools to a model. If the software you want an agent to reach already speaks MCP - or you can put a small MCP server in front of it - that is the shortest path from your systems to a conversation, and it is the one the rest of the industry has converged on.

A tool of kind MCP calls one tool on one server. Add several to give an agent several.

Connecting one

1. Under Tools, create a tool and choose MCP.
2. Paste the server URL and press Discover. The server must speak MCP's streamable HTTP transport.
3. Pick a tool from the list. Its name, description, argument schema and argument mapping are all filled in from what the server published.
4. Check the argument mapping (see Arguments below), then add the tool to your agent.

If the server needs authentication, put it in the headers field before pressing Discover; the same headers are sent on discovery and on every later call.

Arguments

The arguments field maps what the server expects to what the model fills in:

{
  "order_id": "{{order_id}}"
}

{{order_id}} is replaced with the model's argument of that name at call time. Discovery writes this mapping for you, one "{{field}}" entry per field in the server's schema. Two consequences worth checking before you save:

• Every mapped argument reaches the server as a string. A placeholder is always replaced with text, so a field the server declares as a number, boolean or array receives "3" rather than 3. If the server validates types strictly, replace that entry with a fixed value of the right type or adjust the server to accept strings.
• An optional field the model left out arrives as an empty string, not as a missing field. If the server treats "" differently from "not sent", remove that entry from the mapping.

You can also pin a value by typing it directly instead of a placeholder: "region": "eu" is sent as is on every call, whatever the model supplies. Remove the field from the tool's parameters too, so the model is not asked for it.

What comes back

The model is given the text of the server's result. Other content types in the result (images, embedded resources) are dropped. If the server reports the call as an error, the model is told the tool failed.

A call that takes longer than 30 seconds is abandoned and reported to the model as a failure; the conversation carries on.

What is allowed to be reached

An MCP server URL is treated like any other outbound target: it is resolved and checked before the connection, and the connection is pinned to the address that was checked. Redirects are followed, and each hop is checked the same way. Private, loopback, link-local and cloud-metadata addresses are refused, so a server URL cannot be pointed at something inside the network boundary. An operator can allowlist a specific internal host if you genuinely run one.

See Tools for how tools are attached to an agent and how failures reach the model.