MCPmcpprotocolintegrationclient-servertools

MCP Overview

The Model Context Protocol standardises how an AI application discovers and calls external capabilities, turning N × M bespoke integrations into N + M.

▶ InteractiveInterview question
Progress

The integration problem

Before a shared protocol, every AI application (a chat assistant, an IDE agent, an internal support bot) that wanted GitHub, Postgres, Slack and Jira access wrote four bespoke adapters. With N applications and M systems, that is N × M integrations, each with its own schema format, auth handling and error conventions.

MCP separates the two sides. An application implements an MCP client once. A system exposes an MCP server once. Any client can then talk to any server, so the integration count drops to N + M. This is the same economics that made JDBC/ODBC, LSP (Language Server Protocol) and USB worth standardising.

The catch is that protocols only pay off when both sides are numerous. If you have one application and two internal APIs, a direct integration is simpler — see MCP vs Direct Integration vs Function Calling.

  • 3 applications × 5 systems = 15 adapters without a protocol; 3 + 5 = 8 with one, and the marginal cost of a new system is one server, not three adapters.
  • Standardisation covers discovery, invocation, schemas and transport — not the semantics of what a tool does.

Architecture

The host application embeds an MCP client. The client opens a session to one or more servers, asks each what it offers, and forwards the model's tool calls. The server owns the connection to the real system and returns results the client puts back into the model's context.

The LLM never speaks MCP. It sees ordinary tool definitions (JSON schema) that the client derived from the server's tools/list response, and it emits ordinary tool calls that the client translates into tools/call requests.

MCP topology
tool defs + callsJSON-RPCAI application (host)LLMMCP clientMCP serverToolsResourcesPromptsExternal system (GitHub, DB, …)
UserLLMAgentToolDataDecisionHumanGuardrail

What MCP does not solve

MCP standardises plumbing, not judgment. The model still has to pick the right tool among 40 exposed ones, still hallucinates arguments, and still trusts whatever text a server returns — a malicious or compromised server is a prompt-injection channel (Indirect Prompt Injection).

It also does not remove the need for Tool Permissions and Least Privilege. A server that exposes delete_repository next to search_repository hands the model both; the host must decide which to surface and which to gate behind Human-in-the-Loop Overview approval.

  • Every additional server adds tool definitions to the prompt — 10 servers × 15 tools can consume thousands of tokens before the user says anything (Token Budgets).
  • Server output is untrusted content; treat it like a scraped web page, not like your own code.

Key points

  • MCP is a client–server protocol (JSON-RPC) between an AI application and capability providers.
  • It reduces integration count from N × M to N + M, which only matters when N and M are both > 1.
  • Servers expose three primitives: tools, resources, prompts (MCP Primitives: Tools, Resources, Prompts).
  • The LLM sees plain tool definitions; the MCP client does the translation.
  • MCP does not solve tool selection, argument quality, permissions or trust.

MCP walkthrough

MCP walkthrough
An agent uses a GitHub MCP server through an MCP client. Step through initialization, discovery, invocation and the result path.
AI application (agent)MCP clientGitHub MCP serverToolsResourcesPromptsGitHub API
Initialize. The application starts an MCP client and connects to the server (stdio or HTTP). Client and server exchange capabilities: which primitives each supports.
→ initialize { clientInfo, capabilities }
← { serverInfo, capabilities: { tools: {}, resources: {}, prompts: {} } }
Direct API integration
N apps × M systems = N·M integrations. Each app hand-codes auth, schemas, errors.
Function calling
Standard for the model side: schema in, structured call out. Says nothing about how tools are hosted or discovered.
MCP
Standard for the tool side: hosting, discovery, invocation, resources, prompts. N + M integrations; tools reusable across apps.
1/7 · Initialize

When to use — and when not to

Use it when
  • Multiple AI applications need the same integrations, or you want to consume community-maintained servers.
  • Integrations should be swappable without redeploying the host application.
  • You want a uniform audit and permission layer across many capability providers.
Avoid it when
  • One application, one or two internal APIs — a direct function-calling integration is less code and fewer moving parts.
  • Latency-critical paths where an extra process hop and serialization matter.
  • When you cannot vet the servers you would connect to — each one is inside your trust boundary.

Failure modes

  • Tool sprawl: dozens of servers flood the prompt and the model picks wrong tools (wrong-tool-selected is the matching challenge).
  • A compromised or badly written server returns injected instructions in a tool result.
  • Version drift between client and server capabilities breaks discovery silently.
  • Treating MCP adoption as a product feature rather than an integration decision.

Tradeoffs

Complexity
low → high
Latency
low → high
Cost
low → high
Reliability
poor → strong
Debuggability
hard → easy

Overhead is modest per call; the real cost is prompt size and trust surface as servers accumulate.