Introduction to Model Context Protocol (MCP): A Slow-Paced Guide Based on Official Documentation 🐮

1. Introduction

1.1. What is MCP? - A Common Language for AI

Model Context Protocol (MCP) is a standardized protocol for seamlessly connecting AI applications and context sources (file systems, databases, external APIs, etc.).

You can think of MCP as a "common language for AI." Just as people from different countries can communicate through a common language, MCP provides a standardized way for different AI tools and data sources to understand each other. Having this common language allows various AI systems and context sources to exchange information efficiently.

MCP is based on a client-host-server architecture and uses JSON-RPC to provide features such as context exchange and sampling coordination. This architecture allows developers to integrate AI capabilities into multiple applications while maintaining clear security boundaries.

1.2. Why is MCP Important?

In the current AI development environment, each AI tool vendor has its own interface and API design, requiring significant effort to integrate between different systems. This leads to so-called "siloing," creating problems like vendor lock-in and compatibility issues.

The value of standardization provided by MCP can be summarized in the following points:

Value	Description
Interoperability	Different AI tools and systems can communicate in a common language
Modularity	Functionally separated design allows for implementing only the necessary features
Security	Improved security through clear boundaries and division of responsibilities
Flexibility	Vendor-independent design allows for the free selection and combination of tools

2. Evolution of AI Tool Integration

2.1. LLM Performance Improvements and the Need for Tool Integration

Large Language Models (LLMs) have evolved rapidly in recent years. Models such as GPT-4, Claude, Gemini, and Llama 3 have shown incredible performance in text generation, code creation, and reasoning capabilities. However, these models also have clear limitations. Specifically, the following constraints exist:

• Inability to access the latest information (information after the training data cutoff date)
• Inability to interact directly with specialized systems or databases
• Inability to efficiently process complex calculations or specific tasks
• Inability to directly access user-specific data or context

To overcome these limitations, the need to integrate LLMs with external tools and systems has grown. For example, by integrating with APIs that retrieve the latest weather data, internal corporate databases, or specific calculation engines, the capabilities of LLMs can be significantly expanded.

2.2. Early Solutions and Their Limitations

The AI industry has tried various approaches to address these challenges.

2.2.1. Function Calling

AI providers like OpenAI and Anthropic offer features that allow models to call external functions. This makes it possible to execute API requests, send database queries, and perform specific calculations.

However, Function Calling has the following limitations:

• Each provider has its own implementation method, resulting in a lack of compatibility.
• Primarily optimized for single-turn interactions, making it difficult to maintain complex context.
• Tends to cause vendor lock-in.
• The capabilities provided are limited.

2.2.2. RAG (Retrieval Augmented Generation)

RAG is an approach that combines information retrieval from external knowledge bases with the generation capabilities of LLMs. This has made it possible to expand the model's knowledge and provide more accurate answers.

However, RAG also has its challenges.

• Difficulty in balancing retrieval and generation
• Lack of a standardized way to integrate multiple data sources
• Complexity in handling real-time data
• Complex implementation requiring advanced engineering skills

2.3. Challenges for Users + Developers

While these initial approaches solved many problems, users and developers still face the following challenges.

2.3.1. Complexity of Integration

Current AI tool integration often relies on "custom integration." In other words, dedicated code must be written for each integration point, leading to the following issues.

Challenge	Content
Increased development effort	Individual integration code must be developed for each system
Maintenance complexity	Many independent integration points must be maintained and managed
Scalability limitations	New integration code is required every time a new system is added
Lack of consistent error handling	Different error handling methods are required for each integration destination

For example, if an application integrates with OpenAI's GPT-4, an internal database, a weather API, and a calendar system, it needs to write separate connection code for each and handle different data formats and authentication methods.

2.3.2. The Problem of Vendor Lock-in

Relying on a specific AI provider's proprietary APIs or tools creates the following risks:

Risk	Detail
Vulnerability to changes in pricing or terms of use	Being forced to be affected without alternatives if a vendor changes their pricing structure or terms of use
Increased cost of switching to other providers	Transitioning requires significant effort and cost even if a more suitable provider emerges
Risk of a single point of failure	If the selected provider experiences an outage, the entire system is affected
Restriction of innovation	Being tied to a specific vendor's features and constraints makes it difficult to adopt other innovative technologies

For example, a system optimized for OpenAI's Function Calling might require a redesign to run on Anthropic's Claude.

To address these challenges, the AI ecosystem has come to demand a standardized interface. This is where the Model Context Protocol (MCP) comes in. MCP was designed as a standard protocol to achieve interoperability between different AI tools and data sources.

In the next section, we will take a detailed look at the MCP architecture and its key components.

3. MCP Architecture Overview

3.1. Explanation of the Client-Host-Server Model

Model Context Protocol (MCP) adopts a client-host-server architecture. In this architecture, each host is designed to run multiple client instances. This design allows users to integrate AI capabilities across applications while maintaining clear security boundaries and separating concerns.

In the official documentation, there are no relationship lines connecting local servers and remote resources, but I have included them in this representation as I believe it is theoretically possible. My apologies if this is incorrect. I'll give you a dorayaki.

https://spec.modelcontextprotocol.io/specification/2025-03-26/architecture/#core-components

This diagram illustrates the primary components of MCP and their relationships. A host within the application host process manages multiple clients, each of which communicates with a different server. Each server accesses its own resources and integrates with local or remote data sources.

3.1.1. Host

The host process acts as a container and coordinator.

