Where MCP fits

What you will be able to do

Larkfield’s support knowledge is needed in three AI applications. Compare three ways to connect an application to it, set up the course project, and decide when each way is enough.

Before you startWhat to know and to have readyAbout 50 minutes

What you need to know

• Tool calling: the model proposes a call, and the application checks it and runs it. You did this in Describe a tool and Execute in application code in Building Reliable Applications with LLM APIs.
• What an API is, and a request to one, from Build and Deploy Your First API.
• A terminal, cd, and a Python virtual environment.

What you need on your computer

• Python 3.12 or later. The course is tested with Python 3.12 on macOS.
• About 100 MB of free disk space. Git is useful, but a ZIP download also works.
• No account, no key and no money. Everything in this course runs on your computer.

One cable for every device

Think of the drawer of old phone chargers in many homes. Each phone brand had its own plug. A new phone meant a new cable, and a visitor’s phone often fitted no cable in the house.

Then most devices moved to one standard port. Now one cable charges the phone, the headphones and the laptop. A device maker builds the port once, and every cable that follows the standard fits.

Notice what the standard does not decide. It fixes the shape of the plug and how the two ends talk. It does not decide who may use your laptop, or which files a visitor may copy from it. Those decisions stay with the owner of the device.

Keep both halves of this picture in mind. This lesson is mostly about the first half: one standard connection instead of many custom ones. The rest of the course is also about the second half: what a standard never decides for you.

The problem: three applications want the same knowledge

Larkfield is the garden and home shop from earlier courses. Bramble Books is a small bookshop that uses Larkfield’s help-desk service. Both shops keep their policy documents and their support tickets there.

The help desk already has an AI assistant. Amira built its tools in its own code, as in the LLM applications course. Now two more applications want the same knowledge:

• Sam and the other agents write replies in an editor assistant. They want it to search the policies while they type.
• Omar, the product manager, plans a partner’s app. A partner company wants to search Larkfield’s public policies.

Amira counts the work. The help desk assistant has two API calls and a tool schema for its model. The editor needs a plug-in, written for that editor. The partner needs its own API, with keys, schemas and documentation. That is three custom integrations for one body of knowledge.

Each copy can also go wrong in its own way. Suppose the help desk’s tool cuts every result to 300 characters, and the plug-in forgets to. Or the partner API returns a staff-only document. Three copies mean three places to find and fix each mistake.

A tiny example: count the integrations

Count the custom integrations. Each application needs its own code for each service that it uses, so the number is applications × services.

Applications	Services	Custom integrations (applications × services)	Shared servers to build (one per service)
1	1	1 × 1 = 1	1
3	1	3 × 1 = 3	1
3	2	3 × 2 = 6	2
4	2	4 × 2 = 8	2

Read the last two rows. A fourth application adds two more custom integrations, one per service. With a shared protocol, it adds no server at all. It needs only a client for the protocol, and it builds that client once for every server.

With one application and one service, both columns say 1. A shared protocol saves nothing there. Keep that row in mind for the decision at the end of the lesson.

Three ways to connect an application

There are three ways to give an application Larkfield’s knowledge. They differ in two questions: who decides when a call runs, and where the code of the connection lives.

1. Direct API integration. Your code calls the service at a fixed point. For example, the help desk page calls GET /v1/tickets/T-30002 when an agent opens a ticket. No model is involved. Your code decides, every time.

2. Tool calling in one application. The application describes a tool to the model: its name, its arguments and what it returns. The model proposes a call, for example get_order with LK-581106. The application checks the proposal and runs it. The tool’s description and its code live inside this one application. Another application must write its own copy.

3. A shared protocol. The tool moves out of the application into a separate program, a server. Any AI application that speaks the protocol can ask the server what it offers, and call it. The model still proposes, and the application still checks. But the tool is written once.

Three ways to connect an application to the same service. Only the third puts the tool where several applications can use it.

Text description of the diagram

