MCP Sampling Is Deprecated, but the Inference Bill Has No Default Owner

Sampling's replacement creates a provider-account decision, but MCP does not choose the account owner.

MCP Sampling is deprecated under SEP-2577, but the change assigns no invoice by itself. The 2026-07-28 release candidate names direct LLM provider APIs as its replacement. [1] The first replacement call, however, needs an authorised provider account.

That does not mean the server developer always pays. MCP does not assign the payer. The account could be funded by the server operator, authorised by the customer, or supplied by a host platform. The design decision is who owns the credentials, the budget, the consent boundary, and the result when usage reaches a limit.

Provider pricing makes that decision concrete. OpenAI and Anthropic publish separate billing categories for model input, output, caching, and some tool use. [3] [4] Exact rates move. The need for an account that can incur metered usage does not.

The protocol fact and the commercial inference need to stay separate. Mixing them produces the alarming claim that every builder just inherited an inference bill. Leaving the inference out produces a different mistake: a migration plan with no named account owner.

Sampling is deprecated, not switched off

SEP-2577 marks Roots, Sampling, and Logging as deprecated. For Sampling, the release candidate lists direct integration with LLM provider APIs as the replacement. The same official post says this deprecation is annotation-only: the capability continues to work in the current release and in specification versions published within the following year. Removing it later would require a separate SEP. [1]

That distinction changes the work due this week. A server operator does not need to treat 2026-07-28 as a shutdown date. They do need to find any feature that depends on Sampling and decide whether it still needs a model completion after the deprecation window.

Consider a server that uses Sampling to turn retrieved records into a short explanation. The current path can keep running under the release candidate. The replacement review can ask a more useful question than “what broke?”: when that explanation eventually moves to a provider API, which approved account is allowed to generate it?

There is time to answer. There is not a protocol-supplied answer waiting at the end of the runway.

What Sampling kept on the client side

Sampling let an MCP server ask the client's model to generate a completion, according to The Register's report of comments by MCP maintainer David Soria Parra. The same report quotes his assessment that Sampling was rarely used and says he described its semantics as confusing and hard to implement. [2]

A concrete Sampling flow could look like this: the server requests a completion through the MCP client, and the client model returns the result. The server does not need to store its own provider key for that call. That scenario describes an implementation boundary. It does not prove that a user's subscription always absorbed the cost, because MCP does not define the commercial deal among the client, server, provider, and user.

The “rarely used” point deserves weight. This is not evidence of a widespread outage, and no verified source in the research base supplies an affected-server count. For many MCP servers, SEP-2577 may amount to protocol cleanup with no direct migration at all.

For the smaller set that still needs a completion, the cleanup exposes a live operating question. An MCP connection alone does not settle the operating boundary, as the agent-ready MCP integration audit also argues in a different context. The replacement can no longer be described only as “ask the client model.” Someone has to choose and authorise the provider path.

Direct provider APIs make the account boundary visible

Direct LLM provider APIs are metered services. OpenAI's pricing page separates categories such as input, cached input, output, and built-in tool usage. [3] Anthropic's pricing documentation likewise distinguishes input, output, cache writes, cache hits, and charges associated with some server-side tools. [4] The categories differ, which is exactly why a provider-neutral cost estimate would mislead.

The architectural contrast is simpler than the price sheet:

• Sampling path: server to MCP client to client model.
• Direct path: server or host to provider API to a metered provider account.

The second path needs credentials and permission to incur usage on that account. It also needs a response when the account rejects a call, a quota is exhausted, or the requested workload is outside the approved budget. Those are implementation and commercial decisions inferred from the replacement path and provider billing models. SEP-2577 does not prescribe them.

Take a feature that creates a 300-word summary after a user uploads a document. “Call the provider API” is not a complete replacement design. The record still needs to say which provider account can be used for that summary, who approved the use, and what happens when the account declines the request. Without those fields, the model call works only while every unstated assumption happens to remain true.

An account must exist. Its owner is still open, and that is where the universal developer-pays story falls apart.

Direct APIs do not automatically hand the bill to the developer

There are at least three plausible funding patterns. They are an operating framework, not MCP requirements and not a ranking.

Operator-funded

