MCP Server Architecture and Internal Components

What is MCP 

MCP (Model Context Protocol) is a way for AI models (like me) to interact with external tools or systems in a structured way.

MCP Components:

• Host: Think of this as the "middleman" or platform that runs the AI model and manages communication.
• Client: This is the user-facing application (like your chat interface) that sends requests to the host.
• Server: This is the tool or service that provides extra functionality (like a database, calculator, or image generator). The host talks to the server when the client needs something special.

Communication mechanism between MCP Components:

• MCP Client→ sends a request (e.g., "generate an image") to the Host.
• What it is: A software component (usually code) that runs in the user-facing application (like a chat UI, IDE plugin, or CLI).
• Role: Sends structured requests to the MCP Host and receives responses.
• Not an agent by itself—it’s typically implemented in Python, JavaScript, or other languages as part of the app.
• Think of it as: The “bridge” between the user and the MCP Host.
• Client → Host: Protocol => JSON-RPC 2.0 over WebSocket or HTTP
• MCP Host→ interprets the request and decides if it needs help from a Server.
• What it is: A runtime environment (code) that runs the AI model and orchestrates communication with MCP Servers.
• Role: Receives requests from the Client, interprets them, and calls MCP Servers when tools or external data are needed.
• Not an agent in isolation—it’s usually part of the AI platform (like OpenAI’s MCP implementation).
• Think of it as: The “brain” that routes requests and aggregates results.
• Host ↔ Server: Protocol =>  JSON-RPC 2.0 over WebSocket or HTTP
• MCP Server → does the job (e.g., creates the image) and sends the result back to the Host.
• What it is: A service or process (code) that exposes tools/resources via the MCP protocol.
• Role: Provides access to external systems (DB, APIs, file system) through standardized MCP endpoints.
• Implemented as: Python, Node.js, or any language that supports MCP spec.
• Think of it as: The “toolbox” behind the Host.
• Server ↔ tools: Protocol => HTTP, SQL, File I/O to backend
• Host → returns the result to the MCP Client

Protocols & Message Flow:

• Requestor: The human or external app that initiates a request (e.g., you in a chat UI).
• Requestor → MCP Client: UI calls or app method invocations (or HTTP if separate service).
• MCP Client: The user-facing application (chat app, IDE extension, etc.). It sends requests to the Host.
• MCP Client → MCP Host: JSON-RPC 2.0 over WebSocket or HTTP.
• MCP Host: The orchestrator/platform that runs the AI model and speaks MCP. It routes requests to MCP servers.
• MCP Host → MCP Server(s): JSON-RPC 2.0 over WebSocket or HTTP.
• MCP Server: One or more services that expose tools/resources via MCP (e.g., file system, DB, APIs).
• MCP Server → Tool/DB/API: HTTP/REST, SQL, File I/O, etc.
• Tools / DB Access: The actual backends the MCP server uses (databases, APIs, search, compute, etc.).

MCP and Architecture View:

• Layer 1: User Layer
• Component: Requestor (User or external app)
• Role: Initiates commands or queries.
• Layer 2: Interface Layer
• Component: MCP Client
• Role: Converts user input into structured MCP requests.
• Protocol: JSON-RPC over WebSocket/HTTP to Host.
• Layer 3: Orchestration Layer
• Component: MCP Host
• Role: Runs the AI model, interprets requests, and routes to MCP Servers.
• Protocol: JSON-RPC over WebSocket/HTTP to Servers.
• Layer 4: Integration Layer
• Components: MCP Servers (API Tools, DB Adapter, File System)
• Role: Wrap external resources and expose them via MCP.
• Protocol: HTTP, SQL, File I/O to backends.
• Layer 5: Backend Layer
• Components: External APIs, Databases, File Storage

Background about MCP server protocol as RPC:

Remote Procedure Call (RPC):

Remote Procedure Call (RPC) is a method that enables a program to execute a function on another computer in a network as if it were local. The client sends the request (with arguments) to the server, the server executes the function, and the result is sent back. RPC hides the details of networking,

  Step by Step - RPC Works

• Client Calls Stub: The client calls a local procedure (stub) as if it were normal.
• Marshalling: The stub packs (marshals) all input parameters into a message.
• Send to Server: The message is sent across the network to the server.
• Server Stub: The server stub unpacks the message and calls the actual server procedure.
• Execution & Return: The server runs the procedure and returns the result to the stub.
• Back to Client: The server stub sends the result back, and the client stub unpacks it.

 Notes:

• RPC Runtime: A library that manages the communication in RPC. It handles binding, sending/receiving data, selecting the protocol, and handling errors.

Inter-Process Communication, or IPC:

Inter-Process Communication, or IPC, is a mechanism that allows coordinating communication between different running processes (applications)

It helps processes synchronize their activities, share information, and avoid conflicts while accessing shared resources.