Category: Generative AI

The Model Context Protocol (MCP) is an open-source protocol developed by Anthropic that standardises how AI applications connect with external data sources and tools. It essentially functions as the “USB-C for AI apps”.

Large Language Models (LLMs) like Claude, ChatGPT, Gemini, and LlaMA have revolutionised how we interact with information and technology. However, they face a fundamental limitation: isolation from real-world data and systems. This creates what’s known as the “N×M problem,” where N represents the number of LLMs and M represents the number of tools or data sources that need integration.

MCP addresses this challenge by providing a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol. Just as USB-C offers a standardised way to connect devices to various peripherals, MCP provides a standardised way to connect AI models to different data sources and tools.

Understanding the Core of MCP

MCP is an open protocol that standardises how applications provide context to LLMs. It enables developers to build secure, two-way connections between their data sources and AI-powered tools through a straightforward architecture. Developers can either expose their data through MCP servers or AI applications (MCP clients) that connect to these servers.

MCP Host: Programs like Claude Desktop, Cursor IDE, or AI tools that want to access data through MCP. They contain the orchestration logic and can connect each client to a server.

MCP Client: Protocol clients that maintain 1:1 connections with servers. They exist within the MCP host and convert user requests into a structured format that the open protocol can process.

MCP Servers: Lightweight programs that each expose specific capabilities through the standardised Model Context Protocol. They act as wrappers for external systems, tools, and data sources.

How does MCP standardise communication between AI applications and external systems?

MCP uses JSON-RPC 2.0 as the underlying message standard, providing a standardised structure for requests, responses, and notifications. This ensures consistent communication across different AI systems and external tools.

The Mechanics of MCP: How it Works Under the Hood

When an MCP client starts up, it’s like walking into a new office building and meeting your team for the first time. You need to introduce yourself, learn what everyone can do, and then start collaborating.

The “Connect” Phase: The MCP client reaches out to all configured servers simultaneously. In the given diagram, the client connects to three specialised servers — a GitHub Server, Database Server, and File Server. This connection happens through various methods like STDIO pipes or HTTP (server-sent events), but the key point is that all connections are established upfront.

The “Discovery” Phase: Now comes the getting-to-know-you conversation. The client essentially asks each server, “What can you do?” This isn’t a one-way conversation — it’s more like a friendly chat where each server responds with “I can help with…” followed by their specialities, which means that they expose all of their tools to the client. The GitHub Server might say it can help with repositories and code, while the Database Server offers data queries and updates.

The “Registration” Phase: This is where things get practical. Each server provides its detailed “business card” by sharing its complete toolkit. As shown in the diagram, the GitHub Server lists tools like get_repo and commit_codeThe Database Server offers query_data and update_recordThe File Server provides read_file and write_file. The client carefully catalogues all these capabilities for future use.

The “Working” Phase: Finally, it’s time to get things done! The client can now make specific requests like “Please do task X” to any server and receive “Task completed” responses. The client seamlessly orchestrates work across multiple specialised servers, creating powerful AI workflows that leverage each server’s unique strengths.

This entire handshake process transforms a simple client into a powerful orchestrator that can tap into diverse capabilities whenever needed, making MCP the perfect protocol for building sophisticated AI applications.

The Three Primary Interfaces of MCP Servers

MCP servers expose functionality through three primary interfaces:

1. Tools: These are model-controlled functions that the AI can invoke when needed. They are essentially functions that can implement anything from reading data to writing data to other systems. Examples include Get weather, Get forecast, or Get alerts. The AI system (like Cursor or Cloud Desktop) decides when to use these tools based on the context.
2. Resources: These are application-controlled data exposed to the AI system. Resources can be static, such as PDF documents, text files, images, or JSON files. They can also be dynamic, where the server provides instructions on how to dynamically retrieve the data.
3. Prompts: These are user-controlled templates for common interactions. They are predefined templates that users can invoke, helping to standardise complex interactions and ensure consistent outputs. Examples include templates for documentation Q&A, transcript summarisation, or outputting data as JSON.

Building and Running Model Context Protocol (MCP) Servers: Simplified Deployment

The Model Context Protocol (MCP) empowers AI models to interact with real-world tools and data. MCP servers are the bridge, exposing specific functions and information to AI clients in a standardised way. Understanding how to build and deploy these servers is key to unlocking AI’s full potential.

Creating Your MCP Server

Developers have several straightforward options for creating MCP servers:

Manual Coding: For precise control, you can write your server from scratch using languages like Python or Node.js, defining its tools, data access, and prompts.