Role	Description
Client Management	Creates multiple client instances and manages their lifecycle
Connection Control	Monitors and controls the permissions and status of client connections
Security Management	Enforces security policies and consent requirements to ensure the safety of the entire system
Authentication Processing	Handles user authentication decisions and grants appropriate access rights
AI Integration Coordination	Coordinates AI/LLM integration and sampling, enabling efficient interaction with models
Context Management	Manages context aggregation across multiple clients and maintains a consistent information flow

The host serves as the central control point for the entire application, responsible for integrating and managing AI capabilities. For example, when a user asks a question using an LLM, the host coordinates the process of gathering the necessary context, sending the request to the appropriate LLM, and processing the results.

3.1.2. Client

Each client is created by the host and maintains a separate connection with a server.

Feature	Detail
Session Establishment	Establishes one stateful session per server, enabling continuous communication
Protocol Management	Handles protocol negotiation and capability exchange to ensure compatibility
Message Routing	Routes protocol messages bi-directionally, achieving smooth information exchange
Notification Management	Responsible for managing subscriptions and notifications, enabling real-time updates
Security Boundary	Maintains security boundaries between servers to ensure information separation

The host application creates and manages multiple clients, and each client has a one-to-one relationship with a specific server. This allows for managing individual connections with different data sources or tools while ensuring security.

3.1.3. Server

Servers provide specialized context and functionality.

Feature	Description
Capability Exposure	Exposes resources, tools, and prompts through MCP primitives, making them accessible
Specialization	Holds focused responsibilities and operates independently, increasing functional isolation and reusability
Sampling Requests	Can request sampling from AI models through the client interface
Security Compliance	Complies with configured security constraints to guarantee safe data access
Deployment Flexibility	Can operate as a local process or a remote service, catering to various environments

A server is a specialized component that provides access to specific functions or data sources. For example, one server might provide access to a file system, while another provides query capabilities for a database, with each having a clearly defined role.

3.2. Protocol Layer Structure

MCP is composed of several key components.

Layer	Role	Key Components	Implementation Requirement
Base Protocol	Defines core message formats	・Requests ・Responses ・Notifications ・Batch processing	Required for all implementations (MUST)
Lifecycle Management	Responsible for session management	・Initialization ・Operation ・Shutdown	Required for all implementations (MUST)
Server Features	Providing context to AI models	・Resources ・Prompts ・Tools	Optional implementation as needed (MAY)
Client Features	Strengthening coordination with servers	・Sampling ・Root Directories	Optional implementation as needed (MAY)
Utilities	Cross-cutting functional support	・Logging ・Argument Completion ・Progress Reporting ・Cancellation	Optional implementation as needed (MAY)

3.3. Overview of Core Components

MCP adopts a communication protocol based on JSON-RPC (JavaScript Object Notation Remote Procedure Call). JSON-RPC is a lightweight, language-independent remote procedure call format that provides a standardized way of exchanging messages between clients and servers.

3.3.1. Message Types

The following main message types are defined in MCP.

3.3.1.1. Requests

Sent from the client to the server, or vice-versa, to initiate an operation.

{
  "jsonrpc": "2.0",
  "id": "abc123",
  "method": "resources/read",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}

Characteristic	Requirement
ID	Must include a string or integer ID
Uniqueness	The ID must not be null and must be unique within the session
Method Name	Specify a string identifying the operation (e.g., "resources/read")
Parameters	Provide arguments required for the operation in an optional parameter object

3.3.1.2. Responses

Sent as an answer to a request, containing the result of the operation or an error.

{
  "jsonrpc": "2.0",
  "id": "abc123",
  "result": {
    "contents": [
      {
        "uri": "file:///project/src/main.rs",
        "mimeType": "text/x-rust",
        "text": "fn main() {\n    println!(\"Hello world!\");\n}"
      }
    ]
  }
}

Characteristic	Requirement
Matching ID	The response must include the same ID as the corresponding request
Result Classification	Responses are classified as either a "success result" or an "error"
Exclusive Setting	The response must set either result or error, and cannot set both

3.3.1.3. Notifications

One-way messages sent from the client to the server, or vice-versa. The receiver must not send a response.

{
  "jsonrpc": "2.0",
  "method": "notifications/resources/updated",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}

Characteristic	Requirement
No ID Required	Notifications must not include an ID
Method Name	Specify a string identifying the type of notification (e.g., "notifications/resources/updated")
Parameters	Provide information related to the notification in an optional parameter object
No Response Needed	A response must not be sent for a notification

3.3.2. Batch Processing

JSON-RPC also defines batch processing by sending multiple requests and notifications grouped in an array.

Implementation Requirement	Description
Sending Support	MCP implementations may support sending JSON-RPC batches (MAY)
Receiving Support	MCP implementations must support receiving JSON-RPC batches (MUST)
Batch Format	Multiple requests or notifications are grouped and sent as a JSON array
Response Handling	Responses for each request are returned in the same order as they were sent

3.4. Transport Layer

MCP defines the following standard transport mechanisms for communication between clients and servers.

Transport	Features	Communication Method	Use Cases
stdio	・Client starts the server as a sub-process ・Line-delimited message exchange ・Embedded newlines not allowed	・Server reads from stdin ・Server writes to stdout ・Logs can be output to stderr	・Local tool integration ・Command-line applications ・Scripted environments
Streamable HTTP	・Server as an independent process ・Support for multiple client connections ・Support for Server-Sent Events	・Send JSON messages via HTTP POST ・Asynchronous responses with Server-Sent Events ・Single HTTP endpoint	・Web applications ・Distributed systems ・Cloud services