1. Direct API integration. The help desk app (your code) makes an API call to the ticket and policy service. No model is in this path. Your code always decides. Every app writes its own calls.
2. Tool calling in one app. The app describes its tools to the model and gets back a proposed call. The app holds the tool’s schema and the code that runs it, and then makes the API call. The model proposes, and the app checks and runs. The tool lives in this one app.
3. A shared protocol, MCP. Any AI application with an MCP client gets the tools from the server, and the model proposes a call. The application sends MCP messages to an MCP server, which offers tools, resources and prompts and makes a Python call to the service. The model proposes, the app checks, and the server checks again. Every MCP application can use the same server.

The third way has a name: MCP, the Model Context Protocol. It is an open standard for how AI applications connect to tools and data. “Model context” is what a model gets to work with: tools that it may call, documents that it may read, and prompt templates. “Protocol” means agreed rules for messages, as HTTP is for the web. MCP fixes the format of the messages and their order. It does not fix what your tools do.

Three more names come with MCP. You meet each one properly in the next lesson:

• The host is the AI application that a person uses, such as the help desk assistant.
• The client is the part of the host that speaks MCP to one server.
• The server is the program that offers the tools and data, such as Larkfield’s support knowledge.

Notice that MCP does not replace tool calling. The model still proposes a call and the host still decides. MCP changes where the tool lives, and it makes “what do you offer?” and “please run this” the same for every application.

What MCP standardizes, and what stays yours

Tomás has read about MCP. “So MCP is an agent framework,” he says, “and once our tools are behind it, they are secure.”

Both parts are wrong, and the plug from the start of the lesson shows why. MCP is a protocol: a message format and a few rules. It has no planner, no loop and no memory. Those belong to the application, as AI Agents and Workflow Orchestration shows. MCP also does not decide who may read what. A standard plug does not lock your laptop.

You can see where that decision lives already. Larkfield’s business service, the plain Python code under the future server, refuses a Bramble Books ticket on a Larkfield request:

python -m support_mcp.knowledge ticket larkfield T-40003

Not found.

The command exits with code 1. T-40003 exists, but it belongs to Bramble Books, so inside Larkfield the answer is “not found”, the same as for a missing ID. This check is in knowledge.py, below any protocol. MCP will carry the request and the answer. It will not make this check for you, and it must not remove it.

Kwame asks his usual question of every design: “Who is the caller, what may they do, and in which organization?” MCP’s messages carry the call. The answers to Kwame’s question stay in your server and your business service.

MCP standardizes	Your application and your server still decide
How a client finds a server’s tools, resources and prompts (discovery)	Which tools exist, and how narrow they are
The message format (JSON-RPC 2.0) and the transports (stdio, Streamable HTTP)	Who the caller is and what they may do (authorization)
How a tool is called, and how a result or an error comes back	Whether a person must approve a call
How a remote server says where to get a token	Limits, logs, and what the model may see

The table is part of the project. It is in docs/integration-map.md, which you copy below. The terms in its left column, such as JSON-RPC and the transports, each get their own lesson later.

Larkfield’s case: before and after

Amira draws the plan for Larkfield. On the left is today’s path, with one custom integration per application. On the right is the plan for this course: one MCP server, support-mcp, in front of the same business service.

Larkfield's plan. Three custom integrations become one server that every application reaches through its own MCP client.

Text description of the diagram

Without MCP, each of the three applications reaches the support knowledge (policies and tickets) in its own way. The partner’s app is still a plan. The help desk uses two API calls and a tool schema. The editor uses a plug-in. The partner uses a partner API with keys, schemas and documentation. That makes 3 custom integrations, and a fourth application needs a fourth.

With MCP, each of the three applications has an MCP client. All three send MCP messages to one server, support-mcp, and the server calls the support knowledge. That makes 1 server, and a fourth application needs only its MCP client.

The business service on both sides is the same code. That is the point of the plan: the server is a thin layer that offers the service in a standard form. In this course, you build that layer step by step. You design its tools first, then build it, inspect it, connect an AI application to it, and protect it.

Set up the course project

