A study group sorting MCP concepts places progress tracking, cancellation, pagination and argument completion in the same list as tools, resources and prompts. How should those four concepts be classified?
Select an answer to reveal the explanation.
Short Explanation
Tools, resources and prompts are the meal; progress, cancellation, pagination and completion are the cutlery that helps you eat it. You'll use them alongside the primitives, but they aren't primitives themselves. The trap is lumping everything with a method name into one bucket.
Full Explanation
MCP defines three server primitives: tools, resources and prompts. Alongside them the specification describes cross-cutting utilities and patterns that make requests workable. Progress tracking lets a long-running request report advancement through a progressToken in _meta. Cancellation lets a client abandon an in-flight request, signalled per transport. Pagination splits large list results using opaque cursors, and argument completion suggests values for prompt arguments and resource template parameters. These mechanisms serve many requests rather than exposing a new kind of server content, which is why they sit apart from the primitives. Treating them as additional server primitives misreads the model: they do not represent actions, context or templates offered by a server. Calling them client features is also wrong; the client feature in revision 2026-07-28 is elicitation, with sampling and roots deprecated, and those are what multi round-trip input carries. Calling them optional extensions confuses them with modules such as Tasks or MCP Apps, which are negotiated through the extensions field of capabilities. Exam caveat: some utilities are still declared as capabilities, for example completions, so the presence of a capability does not by itself make something a primitive. Operational check: when documenting a server, list primitives under tools, resources and prompts, and list utilities separately with the requests they support.