Skip to main content
Glama
OOBE-PROTOCOL

SAP MCP Server

Pay And Call External x402 Endpoint

sap_payments_call_external_x402

Calls external HTTP x402 endpoints, signs payment challenges with local SAP MCP wallet, retries with signature, and returns response with receipt. Requires confirmation and max price cap.

Instructions

High-level local payment bridge for generic HTTP x402 endpoints outside hosted SAP MCP, such as another SAP agent endpoint discovered from the registry. It sends the request once to obtain the 402 payment challenge, signs with the user-controlled local SAP MCP profile wallet, retries the same HTTP request with PAYMENT-SIGNATURE, and returns the response plus receipt. Use sap_payments_call_paid_tool for hosted SAP MCP tools; use this only for external HTTP x402 providers. Requires confirm: true and maxPriceUsd.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoExternal HTTP or HTTPS x402 endpoint URL to call, for example an agent endpoint discovered from SAP registry metadata.
bodyNoOptional JSON request body for POST, PUT, PATCH, or DELETE calls. Strings are sent as-is; objects are JSON-encoded.
methodNoHTTP method for the external request. Defaults to POST.
confirmNoMust be true. Confirms the user allows this helper to sign an x402 payment payload.
headersNoOptional non-sensitive headers for the external request. Do not include PAYMENT-SIGNATURE, X-PAYMENT, Authorization, or cookies.
maxAttemptsNoOptional retry count for transient x402/RPC failures such as BlockhashNotFound. Defaults to 3; max 5.
maxPriceUsdNoMaximum accepted x402 payment amount in USD. The call aborts if the challenge exceeds this cap.
profileNameNoSAP MCP profile used to sign the x402 payment. Defaults to the active profile.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesExternal endpoint URL called.
auditYesAgent-readable proof object with intent id, profile, payment receipt, attempts, and secret-material guarantee.
methodYesHTTP method used.
paymentNoSelected payment requirements, including amountUsd, network, asset, and payTo, when a 402 challenge was paid.
successYesWhether the external x402 call completed successfully.
attemptsYesNumber of attempts used.
responseYesExternal HTTP response status, safe headers, and parsed body.
settlementNox402 settlement response returned by the provider/facilitator when available.
signerAddressYesPublic address of the local SAP MCP signer. Secret bytes are never returned.
transientRetriesYesRetryable errors encountered before success.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral context beyond annotations: it explains the two-step x402 protocol (send once, sign, retry), signing with local wallet, and return of response plus receipt. No contradictions with annotations (readOnlyHint: false, destructiveHint: false).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences plus usage note. No unnecessary words. Front-loaded with purpose and process. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, output schema), the description covers the core protocol, distinguishes from alternatives, and notes requirements. The output schema exists and doesn't need explanation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description explains the overall workflow but does not add new semantics for individual parameters beyond what the schema already provides. It mentions required parameters but no additional detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'High-level local payment bridge for generic HTTP x402 endpoints outside hosted SAP MCP'. It uses specific verbs ('call', 'sign', 'retry') and identifies the resource (external x402 endpoints). It distinguishes from the sibling tool 'sap_payments_call_paid_tool' by specifying external vs. hosted use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: 'Use sap_payments_call_paid_tool for hosted SAP MCP tools; use this only for external HTTP x402 providers.' Additionally, it notes required parameters ('confirm: true and maxPriceUsd'), giving clear when-to-use and prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OOBE-PROTOCOL/sap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server