The genesis of the Model Context Protocol (MCP) lies in addressing a fundamental and pervasive challenge in the development of applied AI: the integration of external context. While Large Language Models (LLMs) like Claude possess an extraordinary amount of general knowledge learned from vast training datasets, their true power is unlocked when they can interact with specific, timely, and often private information from external systems. This includes everything from searching a corporate database and calling a third-party API to reading a local file or scraping a live webpage. Without this context, an LLM is a brilliant but isolated brain. The core problem has been the how of this integration. Traditionally, developers have resorted to writing custom, hard-coded integrations for every tool and data source an AI application needs. If a chatbot needs to query a Salesforce API and a Google Calendar API, a developer would write two distinct pieces of "glue code," one for each service. This code would handle authentication, request formatting, response parsing, and error handling specific to each API.

This traditional approach suffers from several critical drawbacks that collectively lead to a fragmented and inefficient development landscape. Firstly, it results in a massive duplication of effort. A team building a customer support bot and another team building an internal sales assistant might both need to interact with Salesforce. In a pre-MCP world, both teams would likely build their own separate integrations, wasting valuable development time. Secondly, this approach creates brittle and high-maintenance systems. If Salesforce updates its API, every single application with a custom integration needs to be found and updated individually. This maintenance burden grows exponentially as the number of tools and applications increases. Thirdly, it stifles innovation and collaboration. The custom integrations are tightly coupled to the application they were built for, making them difficult to share, reuse, or open-source. A brilliant tool for interacting with the ArXiv academic database, built for one specific project, remains locked within that project's codebase, inaccessible to the wider community.

MCP was created to dismantle these silos. It introduces a standardized layer of communication, an "lingua franca," between AI applications and the tools they consume. Instead of the AI application talking directly to a dozen different APIs in a dozen different languages, it talks to all of them using one consistent protocol: MCP. The tools, in turn, are wrapped in MCP servers that translate MCP requests into actions on their specific underlying systems. This fundamental shift from a tightly-coupled, many-to-many integration mess to a decoupled, standardized client-server model offers transformative benefits. It promotes modularity and reusability; a single MCP server for Salesforce can be built once and used by any MCP-compatible application within a company. It drastically reduces maintenance overhead; if the Salesforce API changes, only the single MCP server needs to be updated, and all client applications will continue to work seamlessly. Most importantly, it fosters a collaborative ecosystem. Developers can now build and share MCP servers as standalone, reusable components. This opens the door for a public or private registry of MCP servers, allowing an AI application to dynamically discover and connect to a vast array of tools with minimal integration effort, making AI development faster, more scalable, and significantly less fragmented.

The Model Context Protocol (MCP) is founded on a classic and robust client-server architecture. This design pattern is deliberately chosen for its simplicity, scalability, and clear separation of concerns. It decouples the AI application, which consumes context, from the external systems that provide that context. The architecture consists of two primary components: the MCP Client and the MCP Server, which communicate over a standardized protocol.

MCP Architecture Diagram

graph LR
  subgraph "User's Device"
      User(👤 User)
      App["AI Application"]
      LLM[("LLM Core (e.g., Claude)")]
  end

  subgraph "MCP Server Ecosystem (Local or Remote)"
      Server["MCP Server (e.g., ArXiv Search)"]
  end

  External[("🌐 External API / Service")]
  
  User -- "1. Prompt: 'Find papers on AI'" --> App
  App -- "2. MCP Client receives prompt" --> LLM
  LLM -- "3. LLM decides to use a tool" --> App
  App -- "4. MCP Request 📞" --> Server
  Server -- "5. Executes logic (e.g., calls external API)" --> External
  External -- "6. API Response" --> Server
  Server -- "7. MCP Response 📦" --> App
  App -- "8. Passes result to LLM" --> LLM
  LLM -- "9. LLM processes result and generates answer" --> App
  App -- "10. Final Answer" --> User

  style User fill:#0c172b,stroke:#333,stroke-width:2px
  style App fill:#31b1b5,stroke:#0f0f0f,stroke-width:2px
  style LLM fill:#78401a,stroke:#00bcd4,stroke-width:2px
  style Server fill:#702bba,stroke:#0f0f0f,stroke-width:2px
  style External fill:#0a6141,stroke#0f0f0f,stroke-width:2px