The project is support-mcp. Its first version, the snapshot start, has no MCP yet. It has the synthetic data of both shops and the business service, support_mcp/knowledge.py. Every function in it takes the organization as a required argument.

1. Open a terminal and go to your projects folder:

   cd ~/projects

   If the folder does not exist, make it first with mkdir ~/projects.

2. Get the course files. If you cloned the labs repository for an earlier course, update it:

   git -C nextia-learning-labs pull

   If you do not have it, clone it with git clone https://github.com/Nextia-Intelligence/nextia-learning-labs.git. Without Git, download the ZIP file of the repository. Unzip it in ~/projects, and rename its folder from nextia-learning-labs-main to nextia-learning-labs.

3. Copy the snapshot start into a new folder, support-mcp, and go into it:

   macOS / Linux

   cp -R nextia-learning-labs/C28/snapshots/start support-mcp
   cd support-mcp

   Windows (PowerShell)

   Copy-Item -Recurse nextia-learning-labs\C28\snapshots\start support-mcp
   cd support-mcp

4. Make a virtual environment, activate it, and install the test tools:

   macOS / Linux

   python3 -m venv .venv
   source .venv/bin/activate
   python -m pip install -r requirements-dev.txt

   Windows (PowerShell)

   py -m venv .venv
   .venv\Scripts\Activate.ps1
   python -m pip install -r requirements-dev.txt

   The start needs no package to run, only Python’s standard library. The file installs pytest and ruff for the tests.

   Check the version: python --version must print 3.12 or later. On macOS, python3 can be the system’s Python 3.9, which the MCP SDK of the next lesson does not support. If so, delete .venv and make it again with python3.12 -m venv .venv (Windows: py -3.12 -m venv .venv).

5. Run the tests:

   python -m pytest -q

   ........                                                                 [100%]
   8 passed in 0.01s

   Your time can differ. Eight tests pass: the business service works.

6. Count what the data holds:

   python -m support_mcp.knowledge

   larkfield: 9 documents, 13 tickets
   bramble: 5 documents, 8 tickets

7. Search Larkfield’s policies:

   python -m support_mcp.knowledge search larkfield "return a damaged item"

     1.32  damaged-or-wrong-items: Damaged, faulty on arrival or wrong items
           … no, you can keep or recycle the damaged item. - Items of 50 dollars or more: we send a free return label, or arrange a …
     1.21  returns-policy: Returns policy
           … Return shipping is free when the item arrived damaged or we sent the wrong item. ## Refunds We inspect the item within 3 business days …
     0.90  order-changes-and-cancellations: Changing or cancelling an order
           … your account, choose the item and select Return an item. Or contact the help desk. We email a return label within 1 business day.

   The search returns the three best documents, best first. The number is the search score: higher is a better match.

8. Ask for the Bramble Books ticket through Larkfield, as above:

   python -m support_mcp.knowledge ticket larkfield T-40003

   The answer is Not found. Now ask through Bramble Books, with ticket bramble T-40003. The ticket appears: T-40003 (open): Book arrived damaged.

9. Copy this lesson’s worked example, the integration map, from the snapshot end-of-m01:

   macOS / Linux

   mkdir docs
   cp ../nextia-learning-labs/C28/snapshots/end-of-m01/docs/integration-map.md docs/

   Windows (PowerShell)

   mkdir docs
   Copy-Item ..\nextia-learning-labs\C28\snapshots\end-of-m01\docs\integration-map.md docs\

10. Open docs/integration-map.md in your editor, and read it. It holds the three applications, the integration count, and the table of what MCP standardizes.

Keep this terminal open, with the virtual environment active. Every lesson of the course starts here, in ~/projects/support-mcp.

When each way is enough

Now decide, for each case, which way is the simplest one that works. More machinery is not better. Each step to the right in the first diagram adds a part that you must run, test and keep up to date.

