Guide

Agents and tools

Hosts, clients and servers

MCP turns N times M custom adapters into N plus M. A host owns the app, a client talks to one server, and a server exposes tools and data.

81 of 155 · 2 min read

Every AI app that needs GitHub, Slack, Postgres and an internal billing API used to grow a custom integration per host. Five hosts times twenty systems is a hundred one-off adapters. That is the N×M problem. The Model Context Protocol (MCP) turns it into N + M: you write a server once; any compatible host can connect as a client.

Think of it as USB-C for model capabilities. The analogy breaks on security: a shared plug shape does not decide who is allowed to plug in.

Concept

Before you start: tool use is the model emitting a call that your process runs. MCP does not replace that loop. It standardizes how tools and data are discovered and invoked across apps.

The big idea

Three roles, one connection each:

  • Host — the app the user runs (an IDE, a chat product, an agent runtime). It owns UX, model choice, policy and which servers are allowed.
  • Client — a connector inside the host. Typically one client per server connection.
  • Server — a process that exposes capabilities: tools to invoke, resources to read, prompts to insert.

A host may attach many servers at once. The model sees a merged tool list unless the host filters. Duplicate names and vague descriptions still cause wrong calls; that is a product problem, not a protocol one.

Walking through a connect

When a user enables a server, the host does this:

  1. Start the transport (spawn a local process, or open an HTTP session).
  2. Negotiate protocol version and capabilities.
  3. List tools, resources and prompts. The host may filter by an allowlist.
  4. On each model turn, merge the allowed tool schemas into the request.
  5. When the model calls a tool, route to the right client and tools/call.
  6. Append the result as a tool result for the next model call.

tools/list should be fast. A two-second list makes every host feel broken on connect. Cache discovery metadata; do heavy work only on tools/call.

Example

A platform team published one MCP server for "customer 360" (subscription, last invoices, open tickets). Support's chat app, the IDE assistant and an ops agent all connected. Three consumers, one auth path and one audit log, instead of three REST wrappers.

Common mistakes

  • Treating MCP as a new kind of tool loop. The model still sees schemas and emits calls. Your process still executes them.
  • Merging every server with no filter. The model then chooses from a kitchen-sink list. Filter in the host.
  • A slow tools/list. Hosts call it on connect. Cache it.

Check yourself

  • Five hosts and twenty systems: how many adapters without MCP, and with it? A hundred custom adapters versus twenty-five (twenty servers plus five host clients).
  • Who decides which servers the model may use? The host. The server only exposes capabilities.

Key takeaways

  • MCP solves N×M by making each system a server that many hosts can reuse.
  • Hosts own policy. Clients connect one-to-one to servers. Servers expose capabilities.
  • Listing tools must be cheap. Doing the work happens on tools/call.

Further learning

Next, see the three things a server can expose in tools, resources and prompts.

Model Context Protocol (MCP)

The open standard for connecting models to tools and data: architecture, primitives, transports and security.

Tools, resources and prompts

MCP servers expose three primitives: tools the model calls, resources the app can read, and prompt templates the user can insert.

Tool use and function calling

Letting models call your code: tool schemas, the tool loop, and designing tools models use well.