These transport mechanisms allow MCP to operate flexibly in various environments and applications.

3.5. Design Principles

MCP is built based on the following key design principles.

Design Principle	Realization	Benefits
Ease of Server Construction	・Host applications handle complex orchestration ・Servers focus on specific, well-defined functions ・Simple interface design	・Minimization of implementation overhead ・Rapid development of specialized servers ・Improved maintainability
High Composability	・Each server provides independent, focused functionality ・Interoperability through shared protocols ・Modular design	・Flexible combination of multiple servers ・Reusability of functions ・Ease of system expansion
Security Isolation	・Servers receive only necessary context information ・Conversation history is maintained by the host ・Security boundaries enforced by the host	・Implementation of the principle of least privilege ・Reduction of information leakage risk ・Ensuring context isolation
Incremental Extensibility	・Core protocol provides minimum required functionality ・Capabilities negotiated as needed ・Maintenance of backward compatibility	・Independent evolution of clients and servers ・Supports future expansion ・Compatibility with existing systems

These design principles make MCP a flexible, extensible, and secure protocol. In the next section, we will take a detailed look at the specific features of MCP.

4. Core Features of MCP

The core features of MCP are divided into two categories: server features and client features. These features provide the foundation for effectively connecting AI models and context sources.

4.1. Server Features

As a bridge between context sources and AI models, the server provides the following three primary primitives.

4.1.1. Resources

Resources are structured data that the server exposes to clients. They provide a standardized way to access data from various sources, such as file systems, databases, and external APIs.

Operation	Description	Example
List Retrieval	Retrieves a list of available resources	List of project files, list of database tables, etc.
Read	Retrieves the content of a specific resource	Reading file contents, retrieving database records, etc.
Subscription	Subscribes to receive notifications of resource changes	Monitoring file changes, detecting database updates, etc.
Templates	Uses parameterized resource URIs	File path templates, query templates, etc.

4.1.1.1. Identification of Resources

Each resource is uniquely identified by a URI. MCP defines several standard URI schemes as follows:

URI Scheme	Purpose	Example
file://	Represents file system resources	file:///project/src/main.rs
git://	Git version control integration	git:///repo/main/HEAD:src/main.js
https://	Resources on the web	https://example.com/api/data
Custom	Implementation-specific resources	database:///users/123, jira:///projects/MCP

4.1.1.2. Data Types

Resources can contain either text or binary data.

Data Type	Structure	Use Case
Text	UTF-8 encoded text	Source code, configuration files, text documents, etc.
Binary	Base64 encoded binary data	Images, audio, binary files, etc.

4.1.1.3. Implementation Example: File System Resource

// Resource list request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list"
}

// Resource list response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      {
        "uri": "file:///project/src/main.rs",
        "name": "main.rs",
        "description": "Main entry point",
        "mimeType": "text/x-rust"
      },
      {
        "uri": "file:///project/Cargo.toml",
        "name": "Cargo.toml",
        "description": "Project configuration",
        "mimeType": "text/toml"
      }
    ]
  }
}

// Resource read request
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "resources/read",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}

// Resource read response
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "contents": [
      {
        "uri": "file:///project/src/main.rs",
        "mimeType": "text/x-rust",
        "text": "fn main() {\n    println!(\"Hello, MCP!\");\n}"
      }
    ]
  }
}

4.1.2. Prompts

Prompts are templates or instructions used to guide interactions with LLMs. Servers expose prompts, and clients can select and customize them based on user intent.

Operation	Description	Example
List Retrieval	Retrieves a list of available prompts	Code generation, bug fixing, document creation, etc.
Prompt Retrieval	Retrieves the content of a specific prompt (applying arguments)	Retrieving a "code generation" prompt with specified language and task
Change Notification	Notification of changes to the prompt list	Addition of new prompts, modification of existing prompts, etc.

4.1.2.1. Prompt Structure

A prompt consists of a name, description, arguments, messages, etc.

Element	Purpose	Characteristics
Name	Unique identifier for the prompt	Simple string for list display
Description	Description for the user	Explains the purpose and usage of the prompt
Arguments	Customization parameters	Includes name, description, required flag, etc.
Messages	The actual content sent to the LLM	Includes role (user/assistant) and content

4.1.2.2. Message Content Types

Prompt messages can include various types of content.

Content Type	Format	Use Case
Text	Plain text	Instructions, questions, answers, etc.
Image	Base64 encoded data	Providing visual information (for multimodal LLMs)
Audio	Base64 encoded data	Providing audio information
Embedded Resource	Resource reference	Direct reference to server-managed resources

4.1.2.3. Implementation Example: Code Review Prompt

// Prompt list request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "prompts/list"
}

// Prompt list response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "prompts": [
      {
        "name": "code_review",
        "description": "Analyzes code quality and suggests improvements",
        "arguments": [
          {
            "name": "code",
            "description": "Code to be reviewed",
            "required": true
          },
          {
            "name": "language",
            "description": "Programming language",
            "required": false
          }
        ]
      }
    ]
  }
}

// Prompt retrieval request
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": {
      "code": "function add(a, b) {\n  return a + b;\n}",
      "language": "javascript"
    }
  }
}

// Prompt retrieval response
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "description": "Code review prompt",
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "Please review the following JavaScript code. Analyze for quality, readability, and potential bugs.\n\nfunction add(a, b) {\n  return a + b;\n}"
        }
      }
    ]
  }
}

4.1.3. Tools

Tools are executable functions that allow LLMs to interact with external systems. They can perform various actions, such as sending API requests, executing database queries, and performing calculations.