Core Components:

1. MCP Client: The MCP Client is a component that resides inside the AI application. It acts as the intermediary between the LLM's reasoning engine and the network of MCP servers. Its primary responsibilities are:

   • Server Discovery and Connection: The client is configured with the addresses of one or more MCP servers. Upon connection, it sends a request to each server to fetch its "manifest" or capabilities. This manifest details the tools, resources, and prompt templates the server offers, including their names, descriptions, and input/output schemas.
   • Request Formulation: When the LLM decides it needs to use an external tool (a process often called "tool use" or "function calling"), the client takes the LLM's intent (e.g., "read the file 'report.md'") and formulates a structured MCP request. This request is a standardized message, likely in a format like JSON-RPC, specifying the tool to be called (readFile) and its parameters (path: 'report.md').
   • Communication: The client sends this request to the appropriate MCP server over the network (or locally via a subprocess).
   • Response Handling: The client waits for the server's response, parses the standardized MCP response message, and extracts the result (e.g., the content of 'report.md'). This result is then passed back to the LLM, which uses the new information to continue its task or formulate a final answer for the user. The key is that the client is generic; it doesn't need to know how to read a file, only how to ask an MCP server to do so according to the protocol.

2. MCP Server: The MCP Server is a standalone process that exposes a set of capabilities to any MCP client. It can be a simple script running locally on the same machine or a robust web service deployed in the cloud. Its responsibilities are the mirror image of the client's:

   • Exposing Capabilities: The server's core function is to define and implement a set of tools, resources, and/or prompt templates. For example, a filesystem server would implement functions like readFile, writeFile, and listFiles.
   • Serving the Manifest: When a client connects, the server responds with its manifest, advertising its available capabilities. This allows the client (and by extension, the LLM) to know what it can do.
   • Listening for Requests: The server listens for incoming MCP requests from clients.
   • Execution and Logic: Upon receiving a valid request, the server invokes the corresponding tool's implementation. For a readFile request, it would interact with the operating system's filesystem. For a search_papers request on an ArXiv server, it would make an HTTP request to the actual ArXiv API.
   • Response Formulation: After executing the tool, the server packages the result (or any error that occurred) into a standardized MCP response message and sends it back to the client. This completes the request-response cycle.

The communication between them is the protocol itself, defining the exact structure of request and response messages for discovering capabilities, calling tools, fetching resources, and handling errors. This rigid standardization is what enables the entire ecosystem to function seamlessly.

To fully appreciate the transformative impact of MCP, let's consider a practical, step-by-step example: building a chatbot designed to assist researchers. The initial goal for this chatbot is to allow a user to ask questions about recent academic papers on ArXiv, a popular open-access archive for scholarly articles.

Phase 1: The Pre-MCP, Monolithic Chatbot

In a traditional development approach, we would build this functionality directly into the chatbot's codebase. The application's logic would look something like this:

1. User Input: The user types a prompt: "Find me recent papers on 'causal inference'."
2. LLM Invocation with Hard-coded Tools: The chatbot's backend code would be designed to recognize the intent to search for papers. It would have a specific Python function, say search_arxiv_directly(query: str), defined within its own source code. The LLM would be prompted in a way that encourages it to "call" this specific, known function.
3. Custom Integration Logic: The search_arxiv_directly function would contain all the necessary logic to interact with the ArXiv API. This includes:
   • Constructing the correct HTTP request URL with the user's query.
   • Making the HTTP GET request using a library like requests.
   • Handling potential network errors (timeouts, connection issues).
   • Parsing the XML or JSON response from the ArXiv API.
   • Extracting the relevant information (titles, authors, summaries) for each paper.
   • Formatting this data into a clean string or data structure.
4. Returning Context to LLM: The formatted list of papers is then passed back into a subsequent prompt for the LLM.
5. Final Response Generation: The LLM receives the search results and synthesizes a natural language response for the user, such as: "I found three recent papers on causal inference. The first is titled 'A New Approach to...' by..."

