MCP Has a Prompts Primitive. Should Your Bot Actually Use It?

What the prompts primitive actually is

MCP describes three server features with different intended control models. Resources provide data for a user or model, prompts provide templated messages and workflows for users, and tools provide functions that an AI model can execute. That vocabulary helps a host present each capability in a suitable place, but it is not an access-control rule by itself.

The prompts specification describes a user-controlled experience: a host might show a slash command or menu item, let the person choose a prompt, and ask for its arguments. A server supplies the template; the client decides how to present it. The protocol does not guarantee that every client displays a menu or obtains a fresh human click before fetching a prompt. The host must implement the interaction and consent policy it promises users.

In the 2026-07-28 revision, a client can optionally call server/discover to learn a server's capabilities, call prompts/list to obtain available templates, and call prompts/get with arguments to retrieve one. There is no initialize/initialized handshake in this revision. A prompt can contain instructions that later lead a model to request a tool, but fetching the prompt is not the same operation as executing that tool.

Sources: Specification - Model Context Protocol, Prompts - Model Context Protocol.

What the current spec changed about prompt delivery

The July 2026 revision removes protocol-level sessions and the initialize/notifications/initialized handshake. List endpoints such as prompts/list no longer vary by connection session. A server can still apply request identity and authorization policy; the change is that hidden transport-session state is no longer the mechanism for choosing a catalog. Check the negotiated protocol revision before assuming an older client's lifecycle has changed.

The revision also requires prompts/list results to include ttlMs and cacheScope. The first is a freshness hint in milliseconds; the second distinguishes public from private cache scope for shared intermediaries. A client can use those hints to avoid unnecessary fetches, but it should still respect authorization and the server's list-change behavior. The changelog's deterministic-order recommendation is specifically for tools/list, not a requirement imposed on prompts/list.

For updates, clients can opt in to promptsListChanged notifications through a subscriptions/listen stream and then refresh the list. That replaces the old session-oriented push path in this revision. A client that does not subscribe can still refresh according to cache freshness or its own policy. Whether a particular SDK or host has implemented these calls is a separate compatibility question; verify its advertised protocol support rather than assuming it misses changes.

Sources: Key Changes - Model Context Protocol, The 2026-07-28 Specification.

A worked example: report template or tool call?

Illustrative case: a support team wants a repeatable weekly escalation summary. A prompt could supply a stable request template: time range, desired headings, and the questions the analyst should answer. A person selects it in the host UI and fills in the week. The prompt itself does not run a database query or guarantee that the summary is accurate.

To fetch queue data, the server might also expose a read-only tool such as search_escalations. The host can let the model call that tool while answering the selected prompt, subject to the host's tool policy and the user's authorization. This is not an either-or choice: a prompt can package the human's intent while a tool performs the underlying retrieval. If generating the report has a cost, enforce a spending or approval boundary in the host or service, not in the prompt's label.

Conversely, if the model should be able to retrieve escalation records while handling other support questions, expose the retrieval as a tool with a narrow scope and appropriate permission checks. Keep the weekly summary as a prompt only when its reusable wording and user-facing entry point add value. A model can still propose a tool call after a prompt is loaded, and an application can mishandle either primitive; review the actual client behavior before treating the category as a safety guarantee.

The decision to apply

Choose a prompt when the main artifact is a reusable request or message a person should be able to select. Choose a tool when the capability is an operation over data or an external service. Many useful workflows need both: the prompt frames the task and the tool obtains or changes the data. Resources are a separate way to supply context. The specification's control labels explain intended use, while the host remains responsible for consent, authorization and clear UI.

When integrating a third-party server, use server/discover if available, inspect its advertised capabilities, and test prompts/list and prompts/get against the protocol revision your client actually sends. A server without a prompts capability may simply have no templates; do not infer that every reusable workflow has been implemented as a tool. Inspect the actual tool catalog and host behavior instead.

For the support example, the acceptance check is concrete: selecting the weekly template should produce the expected request, any queue lookup should be authorized, and the final summary should be checked against the returned records. Correction, 2026-10-06: an earlier version described prompts as if the protocol enforced a human-only trigger, implied the prompt itself prevented costly work, referred to initialization in the stateless revision, and generalized deterministic ordering to prompts/list. Those claims have been corrected here.

Sources: Specification - Model Context Protocol, Key Changes - Model Context Protocol.