Free lesson · AI Engineering

What Is MCP?

Medium10 min readaillmrag

What Is MCP?

The Integration Problem Nobody Wanted to Solve Twice

By late 2024, the function calling ecosystem had a problem that was invisible to anyone building a single application - and obvious to anyone building two.

Every AI application that called external tools had its own bespoke integration layer. Your Slack assistant had custom code to format Slack's API responses for the LLM. Your database assistant had custom code to format SQL results. Your monitoring assistant had custom code for metrics. Each integration was a one-off: a specific tool, wired to a specific application, in a specific way. None of them could be reused.

I watched this play out at Meta across three internal AI tools. Each team built their own tool integrations - with their own parameter conventions, their own error formats, their own discovery mechanisms, and their own authentication patterns. When a fourth team wanted to build a new assistant that used the same Jira, Confluence, and PagerDuty integrations the first three teams had already built, they had no option to reuse any of it. Every integration was application-specific code locked inside someone else's repo. The fourth team spent six weeks rebuilding integrations that already existed three times over.

This is the problem the Model Context Protocol (MCP) solves. MCP is a standardised protocol that defines how AI applications (clients) discover and use capabilities exposed by external services (servers). Instead of every application building its own custom integration for every tool, the tool builds one MCP server, and every MCP-compatible application can use it - automatically, with no custom integration code.

The analogy I reach for: MCP is to AI tool integrations what USB is to peripheral connections. Before USB, every printer, keyboard, and mouse had its own proprietary connector. After USB, any peripheral plugs into any computer. Before MCP, every AI tool integration was bespoke. After MCP, any MCP server plugs into any MCP client.

The Architecture: Clients, Servers, and the Protocol Between Them

MCP defines three concepts and the protocol that connects them.

MCP Servers expose capabilities - tools, resources, and prompts - that an AI application can use. A Jira MCP server exposes tools like create_issue, search_issues, and update_issue. A database MCP server exposes execute_query and list_tables. The server does not know or care which AI application will use it - it exposes a standardised interface.

MCP Clients are the AI applications that connect to servers, discover their capabilities, and invoke them. Your chat assistant, your IDE plugin, your command-line tool - any application that uses LLMs and needs to call external services can be an MCP client.

The Protocol defines how clients and servers communicate: how a client discovers what capabilities a server offers (capability negotiation), how it invokes a tool (request/response format), how errors are communicated, and how the connection lifecycle works (initialisation, operation, shutdown).

graph TD
    subgraph "MCP Clients"
        C1[Chat Assistant]
        C2[IDE Plugin]
        C3[CLI Tool]
    end
    
    subgraph "MCP Protocol"
        P[Standardised interface:<br/>discover capabilities,<br/>invoke tools,<br/>handle errors]
    end
    
    subgraph "MCP Servers"
        S1[Jira Server<br/>create/search/update issues]
        S2[Database Server<br/>query/list tables]
        S3[Monitoring Server<br/>get metrics/alerts]
        S4[File System Server<br/>read/write/search files]
    end
    
    C1 --> P
    C2 --> P
    C3 --> P
    P --> S1
    P --> S2
    P --> S3
    P --> S4

This diagram shows the MCP architecture. Three MCP clients - a chat assistant, an IDE plugin, and a CLI tool - all connect through the standardised MCP protocol to four MCP servers: a Jira server for issue management, a database server for queries, a monitoring server for metrics, and a file system server. Any client can use any server through the protocol without custom integration code.

The key architectural insight: the protocol creates an N×M matrix from what was previously N×M individual integrations. If you have 5 AI applications and 10 external tools, the old model requires 50 custom integrations. MCP requires 5 clients and 10 servers - 15 components instead of 50, and adding a new tool requires building one server that all 5 applications can immediately use.

What MCP Servers Expose: Three Primitives

An MCP server exposes capabilities through three standardised primitives. Understanding these is essential because they map directly to the concepts you already know from Module 7 - with important structural differences.

Tools

The direct equivalent of Module 7's function calling. A tool is an action the LLM can request: create_issue, execute_query, send_message. Tools have names, descriptions, and parameter schemas - exactly the same structure as the tool definitions from topic 7.2. The LLM sees the tool definitions and decides when to call them, just as in function calling.

The difference from raw function calling: the tool definitions come from the server, not from your application code. Your client discovers them at connection time through capability negotiation - it does not need to hardcode them. If the Jira server adds a new tool next week, your client discovers it automatically.

