Model Context Protocol and MCP's Three Core Interaction Types

LLMs can chat like humans, write blogs, and even book meetings—but scaling them is a nightmare. Every new tool traditionally needs its own custom setup and code, creating a web of fragile bridges. MCP solves this by acting as a central hub: one protocol, many tools. 

Model Context Protocol is an open standard from Anthropic that lets AI applications connect to external tools and data through a single, consistent client‑server protocol. MCP exposes capabilities as tools, resources, and prompts, discovered and invoked over a standardized interface so models can act on real systems without custom one‑off connectors. Under the hood MCP uses JSON‑RPC 2.0 for message exchange, with transports like stdio for local servers and HTTP or SSE for remote ones.Enterprise‑grade authorization for HTTP transports follows OAuth 2.1 style flows, including authorization code and client credentials, so agents can act with least‑privilege tokens.

Instead of building a separate connector for every service, MCP gives the model a universal way to interact. For example, if you say, “Book a meeting with Ram,” the model knows it needs a calendar tool. It sends the request to the MCP client, which forwards it to the right server. The server books the meeting and returns the result, which the client passes back to the model. 

With MCP, it’s not just easier to build—it’s easier to trust, scale, and grow. One standard means faster integrations, stronger security, and a future-proof foundation for enterprise AI.

If the tool runs on your computer, MCP connects directly (like plugging in a cable). If the tool is online, it uses standard web methods like HTTP or Server-Sent Events. To keep things secure, MCP follows OAuth 2.1, the same system trusted by big tech platforms, so the AI only gets the exact permissions it needs—nothing more. This means safer, controlled access without exposing sensitive data.

                                                               AI ↔ MCP Client ↔ MCP Server --->Tools

• LLM at the top
• MCP Client as the orchestrator
• Three MCP Servers each linked to different icons (flight booking, calendar, and database)
• Local tools: If the tool runs on your computer, MCP connects directly using stdio (like plugging in a cable).
• Remote tools: If the tool is online, MCP uses standard web methods like HTTP or Server-Sent Events (SSE).

How it works

HTTP: The client sends a request, the server sends back a response, and the connection usually ends.Good for one-time actions like “search flights” or “get pricing.”

SSE :The client opens a single HTTP connection, and the server can keep sending updates over time without the client asking again.Perfect for real-time updates like “flight price changes,” “order status,” or “chat messages.”

How MCP Organizes Capabilities

The Model Context Protocol (MCP) changes the way AI applications connect to external systems. Instead of hardcoding integrations, MCP provides a standard interface that exposes three types of capabilities:

• Tools – Actions the AI can perform, like search flights, book a ticket, or send a message.
• Resources – Data the AI can access, such as a calendar file, PDF document, or database entry.
• Prompts – Predefined templates or instructions, for example summarize a document or generate an email.

Above mentioned  three primitives work together to create richer, more reliable experiences. Tools handle actions, resources provide information, and prompts guide the AI’s behavior. By understanding when to use each, developers gain more control and flexibility when building AI-powered applications.

This diagram above  shows that MCP acts as a central hub where three types of capabilities connect

• Prompts (user-driven),
• Resources (application-driven), and
• Tools (model-driven).

All of these flow through the MCP Server, which then interacts with external systems like APIs, databases, and services.

------

How Prompt Works in MCP :

1. User invokes a prompt
   The user asks the system to run a predefined prompt, for example:
   “Analyze project.”

2. Client sends a prompt request to MCP Server
   The client calls the MCP Server using prompts/get to retrieve the prompt definition and any dynamic content.

3. MCP Server fetches live data from external systems
   If the prompt requires context (like logs, code, or metrics), the MCP Server queries an external API or data source.

4. External API returns current data
   The external system sends back the requested information to the MCP Server.

5. MCP Server generates a dynamic prompt
   Using the fetched data, the MCP Server builds a formatted prompt message that includes real-time context.

6. Client adds the prompt to the AI model’s context
   The client injects this dynamic prompt into the model’s input so the AI can reason with updated information.

7. AI model produces the final response
   The client displays the AI’s answer to the user.

How Tool Works in MCP :

• User asks: “Calculate the sum of 100 and 50.”
• Client sends the request to the MCP Server.
• AI Model decides which tool to use (e.g., calculator_tool).
• MCP Server invokes the tool and interacts with the External System if needed(if the tool is not available locally-internal).
• Tool performs the calculation and returns the result.
• AI Model generates the final response: “The sum is 150.”

How Resource Works in MCP :

Step 1: MCP Server exposes resources

The MCP Server acts as the central hub. It makes different types of resources available to the AI application. These resources are structured pieces of data or services that the model can use.

Step 2: Resource types and their roles

The diagram shows four common resource categories:

1. RAG System (Build embeddings)

   • The server provides access to a Retrieval-Augmented Generation (RAG) system.
   • This resource helps the AI build embeddings and retrieve relevant context from large datasets.

2. Cache Layer (Store frequently used data)

   • A resource that stores commonly accessed data for quick retrieval.
   • This improves performance and reduces repeated calls to external systems.

