MCP Fundamentals
What MCP is and how it works
Last reviewed
Recommended
MCP Fundamentals — Timed Test 5 (10 questions)
No account needed. Answers and explanations arrive when you submit.
What this topic tests
The mix every MCP Fundamentals set is built to, and the questions published against it so far. Nothing here is hidden before you start.
| Level | Target share | Published |
|---|---|---|
| Easy | 40% | 20 |
| Medium | 40% | 20 |
| Hard | 20% | 10 |
| Total | 50 |
MCP Fundamentals — the theory
The Problem A Standard Solves
Before MCP, every pairing of an AI application and an external system needed its own connector. Four applications and six systems meant twenty-four separate integrations.
MCP replaces that multiplication with one contract. MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems. The documentation's own analogy is a good one: Think of MCP like a USB-C port for AI applications. Build the port once and everything that speaks it plugs in — MCP is an open protocol supported across a wide range of clients and servers.
MCP standardises the exchange of context, not the use of it — which is why one server works behind a chat app, an IDE and a terminal agent without knowing which it is talking to.
Three Participants, And The One Most People Get Wrong
MCP Host: The AI application that coordinates and manages one or multiple MCP clients. The host is the thing you open — an IDE, a desktop app, a terminal agent.
The client is not that. MCP Client: A component that maintains a connection to an MCP server and obtains context from an MCP server for the MCP host to use. It is a component inside the host, and there is one per server: The MCP host accomplishes this by creating one MCP client for each MCP server. Connect four servers and your one application is running four clients.
And MCP Server: A program that provides context to MCP clients. Note what that leaves out: where it runs. MCP servers can execute locally or remotely. "Local server" and "remote server" name the transport in use, not two kinds of program.
What A Server Offers, And Who Decides To Use It
Servers provide functionality through three building blocks: tools, resources and prompts. The distinction that matters is not what they carry but who reaches for them.
Tools are the model's. Tools are model-controlled, meaning AI models can discover and invoke them automatically. That is not a licence to act unsupervised — Tools may require user consent prior to execution, helping to ensure users maintain control over actions taken by a model.
Resources are the application's. Resources are application-driven, giving them flexibility in how they retrieve, process, and present available context. The host decides what to pull in and how much of it to show the model.
Prompts are the user's, and this is the label that misleads. Prompts are designed to be user-controlled, meaning they are exposed from servers to clients with the intention of the user being able to explicitly select them for use. The documentation then says exactly what that does not mean: This refers to who decides when the prompt is used, not who authors its content. The server writes the template. You choose when to fire it.
What The Client Offers Back — And What Just Got Deprecated
Servers can ask the host for things too. The live mechanism is elicitation: Elicitation provides a structured way for servers to gather necessary information on demand. Its two modes differ by a security rule, not a convenience. Form mode collects structured data through the client. URL mode does not: The interaction happens out of band and its data never passes through the client, which makes this mode suitable for sensitive flows such as credential entry or third-party OAuth authorization. The specification gives the rule its own heading: Privacy considerations: Servers must not use form mode to request sensitive information such as passwords, API keys, access tokens, or payment credentials.
Two client features you will still read about everywhere are on their way out. Roots let a client name directories a server should focus on, and were never a security control: Roots serve as a coordination mechanism between clients and servers, not a security boundary. Sampling let a server borrow the host's model. Both are Deprecated as of this revision, and both have a stated replacement — for sampling, New implementations should integrate directly with LLM provider APIs.
Deprecated is a defined state, not a rumour. A Deprecated feature remains part of the specification but is scheduled for removal: new implementations SHOULD NOT adopt it, and existing implementations SHOULD migrate before the feature's earliest removal. Today, No features have been removed under this policy yet.
Two Transports, One Protocol
Stdio transport: Uses standard input/output streams for direct process communication between local processes on the same machine, providing optimal performance with no network overhead. The host starts it: In the stdio transport, the client launches the MCP server as a subprocess. The rule that breaks the most servers is this one — The server MUST NOT write anything to its stdout that is not a valid MCP message. A stray print statement is a protocol error. Logging belongs on the other stream: The server MAY write UTF-8 strings to stderr for any logging purposes including informational, debug, and error messages.
Streamable HTTP transport: Uses HTTP POST for client-to-server messages with optional Server-Sent Events for streaming capabilities. Exposing a server over HTTP brings obligations that stdio does not have. Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks, and When running locally, servers SHOULD bind only to localhost (127.0.0.1) rather than all network interfaces (0.0.0.0). Skip those and a web page you visit can reach the server running on your laptop.
None of this changes the messages themselves. The transport layer abstracts communication details from the protocol layer, enabling the same JSON-RPC 2.0 message format across all transport mechanisms.
There Is No Handshake Any More
Unlearn the opening exchange. There is no negotiation handshake. Every request declares the protocol version it is using via the io.modelcontextprotocol/protocolVersion key in its \_meta field, and the server accepts or rejects each request independently. Reject looks like this: If the server does not support the requested version, it responds with an UnsupportedProtocolVersionError listing the versions it does support.
There is still a way to ask up front, and its direction is worth memorising. Servers MUST implement server/discover. But Calling server/discover is optional for clients — a client may invoke any RPC inline and handle UnsupportedProtocolVersionError if the server does not support the requested version.
Older implementations have not vanished. Legacy: protocol versions that establish a session with an initialize handshake (2025-11-25 and earlier). So initialize is not wrong everywhere; it is wrong for this revision.
Being stateless has a practical payoff. Because the protocol is stateless, any in-flight requests are simply lost and the client can retry them against the fresh process. A crashed stdio server is a restart, not a recovery procedure.
Two Kinds Of Failure, And Only One Is Worth Telling The Model
When a tool call fails, the protocol distinguishes what went wrong. Protocol Errors indicate issues with the request structure itself that models are less likely to be able to fix — an unknown tool, a malformed request. Tool Execution Errors contain actionable feedback that language models can use to self-correct and retry with adjusted parameters — a date in the wrong format, a value out of range.
The distinction decides what the model is shown. Clients SHOULD provide tool execution errors to language models to enable self-correction, while Clients MAY provide protocol errors to language models, though these are less likely to result in successful recovery.
What The Official Registry Promises
The official registry is a metadata repository, not a code host. The MCP Registry hosts metadata that points to those packages. The code itself stays on npm, PyPI or Docker Hub.
What it guarantees is provenance, not safety. The MCP Registry uses namespace authentication to ensure that servers come from their claimed sources, and then The MCP Registry delegates security scanning to: the package registries beneath it and the marketplaces above it. A listing tells you who published a server, not that it is safe.
Where to Go Next
MCP Integration in Claude Code is this protocol wired into one client — scopes, approval prompts and tool-surface cost, none of which the specification dictates. AI Agents Basics covers the loop that decides to call a tool, which MCP says nothing about. And Cursor Basics shows the same standard in a different host — the quickest way to see which parts of a setup are MCP and which are one vendor's.
Sample questions
Three questions from this topic, with the answer and the reasoning shown.
Q1EasyA client sends a server a list of roots. What has it actually done?
- Limited the server to those directories, so a read outside them cannot succeed once the list is set.
- Created a rule the protocol enforces, so a server reading elsewhere is breaking a stated requirement.
- Configured the client's own file layer to intercept and reject any read the server attempts outside them.
- Told the server which directories to focus on, without restricting what it is able to reach.Correct
Explanation
The principle — Telling somebody where to work is not the same as stopping them working elsewhere.
Why the key is correct — Roots define filesystem boundaries for server operations, allowing clients to specify which directories servers should focus on. And the limit of that is stated in the next breath: while roots communicate intended boundaries, they do not enforce security restrictions.
Why the others are wrong — There is no restriction to break, no protocol-level rejection, and no interception layer in the client.
Remember this — Roots point; they do not fence.
Sources — MCP first-party documentation.
Q2EasyA colleague says a program can only be called an MCP server if it is running somewhere on the network. Is that right?
- Yes — a server has to be reachable over the internet, which is what separates it from a plain library.
- No — a server is a program that provides context, and it may execute locally or remotely.Correct
- Yes — a server needs to be on separate hardware, so that the host and the server are not competing for resources.
- Yes — a server is a hosted account you subscribe to, and the program is only the part that connects you to it.
Explanation
The principle — Definitions in this protocol are about role, not about deployment.
Why the key is correct — MCP Server: A program that provides context to MCP clients. Where it runs is a separate question, and the documentation answers it directly: MCP servers can execute locally or remotely.
Why the others are wrong — Network reachability, separate hardware and a subscription are all things some servers happen to have. None of them appears in the definition.
Remember this — What makes it a server is what it provides, not where it sits.
Sources — MCP first-party documentation.
Q3EasyA feature is listed as Deprecated in the MCP specification. What does that tell you about its current status?
- It is still part of the specification, but scheduled for removal and not for new implementations.Correct
- It has already been taken out of the specification, and the entry is there to record that it once existed.
- It carries on being specified but stops functioning in conforming implementations from the moment it is marked.
- Someone has voiced a concern about it, without any defined process attached to what happens next.
Explanation
The principle — Deprecated is a defined state in a lifecycle, not a mood.
Why the key is correct — A Deprecated feature remains part of the specification but is scheduled for removal: new implementations SHOULD NOT adopt it, and existing implementations SHOULD migrate before the feature's earliest removal. Three facts in one sentence — still specified, going away, and different advice for new code than for old.
Why the others are wrong — It has not been removed, it does not stop working, and there is a policy behind it rather than an opinion.
Remember this — Still there, still working, on notice.
Sources — MCP first-party documentation.
Practise all 50 questions
Every published question in MCP Fundamentals, with its answer and explanation.
- A client sends a server a list of roots. What has it actually done?easy
- A colleague says a program can only be called an MCP server if it is running somewhere on the network. Is that right?easy
- A feature is listed as Deprecated in the MCP specification. What does that tell you about its current status?easy
- Elicitation has two modes. What are they?easy
- Elicitation is one of the features a client offers back to servers. What does it enable?easy
- How does a connection over the stdio transport begin?easy
- In MCP's own terminology, what is the host?easy
- MCP protocol versions look like dates. When does that date change?easy
- MCP reports tool failures in two different ways. What separates them?easy
- On the Streamable HTTP transport, how does a client send a message to the server?easy
- Someone is about to write an MCP server for their company's ticketing system and asks which AI applications it will work with.easy
- The MCP documentation compares the protocol to a USB-C port. What is that comparison making a claim about?easy
- What does it mean that MCP prompts are user-controlled?easy
- What does the official MCP Registry actually hold?easy
- Where does an MCP client live, and how many of them exist?easy
- Where should a stdio MCP server write its log lines?easy
- Which of these best describes the thing that the Model Context Protocol standardises?easy
- Which side is obliged to support discovery, and which side may skip it?easy
- Which three building blocks does an MCP server use to offer its functionality?easy
- Who decides when a tool is invoked, and who decides which resources are pulled into context?easy
- A client is deciding whether to forward every failure to the model, including ones naming a tool that does not exist. What is the guidance?medium
- A client sends a request declaring a protocol version the server does not implement. What comes back, and what should the client do with it?medium
- A developer implementing a client against the current revision is looking for the opening exchange that establishes the session, and cannot find it in the specification. What is going on?medium
- A developer runs an MCP server on their laptop over HTTP, binds it to all network interfaces so a container can reach it, and skips Origin checking because the server is not on the internet. What is the exposure?medium
- A manager reads that a feature the team relies on is deprecated with an earliest removal date about a year out, and asks whether the team's client will break on that date.medium
- A monitoring script restarts any MCP server that writes to its error stream. Sessions are being killed while everything looks healthy. What is wrong with the rule the script enforces?medium
- A reviewer objects to a server shipping its own prompt templates, arguing that prompts are user-controlled and therefore ought to be written by the user. How should that objection be answered?medium
- A server currently asks the client for model completions through sampling so that it never has to hold a provider key of its own. The team upgrades to the current protocol revision. What should they plan for?medium
- A server needs the user's API key for a third-party service before it can finish a task. A developer proposes adding a masked password field to the elicitation schema. What does the specification require instead?medium
- A server sends a URL-mode elicitation. The user is on the phone and does not look at the screen for two minutes. What has the client done in the meantime, and what will the server learn?medium
- A stdio server crashes mid-session with two tool calls outstanding. A developer starts designing a mechanism to replay session state into the replacement process. Is that mechanism needed?medium
- A stdio server prints a friendly startup banner before it begins handling requests. The host reports that the connection failed immediately. What happened?medium
- A team plans to hand a third-party MCP server a narrow list of roots and treat that as the sandbox for the whole integration. What is the flaw in the plan?medium
- A team's policy says any MCP server listed in the official registry may be connected without review, on the grounds that listing implies vetting. What is wrong with that policy?medium
- A team wants to move an MCP server that currently runs on each developer's laptop to a shared internal deployment, and asks how much of it has to be rewritten as a remote server.medium
- A tool receives a departure date in the wrong format. The server author is deciding how to report it back. What does the specification steer them towards?medium
- An editor is connected to four MCP servers at once. A teammate asks how many hosts and how many clients are involved.medium
- A team is dividing work on a new integration. Someone proposes that their server should decide which of its own capabilities the assistant ought to use for a given request, and return only that one. What is wrong with putting that responsibility on the server?medium
- A platform team supports four AI applications and six internal systems. Every application that needs a system has its own connector, and every new system means writing four more. What does adopting a shared protocol change about that arithmetic?medium
- You are building a server for an internal reporting database. It needs to let an assistant run parameterised queries, read the current table schema, and offer a ready-made walkthrough for the monthly close. How should those three needs be exposed?medium
- A client supports only the current revision and is being pointed at servers of unknown vintage over stdio. The team debates whether to probe with discovery first or just send the request they want. What does the era model say?hard
- A company wants its internal MCP servers, reachable only inside its own network, listed in the official registry so its developers can discover them in one place. Assess the plan.hard
- A developer sees a server published under a reverse-DNS namespace matching a company they trust, and treats the namespace as evidence the code is safe. What does that namespace actually establish?hard
- A reviewer accepts a locally-run HTTP MCP server that validates Origin strictly but binds to every interface, arguing that the validation makes the binding harmless. Assess that reasoning.hard
- A server author reports every failure as a JSON-RPC error, reasoning that it is the stricter and more honest choice. Agents using the server never recover from bad arguments. Diagnose the design.hard
- A stdio server behaves perfectly when run by hand in a terminal but drops its connection under the host within a second. Logs show a multi-line JSON blob the server pretty-prints for readability. Where is the fault?hard
- A working group proposes adding a first-class protocol message for scheduled reports, arguing it is a common need. Reviewers note the behaviour can already be assembled from a tool and a resource. On the project's stated design principles, how should the proposal be read?hard
- An architect cites the deprecated-features registry as authority for a migration deadline in a contract. What is wrong with treating that table as the authoritative source for a date?hard
- An engineer argues that because MCP tools are model-controlled, adding an approval step before a destructive tool runs would work against the protocol's design. Evaluate that argument.hard
- You are reviewing a third-party MCP server. Its elicitation schema includes a card number field, and the author argues it is safe because the user can decline and the value is only sent to their own payment provider. What is the strongest objection?hard
Frequently asked
What people ask about mcp fundamentals.
Is MCP an Anthropic product?
What is the difference between an MCP host, a client and a server?
Do MCP servers run on my machine or somewhere else?
I keep reading about the initialize handshake. Is it gone?
Are roots a way to stop a server reading files it should not?
Does the official MCP Registry mean a server has been vetted?
More MCP & AI Agents topics
Related guides
Troubleshooting · 9 min read
Your MCP server connects and the tools still do not run
The server is green, the tool count is right, and the model answers without touching any of it. That is a selection problem, not a connection problem: ten causes with distinct fingerprints, from a six-word description to the thirtieth tool that pushed the right one out of reach.
Troubleshooting · 9 min read
Why your MCP server isn't showing up in Claude Code
An MCP server that adds cleanly and then shows no tools has about ten possible causes, and each leaves a different fingerprint. A symptom-first triage guide: what the /mcp statuses actually mean, why scope cannot be changed in place, and the config error that makes Claude run your URL as a local process.