Your assistant can read a catalog in one app, but a second app needs a different integration. Could both discover and call the same capability? Model Context Protocol, or MCP, defines a common way for AI applications and servers to exchange these capabilities.
Before you begin: Understand tools and API requests. No MCP installation is needed for this lesson.
Separate the participants
The host is the AI application the person uses. A client is the protocol connection that the host maintains to a server. The server exposes capabilities and accesses the underlying data or service. The language model may help select a tool, but it is not itself the database or the authenticated network connection.
A “connector” is product language for an integration; it can include an MCP client, server, account connection, and user interface. Do not assume every product called a connector implements MCP or exposes the same features.
Imagine a host connected to a public workshop server. It discovers a tool named read_workshop, with an input schema describing workshop_id. The host can present this capability to a model. A proposed call is checked and sent through the client. The server performs the lookup and returns a result. Only then can the host use the evidence in an answer.
Discoverable does not mean permitted
Before connecting, decide what the server may access. Public fixtures require different controls from private bookings. A remote service must verify the caller and enforce resource access. The host should show meaningful connection permissions and control which actions may run.
An input schema tells you that an argument is a string. It cannot tell you that the signed-in person owns the record named by that string. That check belongs at the service boundary.
| Question | Where to look |
|---|---|
| What tools exist? | Server capability discovery |
| Are arguments well formed? | Schema and handler validation |
| May this user read this record? | Authenticated service authorization |
| Does the answer reflect the record? | Host response evaluation |
This division helps debugging. A model changing a record ID does not fix a failed login. A successful connection does not prove that a source is trustworthy.
Which boundary should you inspect when a tool never runs?
A connector makes capabilities available across a protocol boundary. It does not guarantee that a host will discover a tool, permit it, select it or execute it successfully. Trace those steps separately when a user request appears to require a tool but no call happens.
Start with the advertised tool name and schema, then inspect the host’s available capabilities and decision. Only after a call is made should you investigate the server’s execution result. The challenge turns “the connector is broken” into a specific boundary you can test.
The server exposes three tools, but the host never invokes the third.
Inspect discovery, schema, host permissions and tool selection in order.
You can identify a missing capability or selection issue before debugging execution that never occurred.
Choose how the connection travels
MCP supports local process communication and network transports. With stdio, a client launches or connects to a process and exchanges protocol messages through standard input and output. With Streamable HTTP, messages travel through an HTTP endpoint. A local process inherits an operating environment; a remote endpoint introduces network identity and service deployment concerns.
The current specification reviewed on September 10, 2026 is the July 28, 2026 revision. Older tutorials may target earlier transports or SDK generations. Record both the protocol revision and SDK version when diagnosing compatibility. They are related but not interchangeable version numbers.
Trace a failure before fixing it
The host lists read_workshop, but a call returns “permission denied.” A developer proposes adding “You are authorized” to the prompt. Would that solve the problem?
Follow the missing evidence
No. Tool discovery describes an available interface, not authorization for every resource. Check the actual account connection, token audience and scope where applicable, and server resource policy. Prompt text cannot grant service permissions. Show the user a useful connection or access error instead of retrying with invented identity arguments.
For practice, draw the route of a request from a phone to a host, through its client, to a catalog server. Mark where the user signs in, where credentials stay, and where the returned record becomes model input. Then mark which components can fail independently. This drawing is more useful than treating MCP as a magic plug that makes any service safe.
Practice with feedback
Trace one MCP request across the boundary
A host application connects to an MCP server exposing three tools. A user asks something that would need the third tool, and nothing happens.
Name the participants and separate discovery from permission.
Check your understanding
Your task
Write the debugging checklist for a silent MCP tool, from listing to result.
These notes stay on this page. Download them before leaving.
What to include
- Each step names an observable, not an assumption
- Authorisation is checked at call time and attributed to a component
- The suspected hop follows from the symptom
- The logging plan captures enough to diagnose without reproducing
Compare with a worked answer
Here is one way to answer. Check how it uses the information in the task.
Participants: a desktop host, its embedded MCP client, a local stdio transport, our timetable MCP server, and the timetable database behind it.
Checklist 1. Listed by the server? Call tools/list directly with a minimal client and read the response. This bypasses the host entirely. 2. Exposed to the model? Check the host's tool panel and its request log for the tool definitions actually sent. Hosts filter, rename, and truncate schemas. 3. Did the model propose a call? Look for a tool_use block in the response. If absent, the problem is the description, not the plumbing. 4. Executed? Server access log: the call, its arguments, and the response or error. 5. Authorised? Our server checks the caller identity against the class visibility at call time. The decision and its reason are logged per call.
The hop I would suspect first: step 2 or 3. The tool exists and the other two work, so the likely cause is that the third tool's description is vague enough that the model never selects it. That is the cheapest thing to test: rename and describe it precisely, then retry the same question. What I would log permanently: for every request, the tool list sent to the model, the proposed call with arguments, the authorisation decision with its reason, and the result status. That turns 'nothing happened' from an afternoon into a grep.
When you are signed in, opening the challenge carries your edited working notes into its draft in this browser. The challenge has its own completion record. Practising here does not award points or mark it complete.
Next, build a server exposing one intentionally small read-only contract.
Sources
MCP architecture explains the participants. The versioned specification is the normative reference for protocol behavior.