Search⌘ K
AI Features
Home
Courses
Mastering MCP: Building Advanced Agentic Applications

Introduction to MCP and Its Architecture

Explore the fundamentals of the Model Context Protocol (MCP) and its architecture in this lesson. Understand how MCP standardizes AI interactions using a client-server model, enabling seamless, modular, and secure connections between AI agents and external tools or data sources. Learn the roles of MCP clients and servers, along with the core components: tools, resources, and prompts, to build scalable, context-aware AI systems.

We'll cover the following...

Suppose an AI assistant needs to coordinate several everyday tasks. It should check the calendar for available time slots, place a grocery order through an online service, and send a confirmation message to a friend. The workflow appears straightforward, but the integration work is not. Without a shared interface or protocol, the system requires multiple custom integrations, each using a different API, authentication model, and data format for the calendar, grocery, and messaging services.

MCP addresses this integration problem by standardizing how AI applications connect to external tools and data sources. It defines a standard protocol for exposing tools, resources, and other capabilities to AI applications. Instead of coupling each AI application directly to every service-specific integration, MCP lets applications interact with MCP-compatible services through a consistent interface. This can reduce integration complexity and duplicated work while making tools and resources easier to reuse across different AI applications.

What is Model Context Protocol (MCP)?

At its core, the Model Context Protocol (MCP) operates on a principle that has been the backbone of the internet for decades: the client-server architecture. This is the same fundamental model we use every day when we check our email or browse a website.

In a traditional client-server setup:

  • A client (like our web browser or email application) requests information or a service.

  • A server (a powerful computer that stores the website’s files or our emails) processes that request and sends back a response.

A classic client ↔ server request/response flow
A classic client ↔ server request/response flow

Following this same proven model, the MCP standardizes how AI agents and language models communicate with the outside world. Before MCP, connecting an AI to a new tool or data source required a brittle, one-off integration. MCP introduces a common language, much like how HTTP is a common language for web browsers and servers.

In the MCP ecosystem:

  • The MCP host is the application where the AI model runs (e.g., a chatbot interface, AI agents, IDEs).

  • The MCP client resides within the host and is responsible for making requests to external tools and data sources. It acts on behalf of the AI model and maintains 1:1 connections with the server while residing inside the host.

  • The MCP server exposes an external tool or data source (like a database, API, or local file system). It serves information and capabilities to the client in a standardized format that the AI can understand.

By adopting this client-server architecture, MCP brings several key advantages to AI development:

  • Standardization and scalability: Developers no longer need to build unique connectors for every tool. A tool with an MCP server can seamlessly connect with any AI application that functions as an MCP client.

  • Modularity and flexibility: AI models can easily swap out or add new tools without significant re-engineering. This modularity allows for more powerful and adaptable AI systems.

  • Security: The protocol establishes clear boundaries and rules for data exchange, enhancing the security of the interactions between AI and external resources.

In essence, MCP takes the robust and scalable client-server concept and tailors it to the specific needs of AI, creating a standardized plug-and-play environment for connecting models to the vast world of external data and tools.

The architectural advantage of MCP

While the benefits of standardization and modularity are clear, it raises a crucial architectural question: if an agent can be programmed to call an API directly, why introduce the intermediary of an MCP server?

Without MCP, the AI application would need separate integration logic for the calendar, grocery, and messaging APIs. The application layer would need to manage multiple API clients, each with its own authentication flow, request and response formats, and error-handling behavior. This creates tight coupling between the application and each service API. If the grocery API changes an endpoint or request format, the corresponding integration code must be updated. The calendar integration may also be tightly coupled to this application, making it harder to reuse across other AI systems.

MCP addresses this by introducing a standard abstraction between AI applications and external services. Instead of coupling the agent to each service-specific API, the application can use the MCP interface to access capabilities exposed by different servers. The MCP server handles the service-specific integration details and communicates with the underlying API or service. It can then expose those capabilities through MCP constructs such as tools or resources. This separation of concerns can improve modularity, reuse, and maintainability. Next, let’s examine the core building blocks of the MCP protocol.