Operation	Description	Example
List Retrieval	Retrieves a list of available tools	API requests, fetching weather info, performing calculations, etc.
Tool Call	Executes a specific tool	Calling a weather API, executing a database query, etc.
Change Notification	Notification of changes to the tool list	Addition of new tools, modification of existing tools, etc.

4.1.3.1. Tool Structure

A tool consists of a name, description, input schema, etc.

Element	Purpose	Characteristics
Name	Unique identifier for the tool	Simple string used during calls
Description	Functional description of the tool	Information for the LLM to understand the tool's purpose
Input Schema	Definition of arguments	Argument definition in JSON Schema format
Annotations	Additional information regarding tool behavior	Safety levels, presence of side effects, etc.

4.1.3.2. Tool Execution Results

Results of tool execution can be returned in various formats.

Result Type	Format	Use Case
Text	Plain text	Providing information, calculation results, etc.
Image	Base64 encoded data	Graphs, charts, visual data, etc.
Embedded Resource	Resource reference	Saving results as resources for later reference
Error Info	Error flag and message	Reporting errors during tool execution

4.1.3.3. Implementation Example: Weather Information Tool

// Tool list request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Tool list response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Retrieves current weather information for a specified location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            },
            "units": {
              "type": "string",
              "enum": ["metric", "imperial"],
              "description": "Temperature unit (metric=Celsius, imperial=Fahrenheit)"
            }
          },
          "required": ["location"]
        }
      }
    ]
  }
}

// Tool call request
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "Tokyo",
      "units": "metric"
    }
  }
}

// Tool call response
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current weather in Tokyo:\nTemperature: 22°C\nHumidity: 65%\nCondition: Clear"
      }
    ],
    "isError": false
  }
}

4.2. Client Features

The client provides features for coordinating with AI models and providing resource access points to the server.

4.2.1. Sampling

Sampling is a feature where the server requests text generation ("sampling" or "completion") from an LLM via the client. This allows the server to utilize AI capabilities without its own API keys.

Feature	Description	Use Case
Message Creation	Obtain text generation from LLM	Simple Q&A, complex text generation, etc.
Model Selection	Provide hints for LLM selection	Suggest the best model for the task
User Approval	Request user approval for sampling requests	Ensure security and privacy

4.2.1.1. Message Content

Sampling messages can include various types of content.

Content Type	Format	Use Case
Text	Plain text	Text-based conversation, Q&A, etc.
Image	Base64 encoded data	Image analysis, multimodal interaction, etc.
Audio	Base64 encoded data	Audio input, audio analysis, etc.

4.2.1.2. Model Selection

MCP uses an abstracted preference system for model selection.

Selection Method	Description	Example
Model Hints	Suggest desired models or families	"hints": [{"name": "claude-3-sonnet"}]
Capability Priority	Specify priority of valued characteristics	Specify priority for cost, speed, intelligence, etc. from 0 to 1

4.2.1.3. Implementation Example: Simple Question

// Sampling request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "What is the capital of France?"
        }
      }
    ],
    "modelPreferences": {
      "hints": [
        {
          "name": "claude-3-sonnet"
        }
      ],
      "intelligencePriority": 0.8,
      "speedPriority": 0.5
    },
    "systemPrompt": "You are a helpful assistant.",
    "maxTokens": 100
  }
}

// Sampling response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "role": "assistant",
    "content": {
      "type": "text",
      "text": "The capital of France is Paris."
    },
    "model": "claude-3-sonnet-20240307",
    "stopReason": "endTurn"
  }
}

4.2.2. Roots

Roots are a feature where the client provides the server with access points to the file system. The server can access files within the given roots but cannot access locations outside of them.

Feature	Description	Example
Root List Retrieval	Get available file system access points	Project directories, repositories, etc.
Change Notification	Notify changes to the root list	Addition of new projects, deletion of roots, etc.

4.2.2.1. Root Structure

Each root consists of a URI and a name.

Element	Purpose	Characteristics
URI	Unique identifier for the root	Specify access point with file:// URI
Name	Human-readable name for display	Project name, repository name, etc.

4.2.2.2. Implementation Example: Project Directory

// Root list request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "roots/list"
}

// Root list response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "roots": [
      {
        "uri": "file:///home/user/projects/myproject",
        "name": "My Project"
      },
      {
        "uri": "file:///home/user/projects/another-project",
        "name": "Another Project"
      }
    ]
  }
}

4.3. Interaction of Features

Server features and client features work together to effectively connect AI models and context sources.

Server Feature	Client Feature	Example of Interaction
Resources	Roots	The server accesses files within the roots provided by the client.
Prompts	Sampling	Request sampling from the client using the server's prompts.
Tools	Sampling	Generate server tool execution results based on sampling results.

4.4. Security Considerations

When implementing MCP features, attention must be paid to the following security considerations.

Feature	Risk	Mitigation
Resources	Unauthorized access	・URI validation ・Explicit access control ・Access restriction to within roots only
Prompts	Prompt injection	・Input sanitization ・Separation of prompts and user input ・Escaping of templates
Tools	Misuse	・Implementation of user approval ・Validation of tool inputs ・Sanitization of execution results
Sampling	Privacy infringement	・Ensuring user consent ・Filtering of sensitive information ・Review of request content
Roots	Path traversal	・Path normalization ・Resolving symbolic links ・Validation of absolute paths

By understanding and appropriately implementing these features, effective collaboration between AI systems and context sources becomes possible. In the next section, we will compare Function Calling and MCP and take a detailed look at the differences between each approach.

