Skip to content

Lab

Agents call tools. Someone should check.

Step through how an AI agent discovers and calls tools with the Model Context Protocol, and see what a gateway adds between the client and remote MCP servers.

Illustrative messages. The JSON-RPC follows the shape of the MCP specification, but the servers, tools, tokens and timings are invented examples and nothing calls a real server.

Choose a task

The client talks to every server directly.

Signed in

Sam, support agent. Token scopes: orders:readincidents:read

Tools the model can see (6)

  • Orders serverremote, HTTP
    • get_order_status
    • refund_order
  • Incidents serverremote, HTTP
    • list_incidents
    • restart_service
  • Marketing CRM serverremote, HTTP
    • export_contacts
  • Local notes serverlocal, stdio
    • search_notes

Step 1 of 8

You ask the host app

You type into the host app: a chat app, IDE or agent. The host runs the model and holds one MCP client connection per server it is configured to use.

You → Host app · User message
Refund order 1042

Central audit log

None. Each remote server keeps its own logs, if it keeps any, so there is no single record of who called which tool.

Step 1 of 8: You ask the host app.

The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data. Pick a task above and step through what actually travels over the wire, then switch on the gateway and run the same task again.

The moving parts

  • Host: the app you talk to, such as a chat app, an IDE or an agent. It runs the model and decides when to call a tool.
  • Client: a connector inside the host. Each client holds one session with one MCP server.
  • Server: a program that offers tools (actions the model can ask for), resources (data the host can read) and prompts (reusable templates). This explainer focuses on tools.
  • Transport: local servers usually run as a child process and talk over stdio. Remote servers use Streamable HTTP, where each message is an HTTP POST and the server can stream replies back.

What the messages show

  • JSON-RPC 2.0 throughout. Requests carry an id and a method; every response carries the same id and either a result or an error; notifications have no id and get no reply.
  • Initialisation comes first. The client sends initialize with the protocol version it supports and its capabilities, the server answers with its own, and the client confirms with notifications/initialized before anything else.
  • Discovery is dynamic. tools/list returns each tool's name, description and a JSON Schema for its inputs. The model only ever sees what the host passes on.
  • The model never calls a server. It asks the host to run a tool, and the client sends tools/call on its behalf.

Where a gateway fits

Remote MCP servers are APIs, and they need the same controls as any other API. A gateway between the client and those servers gives you one place to:

  • Validate OAuth tokens. MCP's authorisation for remote servers builds on OAuth 2.1. The gateway checks issuer, audience, expiry and scopes on every request, and uses its own credentials upstream instead of passing the user's token through.
  • Filter the catalogue. Only approved servers and approved tools are listed, so the model never learns about the rest.
  • Authorise each tool call. A support agent can look up an order but cannot issue a refund, whatever the model decides.
  • Apply quotas and rate limits per user, per tool or per team.
  • Keep one audit log of who called which tool, with which arguments, and what was allowed or denied.
  • Trace and measure latency, errors and usage across every server.

Some limits are worth knowing. Local stdio servers run beside the host and never pass through a gateway, so they need their own controls. Tool annotations such as "destructive" are hints from the server, not enforcement. And hiding a tool is not the same as authorising it: in this example the refund tool stays listed and is stopped at call time, which some teams prefer so the model can explain why.

The servers, tools, tokens, timings and answers on this page are illustrative. Nothing connects to a real MCP server.

All Lab experiences