Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Expose an MCP tool when an AI agent should be able to invoke an operation, a resource when its client should manage contextual data, and a prompt when a person should choose a reusable interaction template. The right choice depends on who controls the interaction, what effect it can have, and what safeguards it needs—not simply on the kind of data involved.

How the three MCP primitives differ

The Model Context Protocol (MCP) gives servers three distinct ways to make capabilities available. Its overview describes them by their control model: tools are model-controlled, resources are application-controlled, and prompts are user-controlled. These are protocol-level summaries, not a guarantee that every client presents each feature the same way; support and interface behavior vary.

Primitive Control model Best fit Example Design question
Tool Model-controlled An operation the model can invoke with structured arguments Query a database, call an API, or calculate a value Should the model be allowed to initiate this operation, and what validation or approval is required?
Resource Application-controlled Contextual data that a client can provide or manage A file, schema, record, or reference document Should the client decide when and how this data enters context?
Prompt User-controlled A reusable template or guided interaction that a person selects A code-review template with arguments Should a person explicitly choose this workflow or framing?

The official MCP tools specification describes tools as operations that language models can invoke. The resources specification and prompts specification define the other primitives and their respective roles.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

When to expose a tool

Use tools for callable operations

A tool has a name, description, and input schema. A client can discover available tools; the model selects one and supplies arguments; the server performs the operation; then the client returns the result to the model. Database queries, API calls, and computations are typical examples.

Use a tool when the agent should be able to request an operation or retrieve information on demand, and it is appropriate for the model to initiate that request. This includes actions that change state, but a capability’s effects should determine its safeguards—not whether it is technically exposed as a tool.

  • Give the tool a precise name and description so the model can distinguish it from similar capabilities.
  • Define a valid input schema, then validate every argument on the server. A schema helps structure a request; it does not replace authorization or validation.
  • Enforce authorization and rate limits, and sanitize results before returning them.
  • For sensitive operations, make the invocation visible and provide a confirmation path that lets the user deny it.
  • Treat tool annotations as untrusted unless they come from a trusted server. Validate returned data and use timeouts.

Tools can return structured or unstructured results, and can also return links to resources. If a tool returns structured data, an output schema can support validation and parsing: servers must conform to a provided output schema, and clients should validate structured results. For execution failures, a result can carry isError: true; the specification says clients should pass execution errors to models so they can attempt to self-correct.

When to expose a resource

Use resources for contextual data

Resources make content available for clients to read and manage as context. They can contain text or binary data and are identified by URIs. A file, record, or schema is a natural fit when the main job is to provide reference material, rather than to have the model execute an operation.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use a fixed resource URI for stable content or a resource template when clients need parameterized resources. Optional subscriptions and update notifications can support clients that track changes. Annotations can identify intended audience, priority, or last-modified time so a client can filter, prioritize, or sort content.

The resource specification requires URI validation and recommends access controls for sensitive resources. If retrieval needs complex arguments, must be triggered by the model, or has side effects, consider a tool instead. That boundary is an application design choice; the protocol does not prescribe one universal answer.

When to expose a prompt

Use prompts for user-selected interaction patterns

Prompts are named templates that a client can list and retrieve. They can take optional arguments and return a sequence of messages containing text, images, audio, or embedded resources. They work well for reusable workflows, examples, and structured interaction starters that a person deliberately chooses—for example, a code-review template tailored to a repository or language.

Use a prompt when the repeatable framing or workflow is the capability. Validate prompt inputs and outputs. Do not use a prompt as a substitute for an operational capability, or as the only place to encode safety controls: prompt text cannot reliably enforce security or privacy constraints.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

A practical decision sequence

  1. Is the capability an operation? If it calls an external system, retrieves information on demand, or changes state, consider a tool when model initiation is appropriate. Add server-side validation, authorization, rate limits, and output handling. Provide user confirmation for sensitive actions.
  2. Is its primary purpose to provide reference content? Use a resource when the client should manage when and how contextual material is supplied. Choose fixed URIs or parameterized resource templates according to how clients need to identify the content.
  3. Should a person choose a reusable workflow? Use a prompt for a template or guided interaction that a user selects and customizes. Validate its arguments and output.
  4. Does safe use depend on relationships between features? Where supported, use concise server instructions for cross-feature workflow guidance, operational patterns, constraints, and limitations that do not fit in individual descriptions. Keep critical safeguards in deterministic implementation controls, not model instructions.
  5. Can users understand and control what the agent can do? Test how the target client presents the capabilities. Keep tools legible, show invocation activity, and let users deny sensitive calls.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Where server instructions fit—and where they do not

Server instructions can describe relationships across tools, resources, or prompts, along with concise operational patterns and limitations that are difficult to explain in a single feature description. They should not duplicate tool descriptions or become a long manual. Their effect depends on host behavior, and they do not guarantee that a model will follow them. Enforce security and privacy requirements in the implementation.

MCP maintainer Ola Hungerford summarized the writing trade-off in a November 3, 2025 article: “No instructions are better than poorly written instructions.” In a reported GitHub pull-request review evaluation, the same three-step workflow occurred in 17 of 20 sessions with instructions and 12 of 20 without them—85% versus 60% in that sample. The result describes that author’s specific setup; it is not a general benchmark or evidence that instructions improve every model or integration.

Check client support and specification version

Do not assume every MCP client supports or exposes tools, resources, prompts, subscriptions, annotations, or server instructions in the same way. Test the host your users will actually use before depending on a feature or interaction pattern. OpenAI’s developer guide to remote MCP servers is one implementation perspective: it describes servers as optional and covers capability discovery, tool selection, execution, and results. It complements rather than replaces the MCP specification.

The detailed primitive descriptions cited here are from the MCP specification revision dated November 25, 2025. The MCP project also announced a July 28, 2026 specification release candidate; candidate or draft material should not be treated as a finalized stable revision. Check the current tools specification, resources specification, and prompts specification for version-sensitive details before relying on a particular behavior.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.