Free MCPA practice test: 30 questions with answers

MCP reports tool execution failures inside the tool result with isError set, so the model can see them and possibly retry, while protocol errors cover problems such as malformed requests. Hiding the failure or dropping the connection gives the client and model no usable information.

tools/list is the request a client sends to retrieve a server's tools, and tools/call is used to invoke one. tools/get and tools/discover are not MCP methods, and resources/list returns resources rather than tools.

Prompts are user-controlled templates that a host may surface as menu entries or commands, and they can take arguments. Tools are chosen by the model, resources are attached by the application, and sampling is a completion requested by a server.

Servers that declare the list-changed capability send a notifications/tools/list_changed notification, which prompts clients to request the list again. Restarting transports, attaching catalogues to unrelated replies, or relying on file watches are not the mechanism MCP defines.

A requester can attach a progress token to a request, and the server then sends progress notifications that reference that token. Duplicate calls, reconnecting, and asking the model to guess are not the defined approach.

Either side can send a cancellation notification that refers to a request ID, and the receiver may stop processing it. Closing the whole transport affects every request, while initialize and invented timeout fields do not cancel a single request.

Protocol compliance says nothing about whether a server is safe, so unreviewed servers and their outputs should be treated as untrusted and given minimal data. Broad home-directory access and reliance on the model to filter content both enlarge the risk.

MCP expects hosts to keep users in control, so tool calls, especially those with side effects, should be explicitly approved. Pre-approval during the handshake, one-time blanket consent, and assuming tools are harmless all bypass that control.

Confirmation keeps a person in control of side-effecting actions, and least privilege limits what a mistaken or compromised call can reach. Trusting descriptions, keeping broad rights, or hiding a tool from the interface do not reliably reduce the risk.

Audit trails come from recording invocations, inputs, and results with timestamps at the host or server. Tool annotations describe expected behavior rather than recording what happened, and model settings or vocabulary size say nothing about actions taken.

Tool output is untrusted content, so it may inform an answer but must not authorize actions, and sensitive steps need a human check. Blind obedience, stripping punctuation, and changing temperature do not address the injection risk.

The specification recommends a human in the loop, with users able to review requests and approve results. Handing over API keys, auto-accepting requests, or exempting them from host controls all remove that oversight.

Data owners and platform teams decide what a server exposes and which credentials it uses, under the organization's policies. End users, model vendors, and network staff do not own those exposure decisions.

A read-oriented tool lets the assistant query live data through a server with scoped credentials, which keeps answers current and limits access. Pasting full databases, memorizing records through training, and manual copying are poor fits.

Because the protocol is shared, one server can serve many compatible hosts without bespoke adapters. MCP does not guarantee identical model output, does not remove authentication, and does not require one programming language.

MCP is an open protocol, so compatible implementations from different vendors can work together. Tying it to one vendor, limiting it to desktop programs without remote servers, or requiring existing APIs to be retired are all incorrect.

A growing set of community servers can be evaluated and reused, and testing outside production is a prudent practice. Servers need not come from the model vendor, and MCP does not eliminate the need for credentials or access controls.

Read-only access to live alert data lets the assistant summarize current conditions without changing anything. Memorizing alerts in weights, silencing alerts unprompted, and manual screenshots are poor fits for this need.

MCP is an open standard, so one server implementation can serve any compliant host and avoid per-assistant integrations. Proprietary plugins duplicate effort, fine-tuning does not give live access to the systems, and a copied vector store goes stale and duplicates sensitive data.

MCP covers the connection between AI applications and the external context and capabilities they use. Training and distributing model weights, hosting conversation history, and replacing HTTP for web APIs all fall outside its scope.

The server primitives in MCP are tools (model-invoked actions), resources (readable context identified by URI), and prompts (reusable templates). The other sets name concepts that MCP does not define as server features.

Resources are application-driven context identified by URIs, so the host can attach them without the model choosing to call anything. Tools are model-controlled actions, sampling asks for a model completion, and roots only declare where a server may operate.

MCP messages follow JSON-RPC 2.0, and a session opens with initialize, where the parties agree on a protocol version and capabilities. Vendor-operated servers are not required, and MCP does not define a tokenizer.

Without a shared protocol, every pairing of AI application and external system needed its own connector, so the effort multiplied. Retraining external systems, copying databases, and installing browser engines per user are not the integration problem MCP addresses.

The host is the AI application that owns the user experience, and it creates one client per server it connects to. Servers, the inference endpoint, and a user-installed relay do not create those client connections in the defined architecture.

Each MCP client maintains a dedicated connection to exactly one server, so the host runs one client per server. A shared multiplexed session, server-to-server calls, and in-process calls are not the defined model.

Models do not contact servers directly; the host and its clients gather tool definitions, present them to the model, and carry out the chosen call. Direct model-to-server calls, server-written prompts, and weight-stored tool lists are not how MCP works.

Servers offer tools, resources and prompts, and they may request sampling when the client advertises support for it. Servers do not need the user's model key, and they can run remotely as well as locally.

Each MCP client maintains one dedicated connection to one server, and a host runs several clients when it needs several servers. Shared multiplexed clients, server-held conversation history, and broadcast channels are not the defined model.

The stdio transport launches the server as a subprocess and exchanges messages over its standard streams, which suits local servers. Streamable HTTP targets network-reachable servers, while custom sockets and queues are not standard MCP transports.