Interview: Model Context Protocol (MCP)

MCP (Model Context Protocol) is an open standard for connecting AI applications to external tools and data through a common protocol. Without it, every app builds bespoke integrations for every API (N apps × M tools). MCP defines how clients (AI apps) talk to servers (tool/data providers) so one MCP server works across any compatible client.

• MCP Host: the AI application (e.g. IDE, chat client) that runs the agent loop.
• MCP Client: connector inside the host that speaks MCP to servers.
• MCP Server: exposes tools (actions), resources (readable data), and prompts (templates).
• Transport: typically stdio (local) or HTTP/SSE (remote).

Function calling is a model API feature: the LLM outputs a structured call, your app executes it. MCP is an integration layer that standardizes discovery, schema, auth, and transport for many tools. The model still does tool calling, but MCP servers provide a uniform way to register and invoke capabilities across hosts.

• Tools: callable functions (search, create ticket, run query).
• Resources: read-only context (files, DB rows, API snapshots) addressable by URI.
• Prompts: reusable prompt templates with arguments.

Servers declare capabilities at connect time so clients know what is available without hardcoding.

Stdio suits local dev tools (filesystem, git, shell) where the server runs as a child process on the same machine. HTTP/SSE suits shared team services (company knowledge base, ticketing API) that many clients connect to over the network. Remote servers need auth, TLS, rate limits, and observability like any production API.

• Authenticate clients and servers (OAuth, API keys, mTLS).
• Least-privilege tool scopes per user/session.
• Human approval for destructive or high-risk tools.
• Audit logs of every tool invocation with inputs/outputs.
• Validate and sandbox tool inputs; never pass raw model output to shell/SQL without checks.

RAG pulls static chunks into the prompt at query time. MCP resources can expose live data (current DB state, fresh API response) that RAG indexes cannot keep fresh. Many systems combine both: RAG for document knowledge, MCP tools/resources for real-time actions and data.

• Overly broad tools that give models too much power.
• Vague tool descriptions causing wrong tool selection.
• No idempotency on tools that mutate state.
• Returning huge payloads that blow the context window.
• Missing error messages the model can reason about and retry.

Unit test each tool handler independently. Integration test the server with a mock MCP client. Run eval scenarios where an LLM must pick the right tool, pass valid args, and recover from errors. Log tool latency and failure rates in staging before enabling write tools in production.