While agentic AI can accomplish tasks without MCP, incorporating MCP streamlines the process. This makes it easier, more scalable, and less prone to errors through standardization.

How MCP actually works

MCP defines three core components that determine how AI applications access context and interact with external capabilities.

  • Tools: Tools are the action-oriented functions the agent can execute. Think of them as verbs; they actively do something, like creating a calendar entry, sending an email, or updating a database record.

  • Resources: Resources, on the other hand, are read-only sources of information, essentially the nouns in the conversation. They allow the agent to retrieve data for context, such as getting a list of files in a folder or reading today’s meeting schedule.

  • Prompts: Prompts are pre-defined recipes for interaction that reside on the server. They provide an optimized and reusable way to perform common tasks, saving users from the overhead of complex prompt engineering.

Tools, resources, and prompts
Tools, resources, and prompts

Defining a tool

MCP provides software development kits (SDKs) in various languages that make defining these primitives incredibly simple. When creating a tool on an MCP Server, we typically just write a standard function and then use a special decorator to register it with the protocol.

A decorator marks a function for registration with the MCP server. It identifies the function as an MCP tool that clients can discover and invoke. The SDK handles tool registration, discovery metadata, and invocation routing, exposing the tool to clients and dispatching incoming calls to the function.

We’ll be using MCP’s Python SDK throughout this learning journey.

Here’s an example of how we might define a simple subtract tool using the Python MCP SDK:

import logging
logger = logging.getLogger(__name__)
@mcp.tool()
def subtract(a: int, b: int) -> int:
  """
  Subtracts the second number from the first.
  Args:
    a: The number to subtract from.
    b: The number to subtract.
  Returns:
    The difference between the two numbers.
  """
  logger.info(f"Executing 'subtract' tool with {a} and {b}")
  return a - b
Defining a simple tool in MCP

In this code, the @mcp.tool() decorator automatically makes the subtract function discoverable and callable by any connected MCP client. The function’s type hints (a: int) and docstring are also used by the protocol to tell the client what parameters the tool expects, and what it does.

Defining a resource

Similar to tools, resources are defined on the MCP Server using a decorator. We simply define a function that returns the data, and the @mcp.resource() decorator makes it available. This example shows a resource, which is a static endpoint that always returns the same piece of information when called.

@mcp.resource(
    "system://status",
    mime_type="application/json"
)
def get_system_status():
  """
  Returns the current status and version of the server.
  """
  return {
      "status": "online",
      "version": "1.2.0",
      "server_time": datetime.datetime.now().isoformat()
  }
Defining a resource in MCP

Here, the @mcp.resource() decorator registers the get_system_status function. When a client requests the system://status resource, the server will execute this function and return the JSON object containing the system’s current status and version.

Defining a prompt

Like tools and resources, prompts are defined using a decorator on the MCP Server. The function signature indicates the required inputs for the prompt and specifies that it will return a list of messages.

This example shows a prompt designed to summarize a given piece of text:

@mcp.prompt(
    name="summarize",
    description="Summarizes a long piece of text into a few key bullet points."
)
def summarize_text(
    text_to_summarize: str
) -> list[base.Message]:
  """Generates a prompt to summarize the provided text."""
  # This function returns a list of messages for the LLM.
Defining a prompt in MCP

This code registers a server-side prompt named summarize that generates a list of messages to guide an AI in summarizing text.

MCP provides a standard way to connect AI applications with external tools and data, reducing the integration complexity involved in building agentic AI systems. Its client-server architecture reduces the need for application-specific integrations and provides a consistent interface that can improve interoperability and reuse. Through its core primitives, tools, resources, and prompts, developers can build more modular applications with reusable integrations. MCP provides a common protocol that allows AI agents to interact with external tools, services, and data sources.

Quick quiz

1.

You need to expose a read-only search over your company’s documents so an AI model can look things up. The search takes a query string and returns matching passages. How should you define it on the MCP server?

A.

As a resource, because it is read-only and read-only operations are always resources.

B.

As a tool, because it takes parameters and the model invokes it on demand.

C.

As a prompt, because it helps the model answer questions

D.

As a resource, because HTTP GET requests never change data.

1 / 3