MCP Servers: What Tools, Resources, and Prompts Return

MCP servers can expose three different kinds of capabilities: tools, resources, and prompts. Tools are callable actions, resources provide context or data, and prompts offer reusable message templates; an MCP client discovers and uses each through different protocol operations.

What tools, resources, and prompts mean

The Model Context Protocol (MCP) is a standard for connecting AI applications and other clients to external services and data sources. An MCP server implements capabilities that a client can discover and, where appropriate, invoke. The three capability types are related, but they are not interchangeable.

• Tools let a client request an action, such as searching a catalog, querying a database, or creating a draft. The server describes each tool and its input parameters; a tool call returns a result, often as text or other content, and may also report whether the call failed.
• Resources expose data for a client to read, such as a document, a database record, or a generated status report. A resource is identified by a URI, and reading it returns its content and related metadata.
• Prompts are reusable templates that a client can ask the server to provide. A prompt may accept arguments and return a sequence of messages, such as a user instruction paired with relevant context.

In short, a server does not return one universal “MCP response.” What comes back depends on whether the client is listing capabilities, calling a tool, reading a resource, or retrieving a prompt.

How MCP discovery and requests work

An MCP client first connects to a server using a supported transport and performs protocol initialization. During the exchange, the client and server establish protocol details and advertise capabilities. The client can then ask what the server offers and make requests using MCP’s request-and-response messages.

For example, a client can request a list of tools, then call one by name with arguments. It can list available resources and read a particular resource by URI. It can also list prompts and request one with any required arguments. The server’s response has a type-specific structure, so clients know whether they received tool definitions, resource contents, or prompt messages.

Discovery is not the same as execution. A tool listing describes available actions; it does not run them. Similarly, listing resources does not necessarily return the full contents of every resource, and listing prompts does not automatically insert a prompt into a conversation. A client typically makes a separate request when it needs the actual result.

What a tool call returns

A tool definition generally includes a name, a human-readable description, and an input schema that specifies accepted arguments. The schema helps a client form a valid request—for instance, a search tool might require a query string and optionally accept a result limit.

When the client calls the tool, the server returns a tool result. Results can contain content blocks such as text, images, or other supported content, depending on the protocol version and implementation. A response can also indicate that the tool call produced an error. The exact data is determined by the particular server and the action requested, not by MCP as a fixed universal answer.

Consider a server with a tool named search_docs. Its definition might say that it accepts a search phrase. A call with {"query":"backup procedure"} could return matching passages, but another server might return document identifiers or a concise summary. MCP standardizes the interaction format; it does not dictate the search algorithm or guarantee that results are correct or complete.

Tools are the capability most likely to cause an external effect. A tool might only retrieve information, or it might create, edit, send, or delete something. Clients should make the requested action and its consequences clear, especially for operations that change data.

What resource reads and prompt requests return

A resource entry typically describes a readable item using fields such as its URI, name, and optional descriptive or media-type information. A client reads it by requesting that URI. The response contains one or more resource contents, commonly including the URI, text or binary data, and a MIME type where available.

Some servers also provide resource templates: URI patterns that can be filled in to locate a specific item, such as a record for a supplied identifier. A resource may be static or generated when read. The protocol does not imply that every resource is public, permanently available, or identical across reads; access rules and freshness depend on the server.

A prompt definition typically has a name, description, and optional argument descriptions. Requesting the prompt with suitable arguments returns a prompt result, usually a list of messages with roles and content. For instance, a prompt could accept a topic and return a user message asking for a summary, possibly alongside contextual text.

A prompt is not necessarily a complete conversation, a model response, or a tool execution. It supplies structured material for the client to use. The client decides how to incorporate it into its interface or conversation, subject to the behavior of that application.

How the three capabilities compare

• Use a tool when the client needs the server to perform an operation or answer a request through a defined action.
• Read a resource when the client needs a particular piece of data addressed by a URI.
• Get a prompt when the client wants a reusable, possibly parameterized set of messages.

These are conceptual distinctions, not guarantees about a server’s internal design. A server might make similar information available through a resource and a tool, for example, but the client interacts with each through its respective protocol method. A server can also implement only some capability types. MCP does not require every server to offer all three.

Some MCP features support updates or notifications—for example, a server may signal that a list of tools or resources has changed, or a resource may support subscription-related behavior. Clients should not assume that every server supports these features. They should use the capabilities and notifications the server actually advertises.

Common misconceptions and practical checks

A frequent misunderstanding is that “the MCP server returns tools.” More precisely, a listing request returns tool descriptions, while a separate call returns the result of running a chosen tool. The same distinction applies to resources and prompts: discovery returns descriptions or references; reading or retrieving returns content.

Another misconception is that MCP itself supplies the information. MCP defines communication patterns and data structures, while a server provides the actual functions, data, and templates. A client may display these in a user-friendly way, but presentation and model behavior are application choices.

When evaluating a server or diagnosing an integration, check the following:

• Which capabilities does the server advertise, and which list or read operations does it support?
• What arguments and content formats does each tool, resource, or prompt specify?
• Does a tool merely retrieve data, or can it change external state?
• Are permissions, authentication, and user confirmation handled appropriately for the data and actions involved?
• Does the client handle errors, unavailable resources, and capability changes instead of assuming every request succeeds?

These checks matter because a valid protocol response does not by itself establish that the server is trustworthy, that a result is current, or that an action is safe to approve.

Frequently Asked Questions

Do MCP servers always return tools, resources, and prompts?
No. A server can offer any supported combination of capabilities. The client discovers what is available rather than assuming all three are present.

What is the difference between listing a tool and calling it?
Listing returns its description and input requirements. Calling it sends arguments to the server and returns the result of that operation.

Does a resource return data or just a link?
A resource listing usually provides identifying information such as a URI. A separate read request returns its contents, which may be text or other supported data.

Does an MCP prompt produce an AI answer?
Not by itself. A prompt request returns structured messages or template content. The client or model application decides whether and how to use them to generate an answer.

Are MCP tool results always plain text?
No. Tool results can contain different supported content types, and a server may return structured or multimodal content. Clients should follow the response format rather than assume plain text.

Related

• Jujutsu Kaisen Ancient Sorcerers Tier List
• Fix WHMCS Verification Failures: Captcha, Email & SMTP
• Elgato for 1440p: Which Capture Card Fits?