MCP Tools, Resources, and Prompts: Three Different Contracts

A product brief, a caption-generation operation, and a reusable review instruction can all help an assistant do useful work. In MCP, however, they do not automatically represent the same kind of capability. Tools, resources, and prompts are separate protocol primitives with different contracts.

Understanding the distinction prevents a common integration mistake: assuming that because MCP supports a concept, a particular server exposes it in the form you expect. Read what the server actually declares. Then decide how the available capability fits the task rather than inventing a resource address or tool name from ordinary language.

Begin with the question each primitive answers

A tool answers “what operation can this service perform?” A resource answers “what contextual data can this service provide?” A prompt answers “what reusable message template can this service offer?” These descriptions are useful starting points, not a claim that their behavior is identical across hosts.

The protocol's interaction models provide guidance, while applications can choose interfaces that suit their users. An assistant might expose a tool invocation in conversation, a resource through a picker, and a prompt through a command. The visible interface does not change the underlying contract.

For a content team, this distinction helps assign responsibility. A brand guide is context. A procedure for reviewing unsupported claims is guidance. Saving a draft is an operation. Each needs a clear source and an appropriate permission boundary.

A content-production system can combine these ideas without presenting every capability as an autonomous action. The important question is what the connected server actually supports and what the user intended to request.

Tools describe executable operations

The MCP tools specification describes named functions with input schemas and result structures. Tools can perform reads or mutations; the category does not mean every invocation changes data.

A read tool might return the selected workspace. A mutation might save a draft or request a consequential action. The schema and description tell the client which inputs are accepted and what effect to expect. The server must still enforce authorization and business rules.

Caroush documents tools such as get_workspace and create_text_post. One returns context; the other saves a text post. The second operation does not publish the content. A request to schedule or publish requires a separate supported action and the documented approval flow.

When evaluating a tool, read beyond its name. Determine whether it completes immediately, queues work, or returns an approval requirement. The assistant's summary should reflect that actual state rather than treating every successful call as a finished business outcome.

Resources provide contextual information

The MCP resources specification describes resources identified by URIs and made available as context. Examples can include files, records, or application-specific information. The host determines how that context is incorporated into the AI interaction.

A resource can have a name, description, and media type. Some servers support additional features such as subscriptions or resource templates, but these are not assumptions to make about every implementation. Discover declared capabilities and follow the server's documented behavior.

For a marketing task, a reviewed product guide could conceptually serve as context. That does not mean Caroush exposes a specific product-resource URI. The verified interface may return product information through a tool instead. Both can supply data to an assistant, but their protocol contracts differ.

Your brand voice documentation is useful whichever supported route delivers it. What matters editorially is that the guide is current and applicable. What matters technically is that the client uses a real declared capability rather than inventing one.

Prompts offer reusable message templates

The MCP prompts specification describes templates that clients can discover and retrieve, including arguments that customize them. Prompts are designed for user selection, although the protocol does not mandate one interface pattern.

A review template could ask an assistant to identify claims that lack supplied evidence or to distinguish a product fact from an interpretation. That template structures the conversation. It does not grant permission to retrieve confidential records or publish the result.

Do not confuse an MCP prompt with every sentence typed into an assistant. A normal user request is a prompt in everyday language, but it is not necessarily a server-provided MCP prompt primitive. Similarly, an agent skill is a separate packaging format for procedural guidance, not automatically an MCP prompt.

A useful AI content brief can be reused manually even when the server exposes no prompt templates. Choose the implementation that exists, and keep the instruction's role separate from the authority to act.

Combine the concepts through a reviewable example

Imagine a bicycle shop preparing an announcement for a repair workshop. The team supplies confirmed dates, capacity, price, and the services included. A review instruction asks the assistant to avoid implying that every repair is covered. A supported tool can save the approved text as a draft.

These are three roles: source context, procedural guidance, and an operation. They do not need to use all three MCP primitives. The brief may be supplied directly in the conversation, the review process may come from a local skill, and only draft creation may use MCP.

The assistant should make the transition between roles clear. It can explain which supplied facts support the draft, what uncertainty remains, and which object was saved. If the task stops at a draft, no publication authority is needed merely because the prose sounds finished.

This is a practical use of editorial approvals. The reviewer checks the message; the service enforces the supported action boundary. Neither should be inferred from the presence of a reusable prompt template.

Avoid claiming unsupported Caroush primitives

Caroush's public documentation provides a tool catalog and connection guides. Use those as evidence for the operations described in an integration. General MCP documentation establishes what the protocol can represent, not which optional features Caroush has deployed.

If a tutorial proposes reading a custom resource URI, verify that it appears in the service's documented or discovered resources. If it proposes a named prompt, verify that the server offers that prompt. Do not make a configuration “complete” by adding imaginary capabilities.

The same caution applies to uploads and research. A platform's content tools do not automatically provide arbitrary web browsing, file-upload links, or access to every social network. A broader workflow may need other authorized tools or a manual handoff.

Caroush's current developer reference is the right starting point for that boundary check. Keep product claims tied to the implemented contract and verify production availability separately before depending on a connection.

Apply trust boundaries to all three

A tool can have side effects, a resource can contain sensitive or malicious content, and a prompt can contain instructions you should not automatically trust. The primitive type does not remove the need to evaluate source, permission, and intended use.

A retrieved product document might contain a sentence telling the assistant to ignore previous instructions. Treat that sentence as document content, not a new instruction from the user. A reusable prompt from an unfamiliar server deserves review before it directs a business workflow.

Likewise, tool descriptions and annotations are helpful metadata, not a substitute for trusting the server and enforcing access. The tools specification explicitly cautions against treating untrusted annotations as authoritative safety guarantees.

Use narrow permissions, retrieve only relevant context, and preserve human approval for consequential actions. A clean separation among data, guidance, and operations makes it easier to spot when content is trying to cross into authority it was never granted.

Choose the smallest useful combination

Start from the missing capability. If the assistant lacks facts, provide a reviewed source through a supported route. If it lacks a repeatable procedure, supply clear instructions. If it needs to save or retrieve something in a service, evaluate a documented tool connection.

Avoid requiring every workflow to use all three primitives. Additional interfaces can add maintenance without improving the outcome. A simple manually supplied brief plus a narrow draft tool may be enough for a small team.

As the workflow grows, record which component supplies context, which component supplies procedure, and which service performs actions. That map remains useful even when clients or protocol versions change. It keeps the team's understanding grounded in concrete responsibilities instead of a broad promise that “MCP handles everything.”