This chatbot works, but it's brittle and inflexible. If we now want to add a new feature to search for papers on PubMed, we have to go back into the chatbot's core code, write a new function search_pubmed_directly, and repeat the entire process of writing custom integration logic. The chatbot's codebase becomes increasingly bloated and tightly coupled to the specific tools it uses.

Phase 2: Transforming the Chatbot into an MCP-Compatible Application

Now, we refactor our application to use MCP. The goal is to decouple the chatbot's core logic from the tool's implementation.

1. Create an MCP Server: First, we take the logic from our search_arxiv_directly function and move it into a completely separate application: an ArXiv MCP Server. This server's sole job is to expose one tool: search_academic_papers(query: str). We use a framework like FastMCP to easily wrap our existing logic, which handles all the protocol-level communication for us. We run this server (it could be locally or remotely).
2. Modify the Chatbot to be an MCP Client: Next, we modify the chatbot itself. We completely remove the search_arxiv_directly function and its custom integration code. In its place, we add a generic MCP Client.
3. The New Workflow: The user interaction now looks different under the hood:
   • User Input: "Find me recent papers on 'causal inference'."
   • MCP Discovery: At startup (or dynamically), our chatbot's MCP Client connects to the ArXiv MCP Server's address. It asks the server for its capabilities and learns that a tool named search_academic_papers exists, which takes a query string as input and is described as "Searches the ArXiv database for academic papers."
   • LLM Invocation with Discovered Tools: The chatbot now presents this dynamically discovered tool information to the LLM. The LLM's reasoning engine sees the user's request and determines that the search_academic_papers tool is the perfect fit. It decides to call this tool with the parameter query='causal inference'.
   • Client-Server Communication: The MCP Client takes this instruction, creates a standardized MCP request, and sends it to the ArXiv MCP Server.
   • Server Execution: The ArXiv MCP Server receives the request, calls its internal implementation (the logic we moved), interacts with the ArXiv API, and sends the formatted results back in a standardized MCP response.
   • Context and Response: The MCP Client passes the results back to the LLM, which then generates the final answer for the user, just as before.

The magic here is that the chatbot's code no longer contains any specific knowledge about ArXiv. It only knows how to speak MCP. If we now want to add PubMed search, we don't touch the chatbot at all. We simply create a new PubMed MCP Server and tell our chatbot's client its address. The chatbot will automatically discover the new search tool and make it available to the LLM, demonstrating the power of modularity and dynamic tool integration.

Creating an MCP server is the process of taking a set of functionalities—whether it's interacting with an API, a database, or a local filesystem—and exposing them to the world through the standardized Model Context Protocol. This is a pivotal skill in the MCP ecosystem, as servers are the fundamental building blocks that provide context to AI applications. This course module focuses on the practical steps of building, testing, and running your own server, using specialized frameworks like FastMCP to abstract away the low-level complexities of the protocol itself. The process can be broken down into a clear, logical sequence of steps.

Step 1: Defining the Capabilities (The "What") Before writing any code, the first step is to conceptualize what your server will do. You need to define the specific tools, resources, and prompt templates it will offer. For our ArXiv chatbot example, the primary capability is a tool. We would define it as follows:

• Tool Name: search_academic_papers
• Description: "A tool to search the ArXiv.org database for academic papers based on a query string. Returns a list of recent papers with their titles, authors, and summaries." This description is crucial, as it's what the LLM will use to understand when and how to use the tool.
• Input Schema: The tool requires one argument, query, which is of type string.
• Output Schema: The tool will return a list of objects, where each object contains title (string), authors (list of strings), and summary (string). Defining this "interface" first is a critical design step. It forces you to think clearly about the server's purpose and how it will be used by a client.

Step 2: Implementing the Core Logic (The "How") This is where you write the actual code that performs the work. This is the logic that we previously had embedded inside our monolithic chatbot. You would write a Python function, for instance, def execute_arxiv_search(query: str) -> list:. Inside this function, you would place all the code responsible for:

1. Sanitizing the input query.
2. Constructing the appropriate URL for the ArXiv API.
3. Using an HTTP client library (requests, httpx) to make the API call.
4. Implementing robust error handling (e.g., what happens if ArXiv is down? What if the query returns no results?).
5. Parsing the complex response from the API (which might be in XML or another format).
6. Transforming the parsed data into the clean, simple output structure you defined in Step 1. This core logic is pure functionality; at this stage, it has no knowledge of MCP. It's a self-contained, testable piece of code.

Step 3: Wrapping the Logic with an MCP Framework (The "Serverization") This is where a framework like FastMCP comes into play. Instead of manually implementing a web server, parsing raw MCP requests, and formatting MCP responses (which would be tedious and error-prone), you use the framework to do the heavy lifting. The process typically looks like this:

1. Instantiate the Server: You create an instance of the FastMCPServer.
2. Register the Tool: You "register" your core logic function with the server instance. This involves telling the framework about your tool—its name, description, schemas, and which function to call when the tool is invoked. A framework might use decorators or a registration function, like server.add_tool(name="search_academic_papers", description=..., func=execute_arxiv_search).
3. Run the Server: You start the server with a single command, like server.run(host="0.0.0.0", port=8000). The FastMCP framework automatically handles the rest. It will start a web server, create an endpoint that listens for MCP requests, serve the manifest (based on the tools you registered), parse incoming tool call requests, invoke your execute_arxiv_search function with the correct parameters, take the return value, and wrap it in a valid MCP response to send back to the client.