• Direct API integration is enough when the steps are fixed and no model chooses them. The help desk page opens a ticket when an agent clicks it. A model adds nothing there.
• Tool calling in one application is enough when one AI application needs a few tools that no other application uses. The ticket assistant of the LLM applications course is a good example. Its get_order tool lives in its own code, and that is fine.
• A shared protocol pays off when the same tools and data serve several AI applications. It pays off even more when you do not write those applications yourself, such as an editor assistant or a partner’s app. They bring their own MCP client, and your server works with each one.

MCP also has costs, and you should name them before you choose it:

• Another program to run. The server is a separate process. When something fails, you look at two programs and the messages between them. Module 3 shows you how to read those messages.
• A protocol that changes fast. MCP has had several revisions in a short time. You must pin the versions that you build on, as Version awareness shows.
• Wider exposure. Every connected application can see and call the server’s tools. So you design them narrow, with clear limits, before you build them. That is Module 2.
• Remote access needs sign-in. A server on the network needs tokens and permission checks, as in Authentication, Permissions and Multi-Tenant Applications. That is Module 5.

For Larkfield, the count decides it: three applications today, more later, and two of them not written by Amira. One server is the simpler plan in the long run.

Common mistakes

Common mistake

No module named 'support_mcp'

Symptom: a command of the project fails at once:

…/.venv/bin/python: Error while finding module specification for 'support_mcp.knowledge' (ModuleNotFoundError: No module named 'support_mcp')

Cause: the terminal is not in the project folder. python -m looks for support_mcp in the current folder. This run was one folder too high, in ~/projects.

Fix: go into the project with cd ~/projects/support-mcp, and run the command again.

Common mistake

No module named pytest

Symptom: python -m pytest -q prints No module named pytest. On macOS the message may also name another Python, for example /Library/Frameworks/Python.framework/Versions/3.14/bin/python3.

Cause: the virtual environment is not active. The terminal uses the system’s Python, which does not have the project’s packages.

Fix: activate it again: source .venv/bin/activate on macOS and Linux, .venv\Scripts\Activate.ps1 in PowerShell. The prompt then starts with (.venv). A new terminal always needs this step.

Reset. The data is read from data/ at every start, and nothing in this lesson changes it. If your project is broken, delete the support-mcp folder and do the setup steps again.

Knowledge check

Check your understanding

Explain the difference between tool calling inside one application and a tool offered by an MCP server. Where does the tool live, and who decides whether a call runs?

Show the answer

With tool calling inside one application, the tool’s description and the code that runs it are part of that application. Another application must write its own copy. With MCP, the tool lives in a separate server, and any application with an MCP client can discover it and call it. In both cases, the model only proposes a call. The application decides whether it runs, and with MCP the server also checks the request before it runs it.

Check your understanding

Predict: Larkfield adds two more AI applications (five in all) and a second service, an order service (two in all). How many custom integrations does it need without a shared protocol? How many MCP servers does it need with one?

Show the answer

Without a shared protocol: 5 applications × 2 services = 10 custom integrations. With MCP: 2 servers, one per service. Each of the five applications needs an MCP client, which it builds once for every server.

Check your understanding

Practical check: what does python -m support_mcp.knowledge ticket larkfield T-40003 print, and why must this check stay in the business service when the MCP server exists?

Show the answer

It prints Not found. and exits with code 1. T-40003 belongs to Bramble Books, and every lookup runs inside one organization. MCP only carries requests and answers. It does not know which organization a caller belongs to, or what they may read. If the check were removed from the business service, any application connected to the server could read the other shop’s tickets.

Recap

• Three ways to connect: a direct API call (your code decides), tool calling in one application (the tool lives there), and a shared protocol. With the protocol, the tool lives in a server that any application can use.
• MCP, the Model Context Protocol, standardizes discovery, the message format, calls and errors. It is not an agent framework, and it does not decide who may do what.
• Count first: applications × services custom integrations, against one server per service. With one application and one service, MCP saves nothing.
• Your project ~/projects/support-mcp runs: 8 passed, 9 + 13 Larkfield records, 5 + 8 Bramble Books records, and Not found. for the other shop’s ticket.

Next, you meet the three participants of MCP, the host, the client and the server, and you run the smallest MCP server.

Next: Participants and boundaries