5. Comparison between Function Calling and MCP

Function Calling and Model Context Protocol (MCP) offer different approaches to integrating Large Language Models (LLMs) with external tools. In this chapter, we will compare the two in detail and deepen our understanding of their respective characteristics, advantages, and challenges.

5.1. Architectural Differences

Function Calling and MCP differ significantly in their fundamental architectural design.

Function Calling and MCP take fundamentally different approaches to AI tool integration.

Function Calling is designed around a centralized API, whereas MCP adopts a decentralized design with a clear division of responsibilities. These architectural differences have a significant impact on system flexibility, scalability, and manageability. The following table compares the main design differences between the two approaches and their practical implications.

Feature	Function Calling	MCP	Impact
Central Control	AI Provider API	Application Host	In MCP, control is more distributed, and the user has more initiative.
Architecture	Centralized	Decentralized	MCP allows for more flexible combinations of components.
AI Integration Method	Built-in model functionality	Abstraction at the protocol level	MCP makes it easier to switch between AI providers.
Scalability	Provider-dependent	Based on protocol specifications	In MCP, interoperability is improved through standardization.
Connection Topology	Star type (radial around the API)	Mesh type (multiple servers and clients)	MCP allows for more complex integrations.

5.2. Liberation from Vendor Dependency

One of the critical differences between Function Calling and MCP is the degree of vendor dependency.

Vendor dependency is a crucial consideration in the AI development landscape.

While Function Calling tends to lead to implementations tightly coupled with a specific API provider, MCP reduces dependence on specific vendors by abstracting at the protocol level, enabling a more flexible configuration. The following table summarizes the key differences in vendor dependency between the two approaches.

Aspect	Function Calling	MCP	Significance
API Dependency	Dependent on vendor-specific APIs	Abstraction at the protocol level	In MCP, switching between different AI providers is easy
Vendor Switching	Requires implementation changes	Can be switched transparently	In MCP, switching is possible just by changing host configurations
Multi-vendor Support	Requires maintaining multiple implementations	Single protocol implementation	In MCP, a single implementation can support multiple vendors
Handling Feature Differences	Needs individual handling	Automatic handling through capability negotiation	In MCP, differences in features can be explicitly processed

5.3. Which to Choose?

Function Calling and MCP can be thought of as complementary approaches that address different needs.

Scenario	Recommended Approach	Reason
Prototyping	Function Calling	Easy to implement and allows for rapid development
Single-vendor Environments	Function Calling	Can leverage the simplicity of direct integration
Multi-vendor Environments	MCP	Significant benefits from ease of vendor switching and abstraction
Enterprise Integration	MCP	Separated responsibilities and security boundaries are important
Complex Ecosystems	MCP	Standardized communication between diverse systems provides value
Long-term Projects	MCP	Standardization and extensibility make it easier to adapt to future changes

These two approaches are not mutually exclusive, and it is possible to use them selectively depending on the situation. For example, a strategy could involve rapidly developing a prototype with Function Calling in the short term, while planning a migration to MCP for the long term.

Ultimately, you will choose the optimal approach by considering project requirements, scale, future extensibility, and risk tolerance for vendor dependency.

6. Implementation Tutorial (Reference Implementation)

In the previous chapters, we have deepened our understanding of the concepts and features of MCP. In this chapter, we will look at specific implementation methods through actual MCP implementation examples published in the official repository. This time, we will focus on an example implementation of an MCP server utilizing the Brave Search API from the official Model Context Protocol repository.

6.1. Example Implementation Using the MCP SDK

Various reference implementations are published in the official MCP repository.

Among them, we will look at an MCP server that wraps the Brave Search API. This implementation is built using the MCP SDK. This server provides the following two search functions through the MCP protocol:

1. Web Search - General web search functionality
2. Local Search - Business and place search functionality considering location information

6.2. Explanation of the Reference Implementation

We will explain the reference implementation step-by-step. First, let's look at the overall structure.

#!/usr/bin/env node

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
  Tool,
} from "@modelcontextprotocol/sdk/types.js";

// Tool definitions
// ...

// Server implementation
// ...

// Request handlers
// ...

// Start server
// ...

This code illustrates the basic building blocks of an MCP server. It imports the SDK, defines tools, constructs the server, sets up request handlers, and then starts the server.

6.2.1. Defining Tools

MCP servers provide functions that LLMs can call by defining "tools." In the reference implementation, two tools are defined.

const WEB_SEARCH_TOOL: Tool = {
  name: "brave_web_search",
  description:
    "Performs a web search using the Brave Search API, ideal for general queries, news, articles, and online content. " +
    "Use this for broad information gathering, recent events, or when you need diverse web sources. " +
    "Supports pagination, content filtering, and freshness controls. " +
    "Maximum 20 results per request, with offset for pagination. ",
  inputSchema: {
    type: "object",
    properties: {
      query: {
        type: "string",
        description: "Search query (max 400 chars, 50 words)"
      },
      count: {
        type: "number",
        description: "Number of results (1-20, default 10)",
        default: 10
      },
      offset: {
        type: "number",
        description: "Pagination offset (max 9, default 0)",
        default: 0
      },
    },
    required: ["query"],
  },
};