The server operator holds the provider account and pays the metered usage directly, then absorbs that cost or recovers it through the server's commercial model. This path gives the operator a clear account boundary. It also creates margin risk and abuse exposure. A free endpoint that can trigger unbounded model calls is no longer free to operate merely because the MCP tool itself has no price.

Customer-authorised

The customer supplies or authorises a provider account. A bring-your-own-key flow is the obvious counterexample to the claim that every server developer must personally fund every call, though it is not the only possible implementation. This pattern shifts the usage charge toward the customer's account. It also adds consent, credential-handling, onboarding, and support work. A key pasted into an unlabelled field is not a consent model.

Platform-funded

A host platform supplies the provider account and sets an allowance, quota, or other commercial boundary. The server can avoid holding a customer key, but its model access now depends on the platform's policy and limits. If the host changes the allowance or rejects the workload, the server needs a defined failure path.

No pattern wins by default. Operator funding fits a service that can price model use into its margin. Customer authorisation can fit a technical audience willing to connect an account. Platform funding can fit a host that deliberately includes inference. Each moves the burden to a different place.

The design failure is leaving the payer implicit. A provider key found in an environment variable tells you where a credential sits. It does not tell you who approved the workload, who watches the budget, or who answers when the quota runs out.

Once those three patterns are visible, a speculative cost forecast is less useful than a one-page ownership record.

Run the payer-ownership check before choosing a replacement

Start with one server feature, not the whole architecture. For the document-summary example, write down five fields:

1. Model call purpose: Generate one summary of up to 300 words after the user requests it.
2. Credential owner: Name the operator, customer, or platform account, plus where authorisation occurs.
3. Budget owner: Name the party that approves the workload and the allowed usage boundary.
4. Consent and limit owner: State what the user sees before a billable call and who sets the quota or stop condition.
5. Denial and overage behaviour: Define what the server returns when credentials are missing, the account refuses the call, the quota is exhausted, or usage would exceed the approved boundary.

The 300-word limit is an example design choice, not a cost estimate. Its value is that a reviewer can challenge it. “Use AI for summaries” gives a budget owner nothing to approve.

Choose the funding pattern only after the record has an owner in every row. An operator-funded path may set a per-user allowance and return a plain quota error. A customer-authorised path may require explicit account connection before the tool is enabled. A platform-funded path may disable the feature when the host allowance is unavailable. The exact answer varies. The blank field is the warning.

This check does not replace workload measurement, and it does not tell you how to reduce token use. Readers solving that separate problem can use the guide to token efficiency in AI-assisted development. Here, the narrower concern is accountability for metered usage before a replacement call ships.

Run the check during the annotation-only window. Waiting for a removal proposal turns a reviewable business boundary into a hurried implementation detail.

A protocol replacement cannot choose your business model

Sampling's deprecation is a planning signal. It is not an outage, and it is not evidence that every server builder inherits a provider bill. The official replacement points toward direct LLM provider APIs, whose usage is metered through provider accounts. [1] [3] [4] MCP still does not say whose account should appear on the call.

Write that answer before the code makes it accidentally. For one feature, name the model-call purpose, credential owner, budget owner, consent and limit owner, and denial or overage behaviour. Then ask the person who approves the replacement whether every field reflects the commercial boundary they intend to operate.

Send this five-field ownership record to the teammate who must approve the replacement path.

References

[1] Model Context Protocol Blog, “The 2026-07-28 MCP Specification Release Candidate.” Official source for SEP-2577, Sampling deprecation, the direct LLM provider API replacement, the annotation-only lifecycle, and the separate-SEP requirement for later removal. https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

[2] The Register, “Model Context Protocol prepares to break with its stateful past.” Third-party reporting of David Soria Parra's description of Sampling and his comments on usage and implementation semantics. https://www.theregister.com/devops/2026/07/23/model-context-protocol-prepares-to-break-with-its-stateful-past/5276722

[3] OpenAI API Pricing. Official source for model-specific input, cached-input, output, and tool-related API billing categories. https://developers.openai.com/api/docs/pricing

[4] Claude Platform Docs, “Pricing.” Official source for input, output, cache-write, cache-hit, and tool-related API billing categories. https://platform.claude.com/docs/en/about-claude/pricing