3. Analytics (Transform & analyze)

   • A resource that processes raw data into insights.
   • For example, analyzing logs or metrics before sending them to the model.

4. Integration (Combine multiple sources)

   • A resource that aggregates data from different APIs or databases.
   • This gives the AI a unified view of information from multiple systems.

Step 3: How the AI uses these resources

• When the AI needs context (e.g., logs, historical data, or combined insights), the MCP Client requests these resources from the MCP Server.
• The server fetches or generates the resource and returns it in a structured format.
• The AI then uses this resource to improve its reasoning and generate accurate responses.

----------------------------------------

How MCP works

1. User request arrives at the LLM. The host application passes the user’s intent to the model and supplies the catalog of available MCP tools and resources from connected servers.
2. MCP client maintains connections. The host spins up one MCP client per server, performs initialization, and negotiates capabilities.
3. Tool selection and invocation. The LLM chooses a tool based on descriptions and schemas, then asks the client to call it with structured parameters. 
4. Server executes and returns results. The MCP server performs the action or fetches data and returns structured output via JSON‑RPC. 
5. LLM composes the final answer. The model uses results to respond or to continue a multi‑step workflow, optionally calling more tools until the task is complete. 
6. Optional authorization. If the server requires auth, the client follows the specified OAuth flow and receives scoped tokens before tool calls

Example : How MCP connects an LLM to flight booking tools

High level

• LLM receives the user request.
• MCP Client brokers tool calls.
• MCP Servers expose tools and data over the Model Context Protocol.
• Results flow back to the LLM, which composes the final answer for the user.

Typical servers for air booking

• Flight Search Server - route availability, schedules, fares
• Pricing Server - fare rules, taxes, ancillaries
• Booking Server - PNR creation, seat selection
• Payment Server - tokenize card, 3DS, capture
• Loyalty Server - miles accrual, status rules
• Notifications Server - email or SMS itinerary
• Calendar Server - add travel to calendar
• Data Store Server - cache, user profile, past trips

Step by step booking flow

1. User: “Book BLR to SFO next Friday, return Tuesday, aisle seat, use miles if cheaper.”
2. LLM interprets intent and constraints.
3. MCP Client orchestrates calls:
   • Flight Search Server: search BLR ↔ SFO, date constraints
   • Pricing Server: evaluate fares, fare families, baggage, refundability
   • Loyalty Server: compare miles redemption vs cash
4. LLM ranks options and asks user to confirm.
5. On confirmation:
   • Booking Server: create PNR, select seats
   • Payment Server: charge or redeem miles
   • Notifications Server: send ticket and receipt
   • Calendar Server: add flights to calendar
6. MCP Client returns structured results to LLM.
7. LLM produces the final answer with itinerary details.

Why MCP works well  in this scenerio 

• Standard protocol for tool discovery and capabilities
• Secure, isolated tool execution with clear inputs and outputs
• Composable servers so you can add or swap providers without changing the LLM logic

Why MCP is Required for Scaling LLMs

When LLMs grow in size and capability, they need to interact with more tools, data sources, and systems. Without a standard protocol, every integration becomes a custom job, which is hard to maintain and slows down scaling. MCP solves this by:

• Standardizing communication: Instead of building one-off connectors for each tool, MCP provides a universal protocol (JSON-RPC) for all tools.
• Dynamic capability discovery: LLMs can automatically learn what tools are available and what they can do, without hardcoding.
• Secure and controlled access: OAuth-based authorization ensures least-privilege access, which is critical when scaling across enterprise environments.
• Local and remote flexibility: MCP supports both local tools (via stdio) and remote services (via HTTP/SSE), making it easy to scale from desktop to cloud.

How MCP Enables Scaling

• Plug-and-play architecture: Add new servers without changing the LLM logic.
• Reduced context overhead: Instead of dumping thousands of tool definitions into the model’s prompt, MCP lets the client manage them efficiently.
• Ecosystem growth: As more MCP servers are built, LLMs can instantly leverage them—accelerating feature expansion.

Why MCP is better than ad‑hoc tool wrappers

• One protocol. Fewer integrations. MCP reduces the N×M mess of per‑service connectors to a single standard that any client can speak and any server can implement. 
• Clear capability discovery. Clients list server tools and resources using uniform schema so the LLM can reason about what to call and with which parameters. 
• Vendor‑neutral ecosystem. MCP is open, with SDKs and many reference servers, and is used by multiple apps, which avoids lock‑in and speeds reuse.
• Secure by design. Standardized auth and transport guidance, plus emerging enterprise controls that monitor MCP traffic and enforce least‑privilege access.
• Operational efficiency. New techniques like MCP code‑execution patterns reduce token overhead compared to dumping thousands of tool definitions into context.
• Usable locally. Desktop extensions package local MCP servers for one‑click install, which makes private data integrations accessible without complex setup

Conclusion : If your roadmap includes broader agent capabilities, more systems, and stronger guardrails, MCP is the foundation that turns one‑off integrations into an extensible platform. It gives LLMs a clear, secure, and efficient way to access the real world, which is exactly what you need to scale from prototypes to production