const LOCAL_SEARCH_TOOL: Tool = {
  name: "brave_local_search",
  description:
    "Searches for local businesses and places using Brave's Local Search API. " +
    "Best for queries related to physical locations, businesses, restaurants, services, etc. " +
    "Returns detailed information including:\n" +
    "- Business names and addresses\n" +
    "- Ratings and review counts\n" +
    "- Phone numbers and opening hours\n" +
    "Use this when the query implies 'near me' or mentions specific locations. " +
    "Automatically falls back to web search if no local results are found.",
  inputSchema: {
    type: "object",
    properties: {
      query: {
        type: "string",
        description: "Local search query (e.g. 'pizza near Central Park')"
      },
      count: {
        type: "number",
        description: "Number of results (1-20, default 5)",
        default: 5
      },
    },
    required: ["query"]
  }
};

Each tool definition includes the following elements:

Element	Purpose	Example
name	Unique identifier for the tool	brave_web_search
description	Detailed description of the tool	Functional description of Brave Web Search
inputSchema	Argument definition in JSON Schema format	Parameter definitions such as query and number of results

The following points highlight the implementation design choices made here:

1. Detailed descriptions - Descriptions are written in detail so that the LLM can appropriately select the tool, including its usage and functional limitations.
2. Use of Markdown format - Information is organized and made easy to read using bullet points.
3. Providing default values - Default values are set for optional parameters to simplify user input.

6.2.2. Server Initialization

Next, let's look at the part that initializes the MCP server.

// Server implementation
const server = new Server(
  {
    name: "example-servers/brave-search",
    version: "0.1.0",
  },
  {
    capabilities: {
      tools: {},
    },
  },
);

// Check for API key
const BRAVE_API_KEY = process.env.BRAVE_API_KEY!;
if (!BRAVE_API_KEY) {
  console.error("Error: BRAVE_API_KEY environment variable is required");
  process.exit(1);
}

const RATE_LIMIT = {
  perSecond: 1,
  perMonth: 15000
};

let requestCount = {
  second: 0,
  month: 0,
  lastReset: Date.now()
};

function checkRateLimit() {
  const now = Date.now();
  if (now - requestCount.lastReset > 1000) {
    requestCount.second = 0;
    requestCount.lastReset = now;
  }
  if (requestCount.second >= RATE_LIMIT.perSecond ||
    requestCount.month >= RATE_LIMIT.perMonth) {
    throw new Error('Rate limit exceeded');
  }
  requestCount.second++;
  requestCount.month++;
}

In this code, the following actions are being performed:

1. Create an MCP server instance and define the server information and capabilities.
2. Retrieve the Brave Search API key from an environment variable and check for its existence.
3. Define API usage limits (rate limits).
4. Implement a function to check rate limits.

When initializing the server, the server name, version, and supported capabilities (capabilities) are specified. This server declares that it only supports the "tools" feature.

6.2.3. Implementing API Communication

Next, let's look at the part that implements communication with the Brave Search API.

async function performWebSearch(query: string, count: number = 10, offset: number = 0) {
  checkRateLimit();
  const url = new URL('https://api.search.brave.com/res/v1/web/search');
  url.searchParams.set('q', query);
  url.searchParams.set('count', Math.min(count, 20).toString()); // API limit
  url.searchParams.set('offset', offset.toString());

  const response = await fetch(url, {
    headers: {
      'Accept': 'application/json',
      'Accept-Encoding': 'gzip',
      'X-Subscription-Token': BRAVE_API_KEY
    }
  });

  if (!response.ok) {
    throw new Error(`Brave API error: ${response.status} ${response.statusText}\n${await response.text()}`);
  }

  const data = await response.json() as BraveWeb;

  // Extract just web results
  const results = (data.web?.results || []).map(result => ({
    title: result.title || '',
    description: result.description || '',
    url: result.url || ''
  }));

  return results.map(r =>
    `Title: ${r.title}\nDescription: ${r.description}\nURL: ${r.url}`
  ).join('\n\n');
}

This function executes a web search using the Brave Search API. The key points of the implementation are as follows:

1. Respecting API Limits - Check the rate limit before making a request.
2. Parameter Validation - Upper bound check (Math.min(count, 20)).
3. Appropriate Error Handling - Check HTTP status codes and generate error messages.
4. Response Formatting - Organize results and convert them into an easy-to-read format.
5. Robust Data Processing - Ensure robustness using optional chaining and null checks.

Similarly, communication for the more complex local search (location-based search) API is also implemented. This includes processing that calls multiple API endpoints and combines the results.

6.2.4. Setting Up Request Handlers

For the MCP server to respond to requests from clients, request handlers are set up.

// Tool handlers
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [WEB_SEARCH_TOOL, LOCAL_SEARCH_TOOL],
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  try {
    const { name, arguments: args } = request.params;

    if (!args) {
      throw new Error("No arguments provided");
    }

    switch (name) {
      case "brave_web_search": {
        if (!isBraveWebSearchArgs(args)) {
          throw new Error("Invalid arguments for brave_web_search");
        }
        const { query, count = 10 } = args;
        const results = await performWebSearch(query, count);
        return {
          content: [{ type: "text", text: results }],
          isError: false,
        };
      }

      case "brave_local_search": {
        if (!isBraveLocalSearchArgs(args)) {
          throw new Error("Invalid arguments for brave_local_search");
        }
        const { query, count = 5 } = args;
        const results = await performLocalSearch(query, count);
        return {
          content: [{ type: "text", text: results }],
          isError: false,
        };
      }

      default:
        return {
          content: [{ type: "text", text: `Unknown tool: ${name}` }],
          isError: true,
        };
    }
  } catch (error) {
    return {
      content: [
        {
          type: "text",
          text: `Error: ${error instanceof Error ? error.message : String(error)}`,
        },
      ],
      isError: true,
    };
  }
});

