Start with the job: choose the correct MCP primitive for a capability

MCP primitives answer different interaction questions. Resources let an application obtain context, tools let a model request an operation, and prompts expose reusable interaction templates; selecting the wrong one obscures consent and client behavior.

A read operation is not automatically a resource and a static prompt is not a security policy. Use the protocol semantics and the host experience you need rather than mapping every existing API endpoint one-to-one.

Make the operating boundary visible

The client and server negotiate which primitive capabilities they support. The host then decides how discovered resources, tools or prompts appear to the user and what approval or selection is required before use.

FIG. 01 / Conceptual model

Three primitives, three reader jobs

Hierarchy separating MCP resources, tools and prompts by interaction job
Conceptual model: choose the primitive from interaction semantics, not from the shape of an existing API.

Build a reproducible path

For MCP Tools, Resources, and Prompts, use a small fixture that another developer can repeat without privileged production data. Change one boundary at a time and preserve the exact configuration needed to explain how the page's decision was reached.

  1. State whether the user is selecting context, invoking an action or starting a template.
  2. Identify side effects and who initiates the interaction.
  3. Choose one primitive and define its minimal schema or identifier.
  4. Test discovery, normal use, denial and unsupported-client behavior.

Keep secrets outside the mcp tools resources prompts artifact. Record variable names, scopes and owners, then verify the relevant system of record whenever this tool or workflow can change external state.

Record evidence that survives a rerun

The design record should show the user action, protocol method, schema and expected host treatment. A primitive name alone does not explain whether data is pulled automatically or whether an external system changes.

  • Reader job and initiating actor
  • Selected primitive and capability negotiation
  • Input, output or resource identity
  • Side effect, consent and unsupported behavior

Date the MCP Tools, Resources, and Prompts record and keep factual observations separate from inference. If a claim depends on a hosted service, preview feature or moving SDK, name that dependency beside the claim.

Use a decision rule and a stopping rule

Use a tool when model-requested execution and explicit parameters are central, a resource when addressable context is central, and a prompt when the user is choosing a reusable template. Split mixed capabilities rather than hiding an action inside retrieval.

Inspect what the server advertises and exercise the primitive in at least one host. Confirm that the host presents the intended user choice and does not silently treat a state-changing operation as passive context.

FIG. 02 / Decision aid

Select by initiation and consequence

Decision matrix mapping MCP primitive choice to initiating actor and side effects
Decision aid: user selection, model invocation and external consequence determine the fitting primitive.

Protect against predictable failure and continue deliberately

For MCP Tools, Resources, and Prompts, the architecture review flags three recurring failure modes: specification versions are mixed; local and remote trust boundaries are conflated; a server is recommended without permission review. Treat them as release checks, not footnotes. This page remains draft when its exact implementation or intent evidence is still research-gated.

Use the MCP architecture map next: it separates host policy, client state, server behavior and transport.

Use the stdio versus HTTP comparison next: it chooses transport from deployment and lifecycle boundaries.

Use the MCP field guide next: it reconnects the decision to protocol roles and versioned boundaries.