Resources

Resources are read-only data the server exposes - things the LLM or the application can read but not modify through the resource interface. A file system server might expose resources like file:///path/to/config.yaml. A database server might expose db://schema/tables as a resource listing. A knowledge base server might expose specific documents.

Resources are the MCP equivalent of context from Module 6 - information that enters the LLM's context window to inform its reasoning. The difference from RAG: RAG retrieves documents through your own retrieval pipeline. MCP resources are exposed by an external server that controls what is available and how it is formatted.

Prompts

Prompts are reusable prompt templates the server provides - pre-built instructions for how to use the server's capabilities effectively. A code review server might expose a prompt template called review_pull_request that includes the system instructions, the output format, and the specific review criteria the server's tools expect.

Prompts are the least commonly used of the three primitives today, but they represent an interesting architectural idea: the tool provider, not the tool consumer, defines how the tool should be used. This inverts the Module 7 pattern where your application owns the prompts and the tool definitions are passive schemas.

MCP vs Direct Function Calling: When Each Wins

MCP is not a replacement for function calling - it is a layer on top of it. Understanding when to use MCP versus direct function calling prevents over-engineering simple systems and under-engineering complex ones.

When Direct Function Calling Is Sufficient

You have fewer than 5 tool integrations. The overhead of MCP - server deployment, capability negotiation, transport management - is not justified for a small number of tools. Write the tool definitions in your application code (topic 7.2), call the APIs directly, and move on.

Your tools are internal and tightly coupled to your application. If your tools are custom functions that exist only within your application (a calculator, a local file search, a custom business logic function), MCP adds a network layer and a server deployment between your application and its own code. That is overhead, not architecture.

You are prototyping. MCP adds setup time. During prototyping, inline function definitions get you to working code faster. Add MCP when the prototype matures into a production system with multiple consumers.

When MCP Adds Value

Multiple AI applications share the same tools. This is MCP's primary value proposition. If your organisation has a Slack assistant, a code review bot, and a support agent that all need Jira integration, one MCP server replaces three custom integrations.

You want to use community-built integrations. The MCP ecosystem includes pre-built servers for GitHub, Slack, Google Drive, PostgreSQL, Notion, and dozens of other services. Using a community server saves you the integration work entirely - connect your client to the server and the tools appear.

You need dynamic tool discovery. When your application needs to work with tools it does not know about at compile time - connecting to servers that may be added, removed, or updated at runtime - MCP's capability negotiation handles this. Direct function calling requires hardcoded tool definitions.

You are building a platform. If you are building an AI platform that users can extend with their own tools (an IDE, a workflow engine, a no-code AI builder), MCP provides the standardised interface for user-contributed tool servers.

Transport: How Clients and Servers Talk

MCP supports two transport mechanisms for the connection between client and server. The transport choice affects deployment architecture and is the first decision you make when building with MCP.

stdio (Standard I/O)

The client launches the server as a child process and communicates through standard input/output pipes. The server runs on the same machine as the client. This is the simplest transport - no networking, no authentication, no service discovery.

When to use stdio: local development, desktop applications (like VS Code or Claude Desktop), and single-user tools. The server is private to the client that launched it.

HTTP with Server-Sent Events (SSE)

The server runs as an HTTP service. The client connects over the network. Requests go as HTTP POST; responses and notifications come as server-sent events. This is the production transport - it supports remote servers, multiple concurrent clients, and standard web infrastructure (load balancers, authentication, monitoring).

When to use HTTP/SSE: production deployments, shared servers accessed by multiple clients, cloud-hosted integrations, and any scenario where the server and client run on different machines.

graph LR
    subgraph "stdio transport"
        C1[Client] -->|"stdin/stdout<br/>same machine"| S1[Server<br/>child process]
    end
    
    subgraph "HTTP/SSE transport"
        C2[Client A] -->|"HTTP POST<br/>network"| S2[Server<br/>HTTP service]
        C3[Client B] -->|"HTTP POST<br/>network"| S2
        S2 -->|"SSE<br/>events"| C2
        S2 -->|"SSE<br/>events"| C3
    end

This diagram compares the two MCP transport mechanisms. stdio transport has the client and server on the same machine communicating through standard input and output pipes, with the server running as a child process. HTTP with SSE transport has the server running as an HTTP service that multiple clients connect to over the network, with requests sent as HTTP POST and responses returned as server-sent events.

