Skip to main content

📝 Model Context Protocol (MCP)

Description​

< What is it? >​

The Model Context Protocol (MCP) is an open protocol for connecting an AI application to external tools and context through a standard interface. An MCP server can expose capabilities such as a documentation search, browser, GitHub integration, or database, without every AI client needing a custom integration.

  • MCP architecture
┌──────────┐
│   User   │
└────┬─────┘
     ▼
┌───────────────────────────────┐
│ MCP Host                      │
│ ChatGPT, Claude Desktop, IDE  │
│                               │
│  ┌────────────┐               │
│  │ LLM/Agent  │               │
│  └─────┬──────┘               │
│        │ chooses a tool       │
│  ┌─────▼──────┐               │
│  │ MCP Client │               │
│  └─────┬──────┘               │
└────────┼──────────────────────┘
         │ MCP/JSON-RPC                  <-- Communication via pipes (stdin/stdout)
         ▼                                   Server dies when client exits
┌───────────────────────────────┐
│ MCP Server                    │
│                               │
│ convert_currency(...)         │
└──────────────┬────────────────┘
               ▼
        Exchange-rate API

mcp_arch
  • MCP workflow
mcp_flow
  • MCP interaction sequence diagram
mcp_seq_diagram

< Core roles >​

PartRole
MCP hostThe AI application that needs external capabilities
ex1. The AI application where users type their financial questions & receive responses.
ex2. Determines which external connections are needed based on the user's query.
MCP clientThe connection inside the host that communicates with a server
ex1. Receives tool definitions from the server & executes the corresponding requests.
ex2. Establishes a session with the MCP server using JSON-RPC messaging.
MCP serverThe service that exposes tools or context to the client
ex1. Translates complex banking API calls into a consistent, easy-to-use format.
ex2. Can run locally on machine or be hosted in the cloud.

< Primitives >​

  • Tools:
    • Actions the LLM can perform
    • Querying a database, searching documentation, running code, or booking a flight
  • Resources:
    • Context the LLM can use to answer questions
    • Documents, code, or database records that is too large to fit in a prompt
  • Prompts:
    • Pre-defined workflows and instructions that can be invoked by the LLM
    • Saves users from having to write complex prompts for every task
prompt-resource-workflow

Key points​

  • Tools let an agent take actions or retrieve live results, such as searching documentation or creating an issue.
  • Context gives an agent relevant information from an external source instead of placing everything in its prompt.
  • MCP servers may run locally through stdio or remotely through Streamable HTTP.
  • MCP expands an agent's access; it does not change the underlying model's knowledge or reasoning ability.
  • Treat each server as a security boundary: enable only trusted servers and grant the least access needed.

Ecosystem​

  • Use third-party server

    • Benefits:
      • Speed: filesystem and database access without writing a server
      • Maintained by others: you focus on the client and application
      • Integration: client code can be shared and reused for different MCP servers
    • Considerations:
      • Security: trust the server to handle your data and not leak it. It requires careful management of private data and credentials. The server runs code and may call external APIs → check these sources.
      • Surface area: more tools mean more the LLM can do; be aware of what each server exposes
      • Availability: if the server is down, your client may not work
      • Cost: some servers may charge for usage

  • Awesome MCP Servers (mcpservers.org): A collection of servers for the Model Context Protocol

  • MCP Open Library (8enSmith | github)

  • Model Context Protocol (modelcontextprotocol.io)

    • Interested in creating your own MCP server? Visit the official documentation at modelcontextprotocol.io for comprehensive guides, best practices, and technical details on implementing MCP servers.

Implementation​

  • mcp example (iddv | github)
    • A reference implementation of the Model Context Protocol (MCP) enabling seamless tool calling between LLMs and applications. Features client/server architecture with HTTP APIs, local CLI execution, and AWS Bedrock integration in a production-ready, extensible framework.

Q & A​

< Why does MCP use JSON-RPC instead of REST? >​

JSON-RPC fits MCP because the interaction is naturally “call this operation with these arguments,” and the same messages need to work locally or over HTTP. REST could support similar functionality, but it organizes communication around resources.

AspectJSON-RPC in MCPTypical REST API
Main ideaCall an operation, such as tools/callAccess resources through URLs and HTTP methods
Request structuremethod, params, and request idHTTP method, URL, headers, and body
TransportWorks over stdio or HTTPTypically HTTP
Response structureStandard result or error, matched by idHTTP status plus an API-defined response body

The practical advantages for MCP are:

  • Local and remote use: the same message format works with a local subprocess over stdio and a remote server over HTTP.
  • A consistent envelope: requests, results, errors, and notifications have defined formats.
  • A shared tool interface: clients use operations such as tools/list and tools/call across different servers. MCP supplies those operation names and schemas; JSON-RPC supplies the message structure.

See the JSON-RPC specification and MCP architecture documentation for the message format and transport design.

  • Example: an MCP server can expose a customer lookup tool while calling an existing REST API internally:

    Agent → MCP tools/call: get_customer(customer_id=42)
                         ↓
                   MCP server
                         ↓
             REST API: GET /customers/42

JSON-RPC and REST can work together. The agent gets a standard MCP tool interface, while the server integrates with the underlying REST service.

< When should I use a skill, MCP, or both? >​

Use a skill when the agent needs reusable guidance for performing a task. Use MCP when an application needs a standard way to discover and access tools or context provided by a server. Use both when a repeatable workflow depends on those capabilities.

NeedUseExample
Consistent procedures, domain knowledge, or output formattingSkillFollow a code-review checklist or produce a report in a required format
A standard connection to tools, databases, files, or servicesMCP serverExpose search_documents(query) or get_sales(month) to compatible AI applications
A reusable procedure that uses connected tools or dataSkill + MCPRetrieve sales through an MCP tool, then follow a skill's analysis and reporting steps
A one-off task already supported by existing toolsAn ordinary prompt may be enoughSummarize a document already in the conversation
  • Example: for a monthly sales report, the MCP server provides get_sales(month) to retrieve records. The skill tells the agent how to group revenue, verify totals, and format the report. The agent follows the skill and calls the tool when it needs the data.

A skill can bundle scripts that read files or call APIs directly, so external access does not automatically require MCP. MCP is useful when you want to expose capabilities through a shared interface that compatible clients can discover and call. MCP servers can also supply resources and prompt templates, so they are broader than tool APIs alone. See the Agent Skills overview and MCP server concepts.

For short code examples, see Skill vs. MCP.

Video Tutorial​

Reference​