Model Context Protocol(MCP)

1. 1

   Expose capabilities as a server

   Define each tool with a name, a description the model reads, an inputSchema (JSON Schema 2020-12) and optionally an outputSchema; add resources by URI and prompts if useful. Keep tools narrow and purpose-built.

2. 2

   The client discovers them

   The host may call server/discover for supported versions and capabilities, then tools/list. The tool definitions are handed to the model as functions it can choose.

3. 3

   The model picks a tool

   When the model emits a provider-specific tool call, the host maps it to tools/call on the server that advertised that tool, with the arguments the model produced.

4. 4

   The server executes and answers

   Results come back as content (text, images, resource links) plus structuredContent matching the output schema. Business failures return isError: true so the model can recover; malformed requests return JSON-RPC errors such as -32602.

5. 5

   Authorise and contain every call

   Authenticate each request (an OAuth bearer token over HTTP), scope tools to the caller, bind customer data to the verified WhatsApp ID, ask a human to confirm sensitive actions, and log every call.

6. 6

   Carry state in explicit handles

   With no protocol sessions, a server that needs continuity — a cart, a draft booking — returns a handle such as basket_id that the model passes into later calls.

Wire format

JSON-RPC 2.0

Transports

stdio (local) · Streamable HTTP (remote)

Current revision

2026-07-28 — stateless, no initialize handshake

Server capabilities

Tools, resources, prompts

Tool names (recommended)

1–128 characters: letters, digits, _ - .

Stewardship

Agentic AI Foundation (Linux Foundation) since December 2025

Without a standard, every AI feature rebuilds the same integrations in a provider-specific format: one wrapper for the WhatsApp bot's model, another for the inbox assistant, a third for the next vendor you try. MCP turns your order system, catalogue and CRM into servers with typed tool definitions that any compatible host can use, so a schema change or a new courier API is fixed in one place. For security reviews it also gives one choke point where authorization, input validation, rate limits and audit logs apply to every AI client.

• Exposing broad, powerful tools

  A run_sql or call_any_api tool hands the model your whole backend. Offer narrow tools with strict schemas and least-privilege credentials behind them.

• Trusting what comes back

  Tool results and descriptions from untrusted servers can carry instructions — a product review that says "ignore your rules". Treat them as data, sanitise outputs and keep guardrails outside the model.

• No per-customer authorisation

  If the server accepts any order ID, the agent can be talked into fetching another customer's order. Pass the WhatsApp ID from the verified webhook and check ownership on every call.

• Building on handshake-era assumptions

  Code written for earlier revisions may rely on initialize and session IDs. Since 2026-07-28 requests are self-contained; use explicit handles for state and the backward-compatibility rules for older peers.

• Using MCP where a function will do

  One app, one model and three internal tools may not need a protocol layer. Plain tool calling is simpler until the same tools must serve several clients.

• Prefix tool names by domain (orders.get_status) when several servers feed one agent, to avoid collisions.
• Write tool descriptions for the model: when to use it, when not to, and what each argument means.
• Return tool execution errors with a clear fix ("order not found on this account") so the model can recover.
• Require human confirmation for refunds, cancellations and anything that moves money.