In this code, two types of request handlers are set up:

1. Tool List Handler (ListToolsRequestSchema)

   • Returns a list of all tools provided by the server.
   • Generates a response containing the tools array in accordance with MCP conventions.

2. Tool Call Handler (CallToolRequestSchema)

   • Retrieves the tool name and arguments from the request.
   • Checks for the existence and type of arguments.
   • Dispatches to the appropriate tool execution function.
   • Handles errors and generates MCP-formatted responses.

6.2.5. Starting the Server

Finally, let's look at the part that starts the server.

async function runServer() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Brave Search MCP Server running on stdio");
}

runServer().catch((error) => {
  console.error("Fatal error running server:", error);
  process.exit(1);
});

This code performs the following processes:

1. Create a transport that communicates via standard input/output using StdioServerTransport.
2. Connect the transport to the server.
3. Output a server startup message to the log.
4. Set up error handling (properly exit on fatal errors).

Starting an MCP server is very simple. Since the SDK abstracts the complexity of the protocol, you only need to select a transport and connect. This implementation uses standard input/output (stdio), but it can be changed to an HTTP transport as needed.

6.3. Overall MCP Flow Explanation

Let's look at the overall picture of the MCP flow through this server.

This diagram illustrates the overall flow of the search functionality using MCP.

1. Initialization Phase

   • The user enters a slash command in the IDE.
   • The MCP host performs initialization and capability negotiation with the server.
   • The host retrieves the tool list from the server.

2. Execution Phase

   • The user selects a tool (brave_web_search).
   • The host sends a tool call request to the server.
   • The server calls the external API and retrieves the results.
   • The server formats the results and returns them to the host.
   • The IDE inserts the search results into the user's context.

6.4. Implementation Points and Learnings

It feels like it might be surprisingly easy to implement, right?

7. Future and Outlook of MCP

This Chapter 7 was generated by AI. I found it interesting, so I decided to include it as is.

We have so far explored the concepts, architecture, features, and implementation of Model Context Protocol (MCP) in detail. In this final chapter, we provide a perspective on the future of MCP and its potential impact on the integration of AI tools.

7.1. Predicted Evolution of the Protocol

Although MCP is still a relatively new protocol, its design principles and extensibility allow us to predict how it will evolve in the future.

7.1.1. Progress in Standardization

MCP is currently in the early stages of evolution as an open standard. The following developments are expected over the next few years:

Phase	Characteristics	Period
Initial Adoption Phase	Adoption by advanced developers and tools Trial and error in implementation Establishment of feedback loops	Present – within 1 year
Mainstreaming Phase	Integration into major IDEs and toolchains Increase in third-party servers Becoming a de facto standard	1–2 years
Maturity Phase	Widespread adoption in corporate environments Formation of a rich ecosystem Possibility of official standardization	2–3 years

During this evolutionary process, the protocol itself will likely undergo functional expansion and refinement. The current protocol specifications are designed with future extensibility in mind. Based on feedback from actual use cases, existing features will be strengthened and new features will be added.

7.1.2. Directions for Technical Evolution

The future technical evolution of MCP could head in the following directions:

1. Enhanced Multimodal Support

   Current MCP supports basic multimodal content such as text, images, and audio. However, as the capabilities of AI models evolve, more advanced multimodal interactions will be required. Support for 3D data, interactive content, and real-time streaming may be added.

   For example, the following expansion is conceivable:

   // Example of future 3D/AR content support
   {
     "type": "3d_scene",
     "format": "glb",
     "data": "base64-encoded-data",
     "interaction": {
       "allowNavigation": true,
       "highlightObjects": ["object1", "object2"]
     }
   }
   

2. Real-time Collaboration Features

   The current MCP is primarily based on request-response patterns. In the future, collaboration protocols might be added to allow multiple AI agents to work together to solve problems. This will enable multiple AI services with specialized knowledge to cooperate and solve more complex tasks.

3. Enhanced Security and Privacy

   As AI utilization expands into corporate and privacy-sensitive domains, MCP will be required to have even stronger security features. Features such as encrypted communication, access control, and audit logs may be standardized.

   Envisaged features include:

   • End-to-end encrypted communication
   • Fine-grained access control
   • Server signing and verification mechanisms
   • Declaration of data usage purposes and retention policies
   • Privacy protection processing (anonymization, sanitization)

4. Advanced Capability Negotiation

   The current MCP supports simple capability negotiation to indicate whether features are supported. In the future, more flexible negotiation, such as detailed version compatibility and partial feature support, might be introduced.

   // Example of future capability negotiation
   {
     "capabilities": {
       "tools": {
         "version": "2.0",
         "features": {
           "streaming": {
             "supported": true,
             "modes": ["incremental", "chunked"]
           },
           "cancellation": {
             "supported": true,
             "timeout": 30000
           }
         }
       }
     }
   }
   

7.2. Impact on the AI Tool Ecosystem

The widespread adoption of MCP has the potential to bring about extensive changes across the entire AI tool ecosystem. These impacts will likely extend beyond technical aspects to include business models and user experiences.

7.2.1. Diversification and Specialization of the Ecosystem

With a standardized protocol that is independent of specific AI providers, the following changes are anticipated:

1. Increase in Specialized AI Services
   As it becomes possible to connect to various AI services through MCP, specialized AI services focused on specific domains will likely increase. For example, AI services providing legal document analysis, scientific paper search and summarization, or specialized expertise for specific industries are conceivable. These services can be seamlessly integrated with existing LLMs through MCP without the need to develop or operate their own LLMs.

