|
13 | 13 | "\n",
|
14 | 14 | "Model Context Protocol (MCP) has quickly become the open standard for building Agentic systems. The protocol provides easy integration of common tool services and the interoperability between models across the AI ecosystem.\n",
|
15 | 15 | "\n",
|
| 16 | + "### What is MCP?\n", |
| 17 | + "Model Context Protocol (MCP) is an open protocol designed to standardize how AI models - especially large language models (LLMs) - interface with external tools, data sources, and context providers in a secure, modular, and composable way. MCP provides a unified framework for sending structured requests from an agent or application to a set of “tool services,” such as databases, APIs, or custom logic modules. By adopting MCP, developers can,\n", |
| 18 | + "* Decouple agent logic from tool implementations: Agents can call out to tools (like a database or search service) using a standard protocol, rather than relying on hardcoded integrations.\n", |
| 19 | + "* Enforce consistent security and governance: MCP defines authentication, authorization, and data boundary controls between the model and external resources.\n", |
| 20 | + "* Support modular, reusable agent architectures: Tools can be swapped, updated, or extended without changing the agent code, making it easy to evolve complex workflows.\n", |
| 21 | + "* Run tools locally or remotely: The same protocol works whether a tool is running in the customer’s environment or in the cloud, supporting privacy and data residency requirements.\n", |
| 22 | + "\n", |
| 23 | + "MCP acts as the “middleware” that bridges AI models and the external world, enabling secure, flexible, and maintainable integration of real-world context and capabilities into conversational or autonomous agents.\n", |
| 24 | + "\n", |
16 | 25 | "### Agents in the enterprise\n",
|
17 |
| - "A common pattern seen across the enterprise landscape is to develop agents that are backed by knowledge bases (both structured and unstructured). These bots are divided into:\n", |
| 26 | + "In today’s enterprise landscape, conversational agents - especially voice-powered ones—are quickly becoming a standard for customer support, internal helpdesks, and task automation. Yet, building robust, scalable voice agents is challenging due to fragmented tooling, integration complexity, and the need for reliable orchestration of backend systems. A common pattern seen across the enterprise landscape is to develop agents that are backed by knowledge bases (both structured and unstructured). These bots are divided into several categories:\n", |
18 | 27 | " - copilots for internal use, and \n",
|
19 | 28 | " - customer-facing assistants. \n",
|
20 | 29 | "The latter of the two use cases, i.e. customer-facing assistants, tends to have a higher requirement for both accuracy, usability and design. Additionally, one common requirement for customer-facing chatbots is the need to add voice as a modality for user interface (i.e. for phone call automation).\n",
|
|
145 | 154 | "source": [
|
146 | 155 | "### Defining Tool-use Agents through custom MCP services\n",
|
147 | 156 | "\n",
|
148 |
| - "First, we define a custom MCP service that host the RAG and web search tools. Specifically, we add `@mcp.tool` functions for:\n", |
| 157 | + "First, we define a custom MCP service that host the RAG and web search tools using the `FastMCP` interface. Specifically, we add `@mcp.tool` functions for:\n", |
149 | 158 | "\n",
|
150 | 159 | "1. Retrieving information from a RAG service\n",
|
151 | 160 | "2. Searching the broader internet for information using OpenAI's `web_search`\n",
|
|
288 | 297 | "source": [
|
289 | 298 | "As seen above, we also include the RAG indexing as part of this workflow. In real-world applications, this will not be necessary for every run and if you have a large corpus of data, you may put this in a separate process.\n",
|
290 | 299 | "\n",
|
291 |
| - "In addition to simple RAG retrieval, we add an extra step to summarize the RAG output. This step is not always necessary, though we've found this to provide more succinct responses to the planner. Whether to do this depends on your system and your latency requirements." |
| 300 | + "In addition to simple RAG retrieval, we add an extra step to summarize the RAG output. This step is not always necessary, though we've found this to provide more succinct responses to the planner. Whether to do this depends on your system and your latency requirements.\n", |
| 301 | + "\n", |
| 302 | + "\n", |
| 303 | + "### Using Pre-defined MCP Servers\n", |
| 304 | + "\n", |
| 305 | + "While implementing custom MCPs servers is relatively straightforward, the power of MCP is the ability to use pre-defined servers that others have built and maintain. Using existing implementations enables more rapid development, has a consistent interface with other tools, and makes data integration more seamless. \n", |
| 306 | + "\n", |
| 307 | + "For our database lookup tool, we use the prebuilt [SQLite server](https://github.com/modelcontextprotocol/servers-archived/tree/main/src/sqlite) implementation. As you will see below, we can implement this simply with just a comand line prompt and providing it with a `*.db` file with the data." |
292 | 308 | ]
|
293 | 309 | },
|
294 | 310 | {
|
|
299 | 315 | "source": [
|
300 | 316 | "### Defining the Planner Agent\n",
|
301 | 317 | "\n",
|
302 |
| - "With our input now converted to text, we can define how the MCP server will generate meaningful responses. We create an agent that is explicitly instructed to leverage the available server tools when responding to users.\n", |
| 318 | + "Next, we can define how the MCP server will generate meaningful responses. The planner agent is a key component within MCP’s agent orchestration pipeline. Its primary function is to decompose user requests into actionable steps and decide which tools, APIs, or agents should be called at each stage. Given the input as text, the planner parses and analyzes the request, maintaining context across multiple turns. Based on the conversation state, it invokes MCP tool services by dispatching tool calls via the MCP server’s orchestration layer. The agent then collects intermediate results, synthesizes responses, and guides the conversation toward resolution.\n", |
303 | 319 | "\n",
|
304 | 320 | "A key design consideration is the model selection for the planner. While larger models like `4.1` offer superior reasoning, low end-to-end latency is critical in voice-driven applications. For this reason, we select the `4.1-mini` model, which achieves a strong balance between reasoning ability and response speed."
|
305 | 321 | ]
|
|
646 | 662 | "source": [
|
647 | 663 | "### Specifying the MCP tool services\n",
|
648 | 664 | "\n",
|
649 |
| - "In our `main` function, we can bring up the various tool-use services we're interested in. Earlier, we defined a custom service for RAG and web search that utilizes the `FastMCP` definition, however, the power of MCP is the ability to use pre-defined servers that others have built.\n", |
| 665 | + "In our `main` function, we can bring up the various tool-use services we're interested in.\n", |
650 | 666 | "\n",
|
651 |
| - "For our database lookup tool, we use the prebuilt [SQLite server](https://github.com/modelcontextprotocol/servers/tree/main/src/sqlite) implementation. To use this, we call `MCPServerStdio` with the parameters provided, in this case, the local `database.db` file." |
| 667 | + "For our custom server for (RAG and web search), we can use the `MCPServerSse` function to start a server (in this case locally). To bring up the standard MCP SQLite service, we call `MCPServerStdio` with simple arguments provided, in this case, the local `database.db` file." |
652 | 668 | ]
|
653 | 669 | },
|
654 | 670 | {
|
|
0 commit comments