Skip to main content
This guide explains how to integrate the Nevermined Payments Python SDK with MCP (Model Context Protocol) servers.

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 through payments.mcp:
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).
For backward compatibility the server still falls back to reading the access token from the 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):
Payment required. When the caller has not paid (or cannot be authorized), the tool returns an error tool result carrying the PaymentRequired object in both structuredContent (the object) and content[0].text (its JSON-stringified copy):
Settlement failure after execution. If settlement fails after the tool has already executed, the server returns the same payment-required error result and suppresses the tool’s content — a paid result is never delivered without payment landing.
Note on onRedeemError. Under the in-band MCP transport, content is always suppressed when post-execution settlement fails — even with the default onRedeemError: "ignore" — because the x402 v2 spec forbids delivering a paid result without settlement. onRedeemError no 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