2. Lower Barrier to Entry for Small Players
   The current AI market is dominated by major providers (OpenAI, Anthropic, Google, Microsoft, etc.). The standardization of MCP will make it easier for smaller companies and startups to enter the market by providing AI tools and services specialized in specific fields. This will promote diversity and innovation within the ecosystem.

3. Formation of AI Tool Marketplaces
   Along with the spread of MCP, marketplaces providing a variety of AI tools and services may emerge. Users will be able to choose from various AI tools according to their needs and integrate them into their own environments through MCP.

7.2.2. Changes in Business Models

MCP will also influence the business models of AI services.

1. Decentralization of Value Creation
   In current AI services, major LLM providers create the bulk of the value. As integration through MCP progresses, value creation will become more decentralized, with AI services and tools specialized in specific domains playing a larger role.

2. From API Economy to Protocol Economy
   Current AI services primarily rely on API-based business models, but the spread of MCP may lead to the formation of a broader protocol-based ecosystem. This signifies a shift from purchasing specific services from API providers to accessing various services through a common protocol.

3. Integration with Open Source Models
   MCP will also facilitate integration with open-source LLMs. Companies will find it easier to adopt a "hybrid AI strategy," combining commercial APIs with self-hosted open-source models according to their needs.

7.3. What Developers/Companies Should Do Now

To prepare for the advancement of MCP, let's consider what developers and companies should start working on now.

7.3.1. Recommendations for Developers

1. Learning and Experimenting with the MCP Protocol
   Developers are recommended to learn the basic concepts and implementation methods of MCP and start with experimentation on small projects. Use the reference implementations and official documentation mentioned in this article to understand how to build MCP servers.

2. Considering MCP Compatibility for Existing Tools
   Developers who have existing tools or APIs should consider exposing them as MCP servers. This could expand the range of tool utilization and provide access to new user groups.

   // Example of exposing an existing API as an MCP server
   import { Server } from "@modelcontextprotocol/sdk/server";
   import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio";
   import { CallToolRequestSchema, ListToolsRequestSchema, Tool } from "@modelcontextprotocol/sdk/types";
   
   const server = new Server(
     {
       name: "my-existing-api",
       version: "1.0.0",
     },
     {
       capabilities: {
         tools: {},
       },
     }
   );
   
   // Define existing API as an MCP tool
   server.setRequestHandler(ListToolsRequestSchema, async () => ({
     tools: [
       {
         name: "my_api_function",
         description: "Calls my existing API function",
         inputSchema: {
           // Schema corresponding to existing API parameters
         }
       }
     ]
   }));
   
   server.setRequestHandler(CallToolRequestSchema, async (request) => {
     // Implement existing API call logic here
   });
   

3. Designing Complex Tool Integrations
   The strength of MCP lies in the coordination of multiple tools and services. Developers can provide higher value by designing workflows that combine multiple tools, rather than just standalone tools.

7.3.2. Recommendations for Companies

1. Formulating an Internal AI Tool Integration Strategy
   Companies should consider an integration strategy for the AI tools used internally and the AI capabilities they develop independently. Adopting an integration framework centered on MCP will reduce the risk of future vendor lock-in and enable flexible expansion.

2. Establishing Privacy and Security Policies
   When integrating AI tools, it is crucial to establish policies to ensure privacy and security. Leverage MCP's decoupled architecture to control access to sensitive data and design mechanisms to provide only the necessary information to AI tools.

3. Conducting Pilot Projects
   Before implementing MCP company-wide, it is recommended to conduct pilot projects in specific departments or with a limited group of users. This allows for identifying challenges associated with implementation and formulating an adoption strategy suited to the organization.

7.4. Future of Standardization

The standardization process for MCP requires not only technical aspects but also cooperation and consensus-building across the entire industry. Let's consider the outlook for future standardization.

7.4.1. Standardization Milestones

The standardization of MCP may progress through milestones such as the following:

Milestone	Content	Importance
Enhancement of Reference Implementations	Expanding reference implementations for various use cases	Ensuring implementation consistency and promoting adoption
Development of Test Suites	Developing test tools to verify compatibility	Guaranteeing interoperability
Formation of Industry Groups	Establishing industry organizations to lead the development of MCP	Establishing a system for continuous development and management
Official Standardization by ISO/IEC, etc.	Certification by international standardization bodies	Ensuring the legitimacy of corporate adoption

7.4.2. Vision: As a Common Language for Intelligent Computing

In the long term, MCP has the potential to move beyond the integration of AI tools and become a standard communication protocol between various "intelligent computing" components.

In this vision, MCP functions as a "common language" that enables information exchange between diverse intelligent system components, such as language processing, multimodal recognition, data systems, and interfaces with the physical world. This will allow various technologies to work together to form a more advanced and integrated AI ecosystem.

8. Conclusion: The Possibilities Brought by MCP

MCP has the potential to bring about a transformation of the entire AI tool ecosystem, moving beyond being just a technical protocol. By enabling the exchange of context and functionality in a standardized way, the development of more diverse and specialized AI tools will be promoted, allowing users to combine and utilize these tools more flexibly.

By understanding the potential of MCP and considering its early adoption, developers and companies can solve many current challenges related to AI tool integration and enable more effective use of AI. If the philosophy of a "common language for AI" that MCP aims for is realized, we will move closer to a future where AI is integrated into our lives and work more naturally and seamlessly.

9. References

• Model Context Protocol specification
• Model Context Protocol servers