Step 4: Testing the Server (The "Verification") Once your server is running, you need to verify that it's behaving correctly. This is where a tool like the MCP Inspector becomes invaluable. The MCP Inspector is a specialized MCP client designed for debugging. You would point the Inspector at your server's address (e.g., http://localhost:8000). It will first attempt to fetch the server's manifest, allowing you to see if your tool is advertised correctly. Then, you can use the Inspector's UI to manually invoke your search_academic_papers tool, providing a test query. You can inspect the raw MCP request being sent and, most importantly, the raw MCP response coming back, ensuring that your server is fully compliant with the protocol before you even connect it to a real AI application. This iterative cycle of building, running, and testing is key to developing reliable MCP servers.

If an MCP server is the provider of context, the MCP client is the consumer. Creating an MCP client involves integrating a specialized component into your AI application (like our researcher chatbot) that enables it to communicate with any MCP-compliant server. The beauty of this architecture is that the client code you write is generic. It doesn't need to know the specifics of any particular tool, such as how to search ArXiv or how to read a file. It only needs to understand the language of MCP—how to discover capabilities, how to request a tool execution, and how to interpret the response. This module of the course focuses on building this client-side logic, which effectively turns your application into a gateway to the entire MCP ecosystem.

The responsibilities of an MCP client can be structured into a distinct lifecycle:

1. Initialization and Configuration: The first step is to initialize the client within your application. This typically involves creating an instance of a client class from an MCP library. The primary configuration required is a list of server addresses. This list tells the client where to look for tools and resources.

# Pseudocode for client initialization
mcp_server_urls = [
    "http://localhost:8000",  # Our local ArXiv server
    "[http://mcp.anthropic.com/filesystem](http://mcp.anthropic.com/filesystem)", # A public reference server
]
mcp_client = MCPClient(servers=mcp_server_urls)

This configuration can be static, loaded from a file, or even discovered dynamically, but the core idea is to provide the client with entry points into the MCP network.

2. Capability Discovery and Manifest Aggregation: Once initialized, the client's first action is to connect to each configured server and request its manifest. The manifest is a JSON object detailing all the tools, resources, and prompts offered by that server. The client's job is to:

• Iterate through each server URL.
• Send a standardized MCP request to each one (e.g., a GET /mcp request or a specific RPC call like mcp_getServerInfo).
• Receive and parse the manifest from each server.
• Aggregate all these capabilities into a single, unified list. This aggregated list represents the total set of external tools available to the AI application. This discovery process is vital because it's what makes the system dynamic. When you add a new server to the configuration list, its tools automatically appear in this aggregated list without any other code changes. The client creates a comprehensive "menu" of available actions for the LLM.

3. Presenting Tools to the LLM: The LLM cannot use tools it doesn't know about. The client's next critical role is to format the aggregated list of tools into a structure that the LLM can understand. This is typically done by injecting the tool descriptions into the system prompt. For each tool discovered, the client will format a description block, including its name, a natural language description of what it does, and its input parameters. For example:

<tools>
  <tool>
    <name>search_academic_papers</name>
    <description>Searches the ArXiv.org database for academic papers...</description>
    <parameters>
      <param name="query" type="string" />
    </parameters>
  </tool>
  <tool>
    <name>readFile</name>
    <description>Reads the content of a file from the local filesystem...</description>
    <parameters>
      <param name="path" type="string" />
    </parameters>
  </tool>
</tools>

When the user interacts with the chatbot, this block of XML (or a similar format) is included in the prompt, effectively telling the LLM, "Here are the external capabilities you have at your disposal."

4. Handling Tool Use Requests from the LLM: Modern LLMs like Claude can be prompted to indicate when they want to use a tool. When the LLM decides to make a tool call, its response will contain a special structure indicating which tool to use and with what arguments. For instance, the LLM's output might contain:

<invoke_tool>
  <name>search_academic_papers</name>
  <parameters>
    <query>causal inference</query>
  </parameters>
</invoke_tool>

The application code, which is monitoring the LLM's output, will detect this structure. It then passes this information to the MCP client.

5. Executing the Tool Call via MCP: This is the core communication step. The MCP client receives the tool invocation request from the application. It then:

1. Identifies which server provides the requested tool (search_academic_papers). It knows this from the discovery phase.
2. Constructs a formal MCP tool-call request message (e.g., a JSON-RPC object).
3. Sends this request to the correct server's URL.
4. Awaits the server's response.
5. Parses the MCP response to extract the result of the tool execution.
6. Returns this result to the main application logic. The application then feeds this result back into the LLM for the final step, completing the loop. This cycle of discovery, presentation, invocation, and execution is the essence of a functioning MCP client.

This is the module where the true power and elegance of the Model Context Protocol become strikingly apparent. After successfully building a custom MCP server (for ArXiv search) and integrating a generic MCP client into our chatbot, we can now demonstrate the protocol's primary benefit: effortless extensibility. Connecting our chatbot to new, pre-existing servers requires no changes to the chatbot's core logic or its custom ArXiv server. The only change required is to update the list of server URLs in the MCP client's configuration. This showcases the remarkable decoupling and interoperability that MCP enables. The course uses reference servers built by Anthropic's MCP team to illustrate this concept, with two prominent examples being the filesystem server and the fetch server.

1. The Filesystem Server

The filesystem server is an MCP server designed to expose basic file system operations as tools. When our chatbot's MCP client is configured with the address of this server, it will automatically discover a new set of tools during its initialization phase. These tools might include:

• readFile(path: string): Reads the entire content of a file at a given path.
• writeFile(path: string, content: string): Writes or overwrites a file with the provided content.
• listFiles(path: string): Lists all files and directories within a given path.
• createDirectory(path: string): Creates a new directory.

Impact on the Chatbot: Suddenly, our researcher chatbot, which was previously only capable of searching the web for academic papers, gains a whole new dimension of interactivity. The LLM, being aware of these newly discovered tools via the system prompt, can now fulfill a much wider range of user requests. The user can now have conversations like:

• User: "Find me papers on 'transformer architectures', and save the results to a file named transformers_reading_list.md."
• Chatbot's Internal Process:
  1. LLM sees the request and decides to first use the search_academic_papers tool.
  2. The MCP client calls our ArXiv server, gets the results.
  3. The results are fed back to the LLM. The LLM now sees the second part of the request.
  4. LLM formats the paper list into Markdown and decides to use the writeFile tool.
  5. The MCP client calls the filesystem server with path='transformers_reading_list.md' and the formatted content.
  6. The file is created on the local disk.
  7. The LLM confirms to the user: "I have found the papers and saved the list to transformers_reading_list.md."

Without writing a single new line of integration code in the chatbot, we have seamlessly extended its capabilities.

2. The Fetch Server

The fetch server is another powerful reference tool. Its purpose is to retrieve content from the web. It might expose a single, versatile tool:

• fetch(url: string): Takes a URL, fetches the content of the web page, and intelligently extracts the main body of text, often converting it to clean Markdown and stripping away ads, navigation bars, and other boilerplate.

Impact on the Chatbot: By simply adding the fetch server's address to our client's configuration, our chatbot's abilities expand yet again. It can now act as a research assistant that can not only find papers but also read and summarize web articles.

• User: "Here is a link to a blog post about a new AI model: [some-url]. Can you summarize its key points and then find related academic papers?"
• Chatbot's Internal Process:
  1. LLM sees the URL and decides to use the fetch tool.
  2. The MCP client calls the fetch server with the URL.
  3. The server scrapes the page and returns the article's content as clean Markdown.
  4. The LLM receives the content and generates a summary for the user.
  5. It then identifies keywords from the summary and decides to use the search_academic_papers tool.
  6. The MCP client calls our ArXiv server.
  7. The LLM synthesizes the final response, presenting both the summary of the blog post and a list of related papers.

This module powerfully demonstrates that the value of an MCP-compatible application grows with the ecosystem. By building a single, generic MCP client, our chatbot is future-proofed, ready to connect to and leverage any number of current and future MCP servers for databases, calendars, code execution, and more, all with minimal to no additional development effort.

While dynamic tool use is arguably the most prominent feature of MCP, the protocol's capabilities extend beyond simple function calls. MCP provides a standardized way for servers to offer two other crucial types of context: Prompt Templates and Resources. This module delves into these features, showcasing how they enable more sophisticated, maintainable, and context-rich interactions between the LLM and external systems. By leveraging prompts and resources, developers can centralize and reuse expert knowledge, moving it from being hard-coded in individual applications to being discoverable and shareable via MCP servers.

1. Prompt Templates

Prompt engineering is a critical discipline in getting the best performance from LLMs. Crafting the perfect prompt for a specific task—like summarizing a legal document versus summarizing a casual blog post—can be complex and require significant expertise. In a large organization, multiple different AI applications might need to perform the same summarization task. Without MCP, each development team would likely create and embed their own version of the summary prompt within their application's code. This leads to inconsistency, duplicated effort, and difficulty in updating and improving these prompts centrally.

MCP's prompt template feature solves this problem. An MCP server can be designed to expose pre-defined, expert-crafted prompt templates.

• How it Works: Our ArXiv server, for example, could be enhanced to offer a prompt template named academic_summary_prompt. This wouldn't be a tool to be executed, but rather a string template that the client can request.
• Server-Side: The server's manifest would advertise this prompt template. The server stores the template text, which might look something like this: "You are an expert academic researcher. Based on the following paper abstract: {abstract}, please provide a concise, one-paragraph summary focusing on the methodology and key findings. Avoid jargon where possible."
• Client-Side: The MCP client discovers this available prompt. The AI application's logic can then be designed to request this template by name. The client sends a getPromptTemplate request to the server, and the server returns the template string. The application can then fill in the {abstract} placeholder with the actual abstract from a paper and send the completed prompt to the LLM.

Benefits:

• Centralization and Consistency: All applications that need to summarize academic papers can use the exact same, expert-approved prompt, ensuring consistent output quality.
• Easy Updates: If a prompt engineer discovers a better way to phrase the summary prompt, they only need to update it in one place: the MCP server. All client applications will automatically start using the improved prompt on their next request, without requiring any code changes or redeployments.
• Expertise Encapsulation: A subject-matter expert (e.g., a lawyer) who is not a programmer can contribute to the AI system by crafting high-quality prompts and making them available through an MCP server.

2. Resources

Resources are another powerful feature for providing static or semi-static context to an LLM. A resource is essentially a named blob of text or data that a server exposes for retrieval. This is ideal for information that doesn't require execution like a tool but is necessary for the LLM to perform its task accurately.

• How it Works: Imagine we have an internal company MCP server. This server could expose several resources:
  • company_faq.txt: A text file containing the company's frequently asked questions.
  • style_guide.md: A Markdown document outlining the company's official communication style.
  • api_documentation.json: A JSON file containing the schema for an internal API.
• Server-Side: The server's manifest lists these available resources by name. The server itself simply holds these files or data blobs, ready to serve them upon request.
• Client-Side: An AI application, such as an internal support bot, can be prompted to answer a user's question. If the LLM determines it needs more information, it can request a resource. For example, if a user asks, "What is our policy on remote work?", the LLM can decide to retrieve the company_faq.txt resource. The MCP client sends a getResource request to the server, which returns the full text of the FAQ. This text is then fed into the LLM's context window, allowing it to formulate an accurate, up-to-date answer based on the official company document.

Benefits:

• Grounding LLMs in Factual Data: Resources are a primary mechanism for "grounding" an LLM, reducing the risk of hallucination by providing it with specific, authoritative documents to base its answers on.
• Separation of Data and Logic: The data (the FAQ) is managed on the server, completely separate from the AI application's code. The content can be updated easily without touching the application.
• Efficient Context Provision: It's more efficient to have the LLM dynamically pull in a specific resource when needed, rather than trying to stuff all possible information into its initial context window.

While a significant portion of the course focuses on building MCP clients from the ground up within your own applications, this module explores a powerful alternative: leveraging pre-built, sophisticated MCP clients. Claude Desktop serves as a prime example of such an application. It is a feature-rich, standalone AI assistant that is already fully MCP-compatible. This means that instead of writing your own client-side code to manage server connections, discover tools, and handle communication, you can simply "plug in" your custom-built MCP servers directly into a ready-made, professional-grade application. This approach dramatically lowers the barrier to entry for utilizing your custom tools and demonstrates the power of the MCP ecosystem, where a single tool server can be used by a multitude of different client applications.

The core concept here is the separation of the tool provider (your MCP server) from the tool consumer (the AI application). By adhering to the MCP standard, your ArXiv server doesn't care if it's being called by the simple chatbot we built earlier or by a complex application like Claude Desktop. It speaks the same language to both. This module teaches you the practical steps of making that connection happen.

The Configuration Process: The process of configuring Claude Desktop to use your servers is designed to be straightforward, typically involving a settings file or a graphical user interface.

1. Locating the Configuration File: You would first need to find the configuration file for Claude Desktop on your local machine. This is often a JSON or YAML file located in a standard application data directory.
2. Adding Server Endpoints: Inside this configuration file, there will be a specific section for defining MCP servers. You would simply add the network addresses of the servers you want Claude Desktop to connect to. For instance, you would add the URL of the ArXiv server you built and deployed locally (http://127.0.0.1:8000) and perhaps the public URLs for the reference filesystem and fetch servers.

// Example snippet from a hypothetical Claude Desktop config file
"mcp_servers": [
  {
    "url": "[http://127.0.0.1:8000](http://127.0.0.1:8000)",
    "name": "Local ArXiv Search",
    "enabled": true
  },
  {
    "url": "[https://mcp.anthropic.com/filesystem](https://mcp.anthropic.com/filesystem)",
    "name": "Anthropic Filesystem Server",
    "enabled": true
  }
]

3. Restarting and Verification: After saving the configuration changes, you would restart Claude Desktop. Upon startup, Claude Desktop's built-in MCP client will perform the discovery process we learned about earlier. It will connect to http://127.0.0.1:8000, fetch the manifest, and learn about your search_academic_papers tool.

The User Experience: From this point forward, when you interact with Claude Desktop, it will be fully aware of your custom tool. You can now type directly into the Claude Desktop interface: "Find me the latest papers by Yoshua Bengio." Claude Desktop's powerful LLM backend will see this prompt, recognize that the search_academic_papers tool (which it discovered from your local server) is the appropriate tool to use, and execute it. The request will be sent from Claude Desktop to your locally running server, which will perform the search and return the results. Claude Desktop will then present these results to you in its native interface.

Why This is Important: This capability is transformative for several reasons:

• Rapid Prototyping and Testing: You can quickly test your new MCP server with a powerful, stable client without needing to write a single line of client-side code. This allows you to focus solely on perfecting your server's logic.
• Empowering Non-Developers: A data scientist could create an MCP server that exposes a complex statistical model as a tool. They can then add it to their own Claude Desktop configuration and start interacting with their model using natural language, without needing to build a full-stack application around it.
• Demonstrating the Ecosystem: It provides tangible proof of the MCP promise. You built a component (the server) that is instantly usable by a completely separate application built by a different organization (Anthropic). This highlights the interoperability and modularity that the protocol was designed to achieve. It abstracts away all the low-level logic of client implementation, allowing users to focus on what matters: extending the capabilities of their AI tools.

Up to this point in the course, the MCP servers we've built have likely been running locally on our development machines (e.g., at http://localhost:8000). This is perfect for development, testing, and personal use with applications like Claude Desktop. However, the true potential of the MCP ecosystem is realized when these servers are made accessible over the internet. A remote server can be used by team members, other applications, or even the public, transforming a personal tool into a shared, reusable service. This final module covers the essential software engineering practices required to take a locally-tested MCP server and deploy it to the cloud, making it a robust and accessible part of the wider network.

Step 1: Packaging the Application (Containerization) The first step in preparing for deployment is to package your server application in a consistent and reproducible way. The industry-standard method for this is containerization, most commonly using Docker. A Dockerfile is a script that defines a complete, self-contained environment for your application. For our ArXiv MCP server, the Dockerfile would specify:

• A base operating system image (e.g., a lightweight version of Python).
• The commands to copy our server's source code into the container.
• The commands to install all necessary dependencies (e.g., pip install -r requirements.txt which would include fastmcp, requests, etc.).
• The command to execute when the container starts (e.g., python server.py). By building a Docker image from this file, we create a portable package that will run identically on any machine that has Docker installed, whether it's a developer's laptop or a powerful cloud server. This eliminates the "it works on my machine" problem and is a critical step for reliable deployments.

Step 2: Choosing a Deployment Target (Cloud Providers) Once you have a Docker image, you need a place to run it. There is a vast array of cloud providers and services suitable for hosting containerized applications. The choice often depends on factors like cost, scalability, and ease of use. Some popular options include:

• Infrastructure as a Service (IaaS): Services like Amazon EC2 or Google Compute Engine provide you with a virtual machine. You would install Docker on the VM and run your container manually. This offers maximum control but requires more setup.
• Container as a Service (CaaS): Platforms like AWS Fargate, Google Cloud Run, or DigitalOcean App Platform are specifically designed to run containers. You simply provide your Docker image, and the platform handles the underlying servers, scaling, and networking for you. This is often the easiest and most efficient option for deploying a single-service application like an MCP server.
• Platform as a Service (PaaS): Services like Heroku or Vercel can sometimes deploy Python applications directly from source code, automatically handling the containerization for you, offering an even simpler deployment experience.

Step 3: The Deployment Process The specific deployment process varies by provider, but it generally follows this workflow:

1. Push the Image to a Registry: You push your locally built Docker image to a container registry, such as Docker Hub, Amazon ECR, or Google Artifact Registry. This makes the image accessible to your cloud provider.
2. Configure the Service: You configure your chosen cloud service (e.g., Google Cloud Run). You'll specify which container image to use, the amount of CPU and memory to allocate, and, importantly, you'll configure the networking to expose the container's port (e.g., port 8000) to the public internet on the standard HTTP/S ports (80/443).
3. Set Environment Variables: If your server requires any secrets or configuration (like an API key for the ArXiv API), you would configure these as secure environment variables within the cloud service, rather than hard-coding them in your Docker image.
4. Deploy: You click the "deploy" button. The cloud platform pulls your image from the registry and starts your container. It will provide you with a public URL (e.g., https://my-arxiv-server-xyz.a.run.app).

Step 4: Testing and Validation Your server is now live on the internet. The final step is to test it. You would use the MCP Inspector again, but this time, instead of pointing it to localhost, you would point it to your new public URL. You can verify that the manifest is served correctly and that tool calls work as expected over the public internet. You could also update your chatbot client's configuration or your Claude Desktop settings to use this new remote URL. Your tool is now a globally accessible service, ready to be integrated into any MCP-compatible application, anywhere in the world. This module bridges the gap from a personal development project to a production-ready, shareable AI capability.