The MCP Lifecycle

Every MCP connection follows a defined lifecycle that ensures both client and server agree on capabilities before any tools are invoked.

Initialisation. The client connects and sends an initialize request with its own capabilities (what protocol version it supports, what features it can use). The server responds with its capabilities - what tools, resources, and prompts it offers. This handshake is what enables dynamic tool discovery: the client learns what the server can do at connection time, not at compile time.

Operation. The client invokes tools, reads resources, and uses prompts. The server processes requests and returns results. This is the steady-state phase where actual work happens - and it maps directly to the function calling loop from topic 7.1, with the difference that tool definitions came from capability negotiation rather than hardcoded configuration.

Notification. Either side can send notifications - one-way messages that do not expect a response. The server might notify the client that a resource has changed (a file was updated). The client might notify the server of context changes. Notifications enable reactive behaviour without polling.

Shutdown. The client sends a shutdown signal, the server cleans up resources, and the connection closes. Graceful shutdown matters for servers that hold state - database connections, open file handles, authentication sessions.

Tip: The lifecycle maps to familiar patterns. If you have worked with Language Server Protocol (LSP) in VS Code or any IDE, MCP's lifecycle will feel familiar - it was deliberately modelled after LSP's client-server architecture. The initialisation handshake, capability negotiation, request/response pattern, and notifications are structurally identical. MCP is LSP adapted for AI tool use instead of code editing.

The Ecosystem Today

MCP was open-sourced by Anthropic in late 2024 and has grown rapidly. The ecosystem includes reference implementations in Python and TypeScript, pre-built servers for major services (GitHub, Slack, Google Drive, PostgreSQL, filesystem, web search), and client support in Claude Desktop, VS Code with Copilot, Cursor, and several other AI development tools.

The ecosystem is young - many servers are early-stage, and the protocol itself is still evolving. Production-grade deployments are becoming common but are not yet universal. Module 8.4 covers the production patterns needed to deploy MCP servers reliably.

For this course, the important thing is not to memorise the current ecosystem - it will change - but to understand the pattern: a standardised protocol for tool integration that turns bespoke integrations into reusable components. Whether MCP specifically becomes the dominant standard or a successor replaces it, the architectural principle - standardise the tool interface so integrations compose - will remain.

Interview: MCP comes up in AI Engineering interviews as an architecture question: "You are building an AI platform where users can connect their own tools. How would you design the tool integration layer?" Strong candidates describe the need for standardised capability discovery, invoke-and-result patterns, and transport flexibility - whether or not they name MCP specifically. The architectural thinking (standardisation, reusability, dynamic discovery) is what interviewers evaluate, not knowledge of a specific protocol version.

Exercise: Explore the MCP Ecosystem

Exercise: Get hands-on with MCP before building in the next topics:

1. Install Claude Desktop (if you have not already) and connect the filesystem MCP server from the official examples. Explore: what tools does the server expose? What resources?
2. Connect a second MCP server (the GitHub server or the SQLite server). Observe the capability negotiation - how does the client learn what tools each server offers?
3. Ask Claude Desktop to use a tool from each server in a single conversation. You have just used multi-server MCP - one client, two servers, dynamic tool discovery.
4. Challenge: compare the experience to direct function calling from Module 7. What did MCP handle that you had to build manually in Module 7? What overhead did MCP add that Module 7 did not have?
5. Challenge 2: list every integration in your current workflow that could become an MCP server (your project management tool, your CI/CD system, your monitoring stack). For each, would MCP add value over a direct integration? Apply the decision framework from this topic.

What You Should Take From This Lesson

MCP is a standardised protocol for AI tool integration that replaces bespoke per-application integrations with reusable client-server components. Servers expose three primitives - tools (actions), resources (read-only data), and prompts (usage templates) - that clients discover through capability negotiation at connection time. Two transports serve different deployment models: stdio for local development, HTTP/SSE for production. MCP adds value when multiple applications share tools, when community integrations save development time, or when dynamic tool discovery is needed. It adds unnecessary overhead for simple, single-application tool use - where direct function calling from Module 7 is the right choice. The architectural principle - standardise the tool interface for composability - outlasts any specific protocol implementation.

The next topic builds the server side: creating an MCP server that exposes your own capabilities to any MCP-compatible client.

Back to AI Engineering