Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@open-payments-mcp Create an incoming payment for 100 USD"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Standalone MCP server exposing core Open Payments operations over stdio.
get_wallet_address
request_grant
continue_grant
create_incoming_payment
get_incoming_payment
create_quote
get_quote
create_outgoing_payment
get_outgoing_payment
Related MCP server: Cresium MCP Server
Set these environment variables before running:
export OPEN_PAYMENTS_CLIENT_ADDRESS="https://example.com/client"
export OPEN_PAYMENTS_PRIVATE_KEY_PATH="/absolute/path/to/private.key"
export OPEN_PAYMENTS_KEY_ID="your-key-id"Optional:
export OPEN_PAYMENTS_SESSION_FILE=".data/open-payments-sessions.json"
export OPEN_PAYMENTS_CALLBACK_PORT="3999"
export OPEN_PAYMENTS_MAX_DEBIT_AMOUNT="100000"You can start from .env.example if you prefer loading env vars with your MCP client or shell.
The private key path, key ID, access tokens, and grant continuation tokens are never accepted as MCP tool inputs and are not returned in MCP tool responses.
pnpm install
pnpm build
pnpm startFor development:
pnpm devTypical peer-style flow using the core tools:
get_wallet_address for receiver and sender.
request_grant for receiver incoming-payment access.
create_incoming_payment.
request_grant for sender quote access.
create_quote.
request_grant for sender outgoing-payment access.
User opens interactRedirectUrl and approves in their wallet.
continue_grant.
create_outgoing_payment.
get_outgoing_payment.
Outgoing payment execution requires the finalized grant produced after user approval.
Continue an interactive Open Payments grant after the user approves it.
| Name | Required | Description | Default |
|---|---|---|---|
| interactRef | No | ||
| grantSessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action without explaining side effects, required prior state, idempotency, permissions, or return behavior. This is a significant transparency gap for a continuation step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of ten words with no filler. It is appropriately sized and front-loaded, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is part of an interactive flow, but the description lacks essential context about preconditions, relationship to request_grant, parameter meanings, and outcome. With no output schema or annotations, this is incomplete for a continuation step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for the parameters interactRef and grantSessionId. The agent must rely solely on the parameter names, which is insufficient for correctly invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Continue' and identifies a specific resource ('interactive Open Payments grant') with a clear timing condition ('after the user approves it'). This clearly distinguishes the tool from siblings like request_grant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('after the user approves it'), but it does not mention alternatives or conditions when not to use it. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an incoming payment using a finalized incoming-payment grant session.
| Name | Required | Description | Default |
|---|---|---|---|
| expiresAt | No | ||
| description | No | ||
| grantSessionId | Yes | ||
| incomingAmount | No | ||
| receiverWalletAddress | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action is 'create', which is a write operation, but it does not mention permissions, side effects, error conditions, or what is returned. This leaves the agent uncertain about important behavioral aspects beyond what the schema already shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should explain more about the tool's context, such as return behavior or prerequisites in detail. It only gives a one-line purpose, leaving significant gaps for a 5-parameter mutation tool with nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at grantSessionId via 'grant session' and does not explain receiverWalletAddress, expiresAt, description, or incomingAmount. This is minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'incoming payment', and further specifies the prerequisite of using a 'finalized incoming-payment grant session'. This distinguishes it from sibling tools like create_outgoing_payment or get_incoming_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you have a finalized incoming-payment grant session. It implies this is a follow-up to the grant process but does not explicitly mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an outgoing payment using a finalized outgoing-payment grant session.
| Name | Required | Description | Default |
|---|---|---|---|
| quoteId | Yes | ||
| description | No | ||
| grantSessionId | Yes | ||
| senderWalletAddress | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the creation action and the prerequisite of a finalized grant session, but it does not mention financial side effects, reversibility, authorization requirements, or error behavior. For a payment-creation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded with the action and resource, and the prerequisite is appended efficiently. The brevity is appropriate for the content provided, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a financial mutation with significant complexity, but the description lacks necessary context: it does not explain the grant flow, prior required steps, return values, or side effects. With no annotations, no output schema, and undocumented parameters, the description is not sufficient for an agent to confidently use the tool. It is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters, and the description does not compensate. It fails to explain the roles of grantSessionId, senderWalletAddress, quoteId, or description. Even though the names are somewhat self-explanatory, the description adds no semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'create' on the resource 'outgoing payment', which distinguishes it from the sibling 'create_incoming_payment'. It also adds context by requiring 'a finalized outgoing-payment grant session', giving a precise scope. This meets the standard of a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when a finalized outgoing-payment grant session exists, which is a usage prerequisite. However, it does not explicitly state when not to use it or mention alternatives such as 'execute_peer_to_peer_payment' or 'create_incoming_payment'. The usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a quote using a finalized quote grant session.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | ||
| receiver | Yes | ||
| debitAmount | No | ||
| receiveAmount | No | ||
| grantSessionId | Yes | ||
| senderWalletAddress | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the core action and prerequisite, with no mention of side effects, required permissions, error conditions, or return behavior. This leaves significant gaps for a tool that creates a quote.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, which is efficient. However, it is under-specified, omitting details about parameters and behavior, so the conciseness comes at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, nested objects, no output schema, and no annotations, the description is severely incomplete. It provides only a vague premise and leaves the agent without enough context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of any of the six parameters, including nested objects like debitAmount and receiveAmount. The description fails to compensate for the lack of parameter documentation, making it difficult to know what values to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a quote'), and specifies a key prerequisite ('using a finalized quote grant session'). This distinguishes it from read tools like get_quote, though it doesn't explicitly differentiate from other create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by mentioning the need for a finalized quote grant session, but it does not provide explicit alternatives or exclusions. It lacks guidance on when not to use it or which sibling tool to choose instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Orchestrate a full peer-to-peer payment flow: incoming payment, quote, interactive outgoing grant, and outgoing payment (blocks until approval).
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | ||
| method | No | ||
| timeoutMs | No | ||
| incomingAmount | No | ||
| sendingWalletAddressUrl | Yes | ||
| receivingWalletAddressUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full transparency burden. It does disclose that the operation 'blocks until approval' and is 'interactive,' which is important. However, it does not detail side effects like creating multiple resources, potential irreversibility, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's scope and key behavior. It packs a lot of information without wasted words, though a more structured format might improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of orchestrating four sub-steps, the absence of an output schema, and no annotation context, the description is high-level and incomplete. It fails to mention what the caller receives (return value), error handling, timeout semantics, or prerequisites, leaving significant gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for its 6 properties, and the description itself explains none of them. While the required wallet address fields are somewhat self-explanatory, optional parameters like dryRun, method, and timeoutMs remain completely ambiguous, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Orchestrate') and clearly defines the resource ('full peer-to-peer payment flow'), enumerating the concrete steps involved. This distinguishes it from sibling tools that handle individual steps, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for executing the entire flow in one call, contrasting with the granular sibling tools. However, it does not explicitly state when to prefer this over manual composition, nor does it mention exclusions or specific scenarios for alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read incoming payment details using a finalized incoming-payment read grant.
| Name | Required | Description | Default |
|---|---|---|---|
| grantSessionId | Yes | ||
| incomingPaymentUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It correctly identifies the operation as a read (non-mutating), but offers no information about error conditions, return format, validation of grant status, or consequences of using an unfinalized grant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core operation. It is appropriately concise for a simple read tool, though the brevity contributes to the lack of behavioral and parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain return values and prerequisites. It vaguely says 'details' without specifying what is returned, and references a grant without explaining how it is obtained or what happens if it is not finalized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter (grantSessionId, incomingPaymentUrl) or explain their significance beyond the schema's bare types. The agent gets no added meaning to assist with parameter construction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (read) and resource (incoming payment details), and the word 'incoming' distinguishes it from get_outgoing_payment. However, it does not explicitly differentiate from siblings or elaborate on the scope of 'details', so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used with a 'finalized incoming-payment read grant', providing some contextual prerequisite. But it does not mention when to avoid this tool, nor does it suggest alternatives like get_outgoing_payment or create_incoming_payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read outgoing payment details using a finalized outgoing-payment read grant.
| Name | Required | Description | Default |
|---|---|---|---|
| grantSessionId | Yes | ||
| outgoingPaymentUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral requirement (the grant must be finalized) and the read non-destructive nature via the verb 'Read'. However, it does not mention error handling, response format, or any rate limits, so it offers limited transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the purpose and prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with no output schema and no annotations. It omits parameter semantics and return value expectations, leaving the agent to infer from parameter names alone. The grant requirement is useful but insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no direct explanation of the two parameters. It indirectly hints that grantSessionId relates to the grant and outgoingPaymentUrl to the payment, but it does not clarify their formats, how to obtain them, or their exact roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific action ('Read') and resource ('outgoing payment details'), and adds a prerequisite ('finalized outgoing-payment read grant'). This distinguishes it from sibling tools like get_incoming_payment and create_outgoing_payment by specifying the read-only nature and the grant requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a finalized outgoing-payment read grant is available, but it does not explicitly state when to use this over alternatives or when not to use it. It lacks exclusions or naming of sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read quote details using a finalized quote read grant.
| Name | Required | Description | Default |
|---|---|---|---|
| quoteUrl | Yes | ||
| grantSessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing behavior. It does disclose the need for a finalized read grant, which is beyond a bare 'read' statement. However, it does not describe return formats, potential errors, or whether any side effects exist. The read-only nature is implicit from the verb but not explicitly stated, so transparency is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action. Every word earns its place, with no redundant phrases. It is appropriately sized for the tool's simplicity, demonstrating excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 params, no output schema, no annotations), a short description is acceptable. However, the description omits parameter semantics and any mention of return values, which would be helpful for an agent to invoke and interpret results correctly. It is minimally complete but leaves clear gaps for an agent attempting to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameters. It gives a vague hint that 'grantSessionId' relates to the finalized quote read grant, but it does not explain 'quoteUrl' at all. The description adds minimal semantic value beyond the parameter names themselves, leaving users to infer meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('quote details'), making the tool's primary purpose unmistakable. It distinguishes itself from sibling tools like create_quote or get_outgoing_payment, though it doesn't explicitly contrast with them. The lack of explicit differentiation prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'using a finalized quote read grant' implies a prerequisite context, suggesting this tool should be used when such a grant is available. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an Open Payments wallet address and return sanitized wallet details.
| Name | Required | Description | Default |
|---|---|---|---|
| walletAddress | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'sanitized wallet details' but offers no additional behavioral context such as read-only nature, authentication needs, rate limits, or what 'sanitized' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence (12 words) that is front-loaded with the action verb. No redundant phrasing or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description covers the core purpose. However, with no output schema and minimal descriptions, it leaves the return value vague ('sanitized wallet details') and fails to specify whether it returns a single object or other structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single required string parameter with URI format. The description adds domain context by referring to it as an 'Open Payments wallet address', but it does not elaborate on input expectations or edge cases beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Resolve' with a specific resource 'Open Payments wallet address', clearly distinguishing it from sibling tools focused on grants, quotes, and payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a lookup/resolution use case, but does not explicitly state when to use it versus alternatives (e.g., before creating payments). No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request an Open Payments grant. Outgoing payment grants are made interactive and return an approval URL.
| Name | Required | Description | Default |
|---|---|---|---|
| access | Yes | ||
| interact | No | ||
| authServer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It does disclose key behavioral traits: 'made interactive' and 'return an approval URL.' However, it omits any mention of side effects, required authentication, or follow-up steps, which is a notable gap for a grant-initiation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and no filler. Every word earns its place, making it efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters with nested objects, no output schema, and no annotations, yet the description offers minimal context. It fails to explain the grant lifecycle (e.g., that an approval URL must be used with continue_grant), leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters (authServer, access, interact). It neither defines the purpose of each field nor maps them to the grant workflow, forcing the agent to rely solely on the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as requesting an Open Payments grant and highlights the interactive nature with an approval URL for outgoing payment grants. This distinguishes it from sibling tools like continue_grant and payment creation tools, though it doesn't explicitly frame its role in the broader grant flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like continue_grant. The description mentions a specific behavior (interactive grants) but lacks any conditional context or alternative recommendations, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools map clearly to distinct resources and actions (e.g., create_incoming_payment vs. create_outgoing_payment, get_quote vs. get_outgoing_payment). The composite tool execute_peer_to_peer_payment could be confused with the individual step tools, but its description clearly frames it as an orchestration workflow.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_wallet_address, create_incoming_payment, request_grant). The verbs and resource names are uniform and predictable.
With 10 tools, the server is well-scoped for the Open Payments domain. It covers the essential resources (wallet address, grants, incoming payments, quotes, outgoing payments) and includes a high-level workflow tool without becoming bloated.
The tool set provides create and read coverage for all major resources and handles the grant lifecycle. However, there are no list operations (e.g., list incoming payments) or cancellation/update capabilities, which constitutes a minor gap for a full payment workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Discover machine-payable APIs, probe x402 payment terms, and run seller operations. Non-custodial.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
Trust and payment layer for the agentic economy on the XRP Ledger.
Verified ROKI Connect payments contract for coding agents: operations, schemas, validator.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/devcer/open-payments-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