Community Solutions: Leverage a vast library of open-source MCP servers. This allows for quick setup and modification, saving development time by using existing, proven solutions.

Official Integrations: Many companies, like Cloudflare and Stripe, now offer official MCP servers for their services. Always check for these first, as they provide high-quality, well-maintained integrations, ensuring seamless and reliable connections.

The Role of the Transport Layer: STDIO vs. HTTP+SSE (Server-Sent Events)

MCP supports two primary transport methods:

• STDIO (Standard Input/Output): Used for local integrations where the server runs in the same environment as the client
• HTTP+SSE (Server-Sent Events): Used for remote connections, with HTTP for client requests and SSE for server responses and streaming

STDIO Transport: Direct Local Communication

STDIO (Standard Input/Output) transport creates a direct communication pipeline between the MCP client and server running on the same machine. The client launches the server as a child process and connects through stdin/stdout streams, enabling ultra-fast message exchange without network overhead. This approach is perfect for local AI assistants, development environments, and desktop applications where maximum performance and security are priorities, since there’s no network exposure and communication happens through native OS mechanisms.

HTTP+SSE Transport: Real-Time Remote Connectivity

HTTP with Server-Sent Events (SSE) enables MCP clients to connect to remote servers while maintaining real-time communication capabilities. The client sends requests via standard HTTP, while the server pushes live updates, progress notifications, and streaming responses back through an SSE connection. This transport method is ideal for web applications, cloud deployments, and scenarios requiring scalability, as it allows multiple clients to connect to a single server while providing instant server-to-client communication for dynamic AI workflows and collaborative features.

Deploying Your MCP Server: Focus on Docker

Once built, an MCP server needs to be deployed. While local (STDIO) and remote (HTTP/SSH) methods exist, Docker containers are the most robust and widely adopted deployment strategy for modern applications, including MCP servers.

Why Dockerized Deployment is Superior:

Docker packages your MCP server and all its dependencies into a single, isolated unit. This approach offers significant advantages:

1. Enhanced Security: Each server runs in its isolated environment, preventing conflicts and limiting potential security breaches. This sandboxing protects your system from vulnerabilities within the server.
2. Guaranteed Consistency: A Docker image ensures your server behaves identically across any environment, from your development machine to a production cloud. This eliminates compatibility issues and streamlines testing and deployment.
3. Effortless Scalability: Docker containers are lightweight and start quickly, making it easy to scale your MCP services up or down as demand changes. Tools like Kubernetes can automate this scaling, ensuring high availability.
4. Simplified Management: All server dependencies are bundled within the Docker image, simplifying setup and avoiding conflicts. Versioning and easy rollbacks also provide a safety net for updates.

Docker’s widespread adoption and inherent benefits make it the ideal choice for deploying secure, portable, and scalable MCP servers, ensuring your AI integrations are robust and reliable.

Introduction of MCP:

MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.

Why MCP:

Modern applications increasingly rely on Large Language Models (LLMs) that must dynamically interact with multiple tools, databases, APIs, and files. Traditional RESTful APIs struggle with this because they:

• Require manual integration and boilerplate per tool.
• Lack of context awareness and persistent state.
• Don’t support dynamic tool discovery or bidirectional communication.

Model Context Protocol (MCP) solves this by standardizing how LLM-based apps discover, invoke, and interact with tools in a structured, contextual, and modular way.

It enables:

• Dynamic, pluggable tools with self-describing schemas.
• Context sharing (memory/state) across tools.
• Asynchronous interactions, like notifications or background tasks.
• Reduced N×M complexity for tool integrations.

Learn a Few Terminologies:

Learn a few terminologies like: MCP Host, MCP Client, MCP Server, MCP Protocol, etc.

---

1. MCP Host:

The MCP Host is the LLM-powered application or environment (e.g., Claude Desktop, a chat UI, or IDE) that wants to access external information or tools, but cannot talk to them directly.

• Acts as the “chef” who needs ingredients (data), but doesn’t fetch them.
• Example: Claude Desktop wants to query a Postgres database.
• Hosts orchestrate the conversation and manage multiple tool interactions.
• Uses MCP Clients internally to connect to tools.

2. MCP Client:

The MCP Client is the connector within a Host that translates LLM requests into MCP messages and sends them to servers.

• Like the “waiter” taking orders from the chef.
• Example: MCP client inside an IDE that calls GitHub or file-system MCP servers.
• Maintains one-to-one connections to each MCP Server.
• Handles JSON-RPC communication (requests, responses, notifications).

