Overview
MCP (Model Context Protocol) enables AI applications to interact with external tools, resources, and prompts. The Nevermined SDK provides built-in MCP integration to:- Protect tools, resources, and prompts with paywalls
- Handle OAuth 2.1 authentication
- Manage credit consumption per operation
MCP Integration API
Access the MCP integration throughpayments.mcp:
Simplified API (Recommended)
The simplified API handles server setup automatically:Register a Tool
Register a Resource
Register a Prompt
Start the Server
Advanced API
For more control, use the advanced API:Configure and Protect Handlers
Attach to Existing Server
Complete Example
Server Configuration
Handler Options
In-band x402 signaling (_meta)
The MCP transport follows the x402 v2 MCP transport specification: payments are signalled in band through the MCP tool-call machinery, not via HTTP status codes or headers.
Request — payment payload. The client sends the x402 PaymentPayload as plain JSON in the tool-call request params under _meta["x402/payment"]. This is the payment channel — separate from session auth: the MCP session is an OAuth-protected resource, so the client must also send an Authorization: Bearer <access_token> header when opening the transport to establish the session (initialize returns 401 without it).
Authorization: Bearer header when _meta["x402/payment"] is absent, but that path is deprecated under the x402 v2 MCP transport.
Response — settlement receipt. On a successful paid call the SDK injects the settlement receipt under the spec key _meta["x402/payment-response"], alongside Nevermined-specific observability under the namespaced _meta["nevermined/credits"] key (not part of the x402 spec):
PaymentRequired object in both structuredContent (the object) and content[0].text (its JSON-stringified copy):
Note ononRedeemError. Under the in-band MCP transport, content is always suppressed when post-execution settlement fails — even with the defaultonRedeemError: "ignore"— because the x402 v2 spec forbids delivering a paid result without settlement.onRedeemErrorno longer controls whether content is returned; it now only affects the kind of error surfaced:"ignore"yields the in-band payment-required error result, while"propagate"raises a JSON-RPC misconfiguration error instead.
Endpoints
The MCP server exposes:/.well-known/oauth-authorization-server- OAuth 2.1 discovery/.well-known/oauth-protected-resource- Resource metadata/.well-known/oauth-protected-resource/mcp- MCP-specific protected resource metadata/register- Client registration/mcp- MCP protocol endpoint (POST/GET/DELETE)/health- Health check
OAuth 401 vs. payment-required
OAuth and x402 payment-required live at different layers, so they never collide:
Because payment-required is signalled in band as a tool result (not as an HTTP
402), there is no clash with the OAuth 401 challenge and no need to special-case the /mcp status code. The /mcp endpoint keeps the standard OAuth 401 behavior; payment is negotiated entirely through the tool-call _meta / tool-result mechanism described above.
x402 discovery is therefore implicit on the first tool call: a client that has not paid receives the PaymentRequired object (with its accepts array) in the error tool result and pays on the next call. There is no /.well-known/x402-payment endpoint.
Next Steps
A2A Integration
Agent-to-Agent protocol
x402 Protocol
Payment protocol details