3. MCP Server:

The MCP Server is a lightweight service exposing specific capabilities—such as databases, file systems, and web APIs— via MCP.

• Acts like the “supplier” who delivers ingredients/tools.
• Example: PostgreSQL MCP Server that runs SQL queries and returns results.
• Servers are self-describing, sharing schema, tools, annotations, and capabilities.
• Can wrap local resources (e.g., files) or remote services (e.g., Slack, Stripe).

4. MCP Protocol:

The Model Context Protocol standardizes how Clients and Servers communicate via JSON-RPC 2.0 over STDIO or HTTP+SSE, enabling dynamic tool use and context exchange.

• Defines messages: requests (tool calls), notifications, and responses.
• Supports tool discovery, structured inputs/outputs, and persistent context.
• Enables bidirectional communications: Servers can notify Clients or request model samples.
• Example types:
  • Resources: read-only context like database views.
  • Tools: actions like “run_sql” or “create_chart.”
  • Sampling: The server asks the model to generate a summary of the data.

Communication between Components:

1. User Input: A user provides input (e.g., a question or command) to the system.
2. MCP Client requests tool list: The MCP Client (inside the MCP Host / Application) queries available MCP Servers to find the list of tools they provide.
3. MCP Client collects tool descriptions: The MCP Client retrieves metadata about the available tools from all MCP Servers (e.g., what methods they support, input/output schemas).
4. LLM receives questions + tools list: The MCP Client gives the LLM the user’s question and the list of available tools for reasoning.
5. LLM selects a specific tool for the task: The LLM decides which tool(s) to call based on the user input and tool capabilities, then forms a tool request.
6. MCP Client sends the tool call: The MCP Client forwards the LLM’s tool request (via JSON-RPC) to the specific MCP Server that hosts the tool.
7. MCP Server processes and extracts context: The MCP Server performs the requested operation (e.g., DB query, file processing, API call) and generates output.
8. MCP Client returns tool response to LLM: The result from the tool is passed back to the LLM for integration into its reasoning.
9. LLM generates contextualized response: The LLM uses the tool output as part of its overall response formulation.
10. Final Output to User: The user receives a rich, contextualized answer that combines the LLM’s reasoning and the tool’s output.

Real World Example:

Scenario: K12 Chatbot with Agentic Capabilities

You’re building an AI-powered chatbot that helps students with:

• Answering subject-specific questions (Math, Science, etc.)
• Generating MCQs or quizzes.
• Fetching summaries from textbooks.
• Displaying charts or solving equations.

Key Components in these Applications:

1. MCP Host (K12 Chatbot Application):

• This is your main chatbot interface (e.g., built with LangChain or LangGraph).
• It includes the LLM agent that interacts with students.
• It needs access to textbooks, quiz generation tools, image/video explainers, etc., but doesn’t connect directly to them.
• Example: A LangChain app with memory and state management

2. MCP Client (Connector Layer):

• Resides within the host (chatbot) and connects to different MCP Servers.
• Translates AI’s internal requests into structured MCP tool calls.
• Maintains persistent state and tool discovery.

3. MCP Servers (Your Tool Providers): You can create various servers depending on the tools you want your chatbot to access:

• Textbook Reader Server: Exposes subject-specific PDFs or markdown notes as a resource.
• Quiz Generator Server: A tool that takes a topic and returns 5 MCQs.
• Math Solver Server: Accepts math expressions, returns LaTeX-rendered solution or graph.
• Video/Animation Server: Calls external APIs to return animated video explanations.

Each of these servers self-describes its tools (e.g., generate_quiz, read_topic, solve_equation).

4. MCP Protocol:

• The standard that connects your client and servers.
• Uses JSON-RPC 2.0 over:
  • HTTP + Server-Sent Events (SSE) for web-hosted tools.
  • stdio for local resources or offline apps
• This enables your chatbot to:
  • Discover which tools are available.
  • Understand each tool’s input/output schema.
  • Maintain session context (like memory of what topic is being discussed).
  • Receive notifications (e.g., “quiz ready!”).

Why is MCP perfect for this?

• Dynamic tool discovery: Add new subjects/tools without coding changes in the chatbot.
• Persistent state: Student topic context and progress are retained across multiple questions.
• Security and isolation: Each tool runs in its own MCP Server (e.g., quiz generator can’t access DB directly).
• Scalable & modular: You can scale servers independently (e.g., separate quiz service per grade).

Note:

If you have 50 different tools, you do not necessarily need 50 servers, but you can, depending on your architecture and design goals. Here’s a breakdown based on Security, Isolation, and Scalability using MCP:

1. Security & Isolation:

Why separation helps:

• Each MCP Server runs in its process or container.
• If a tool is compromised, the damage is isolated.
• Sensitive tools (e.g., student_db_tool) can run in a secure environment with access control.

Example:

• Quiz_generator cannot access student_grades_tool or admin_tools unless explicitly allowed.
• You can sandbox tools that run untrusted code (e.g., code_executor_tool).

Conclusion: Creating separate servers per sensitive or critical tool enhances security and isolation.

2. Scalability & Modularity:

Why modular servers help:

• Tools with heavy load (e.g., video_generator, text_summarizer) can scale independently.
• You can deploy tool servers on different machines or even in the cloud (e.g., AWS Lambda, containers).
• Developers can work on tools independently and deploy updates without affecting the rest of the system.

Example:

• math_solver, textbook_parser, and speech_to_text_tool are hosted separately and scaled based on demand.

Conclusion: Splitting tools into modular MCP Servers allows horizontal scaling and better resource management.

---

Comparisons between APIs vs. MCP:

Similarities between APIs vs. MCP:

Aspect	Descriptions
Communication	Both are mechanisms for communication between clients and services/tools.
Data Exchange	Both use structured data (usually JSON) to send and receive information.
Request/Response	Both follow a pattern where a client sends a request and gets a response.
Interoperability	Both allow integration of multiple services and tools, often over HTTP.
Can be Secured	Both support secure communication (e.g., via HTTPS or internal auth).

Difference between APIs and MCP:

Criteria	Traditional APIs	Model Context Protocol (MCP)
Designed For	Human/frontend clients (browsers, apps).	LLMs and autonomous agents.
Interface Type	RESTful (HTTP verbs, endpoints like /getData).	JSON-RPC method calls like run_tool, generate_quiz.
Tool Discovery	Manual (Swagger/OpenAPI) or hardcoded.	Automatic, self-describing tools (metadata sent by each MCP server).
Context Awareness	Stateless — no memory between requests.	Contextual — LLMs retain memory across multiple tool calls.
Protocol Structure	URI-based, with route handlers (/user/5).	RPC-like calls with tool names as methods and parameter dictionaries.
Dynamic Tool Calling	Not native, requires orchestration logic.	Built-in — LLMs can reason and call new tools in real-time.
Latency Handling	Synchronous by default.	Supports async patterns (like server push, background jobs via notify, etc.)
Scalability Model	One endpoint per functionality or microservice.	One MCP Server per tool or group of tools — more modular, LLM-aware.
Use Case Fit	CRUD apps, frontend/backend separation.	LLM agents, tool chaining, and AI orchestration (e.g., agents solving tasks using many tools).

---

JSON-RPC, StdIO, and HTTP + SSE:

Here’s a clear and complete explanation of JSON-RPC, along with StdIO and HTTP + SSE in the context of Model Context Protocol (MCP) and real-world applications:

JSON-RPC:

JSON-RPC (JavaScript Object Notation – Remote Procedure Call) is a lightweight protocol used to make remote method calls using JSON. It allows a client (like an LLM or frontend) to call methods on a remote server as if calling local functions.

Key Characteristics:

• Language-agnostic.
• Uses JSON for requests and responses.
• Supports method names, parameters, and IDs.
• Supports notifications (one-way messages without expecting a response).

JSON-RPC Request Example:

{
  "jsonrpc": "2.0",
  "method": "generate_quiz",
  "params": {"topic": "photosynthesis", "questions": 5},
  "id": 1
}

JSON-RPC Response Example:

{
  "jsonrpc": "2.0",
  "result": ["What is chlorophyll?", "Name the process..."],
  "id": 1
}

Real-World Example (K12 Chatbot): A K12 chatbot wants to generate a quiz based on a topic.

Instead of calling a REST API like:

POST /api/quiz?topic=photosynthesis&count=5

The LLM uses JSON-RPC:

{
  "method": "generate_quiz",
  "params": {"topic": "photosynthesis", "count": 5}
}

Why this helps:

• The tool is self-describing.
• Easy to chain tools dynamically.
• Method-focused, not URI-focused.

StdIO (Standard Input/Output) in MCP:

StdIO is a communication pattern where the MCP server communicates via command-line input/output streams.

Example Use Cases:

• An LLM agent launches a local Python script tool (like a math solver).
• The tool receives JSON-RPC via stdin and writes responses via stdout.

Request on stdin:

$ echo '{ "method": "solve_equation", "params": {"eq": "x^2 - 4 = 0"}, "id": 1 }' | python mcp_tool.py

Tool responds on stdout:

{ "result": ["x = -2", "x = 2"], "id": 1 }

Ideal For:

• Running tools locally or in sub-processes.
• Lightweight deployment.
• CLI/terminal-based agent systems.

HTTP + SSE (Server-Sent Events):

MCP over HTTP + SSE allows clients to send JSON-RPC calls over HTTP and receive streamed responses from the server in real time.

SSE = one-way push from server to client (good for streaming answers, like LLM outputs).

Example Use Cases:

• A user requests a summary document
• The server sends updates line-by-line via SSE:

data: {"partial": "The document discusses..."}
data: {"partial": "Key points include..."}
data: {"final": "Complete summary here"}

Ideal For:

• Streaming large outputs (e.g., LLM responses).
• Web applications that need real-time updates.
• Cloud-hosted MCP servers.

Summary Table:

Transport	Best For	Communication Pattern
StdIO	Local tools, CLI agents	JSON-RPC via stdin/stdout
HTTP + SSE	Remote tools, web apps	JSON-RPC over HTTP + streaming

---

How MCP Standardizes Communication:

Model Context Protocol (MCP) defines a uniform way for LLMs and tools to interact, regardless of where or how those tools are hosted.

Key Components:

Transport Options:

StdIO (Standard Input/Output): MCP Client ⇄ and MCP Server communicate via terminal I/O streams.

When to Use:

• Local tool execution (e.g., subprocesses tools)
• Lightweight environments.
• When low-latency matters or when deploying on the CLI.

Example:

• An LLM spawns a Python tool via subprocesses
• Sends JSON-RPC to its stdin
• Receives JSON output from stdout

HTTP + SSE (Server-Sent Events): JSON-RPC over HTTP requests, with streamed responses via SSE.

When to Use:

• Remote/cloud-based MCP servers
• Need to stream long outputs (e.g., LLM completions)
• Web integrations

Example:

• MCP client POSTs {“method”: “generate_quiz”} to /rpc
• Server streams quiz questions line-by-line via SSE

When to Use Each Option:

Scenario	Use StdIO	Use HTTP + SSE
Local tools	✓
Cloud/remote tools		✓
Streaming outputs		✓
Web integrations		✓
CLI/terminal apps	✓
Low latency needed	✓

Summary:

• MCP standardizes how tools (servers) describe themselves and how LLMs (clients) call them using JSON-RPC 2.0.
• It abstracts away the transport layer — whether it’s Stdio for local tools or HTTP + SSE for cloud services — enabling tool discovery, context sharing, and AI-native orchestration.
• It’s optimized for LLM-first architecture, making it scalable, modular, and contextual.

---

Difference between Function Call and MCP:

Aspect	Function Call	MCP (Model Context Protocol)
Scope	LLM calls pre-registered functions/tools inside one API (e.g., OpenAI API)	LLM calls external tools/servers dynamically via JSON-RPC
Tool Discovery	Functions must be registered in the API request (no discovery)	Tools self-describe at runtime; dynamic discovery is possible
Execution Location	Functions handled within the API environment	Tools run anywhere (local, cloud, separate services)
Transport	Encoded in LLM API request/response	StdIO or HTTP + SSE for tool communication
State/Context Sharing	No cross-call memory (unless implemented manually)	Sessions enable context sharing across multiple tool calls
Flexibility	Limited to what’s embedded in the LLM provider’s API	More modular: tools live independently and can scale separately
Streaming & Async	Limited (depends on provider)	Built-in async, streaming via SSE

---

When to use Function Call and When to use MCP:

Let’s explore when to use a Function Call or when to use MCP:

When to use Function Call:

• You want a simple integration inside your LLM API call (e.g., OpenAI, Anthropic).
• Your tools are small, deterministic, and lightweight.
• You don’t need independent deployment, scaling, or dynamic discovery.
• Example:
  • Call the weather API, calculator directly within the LLM API request.

When to use MCP:

• You want your LLM to access external, independently running tools.
• You need dynamic tool chains where tools can be added/removed at runtime.
• You need modular, scalable architecture (e.g., microservices for AI agents).
• You want persistent context across tools in a workflow.
• Example:
  • An agent that queries the DB, generates a report, and emails the result, all via independent MCP tools.