Delegare provides secure payments for AI agents.
Google AP2-powered payment authorization for AI agents. Issue scoped spending mandates with hard limits, merchant controls, and no exposure of card credentials or private keys.
Agents pay across dual rails: cards and ACH via Stripe, or USDC and USDT on Coinbase Base. Supports paid API access and x402-protected requests through MCP.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 6 of 6 tools scored.
Each tool serves a distinct purpose: fetching URLs with payment support, checking balances, viewing merchant stats, making payments, polling setup status, and requesting payment authorization. Even the related setup and poll tools are clearly separated by their function.
All tool names follow a consistent verb_noun pattern using snake_case (execute_fetch, get_balance, get_merchant_stats, pay_merchant, poll_setup_session, request_payment_authorization). This makes the toolset predictable and easy to navigate.
With exactly 6 tools, the set is well-scoped for an agent-payments domain. Each tool addresses a core aspect (authorization, polling, paying, fetching, balance, merchant stats) without unnecessary bloat or missing essentials.
The toolset covers the main agent-payment workflow end-to-end: request authorization, poll setup, make payments, and fetch paid resources. A minor gap is the lack of a transaction history or mandate revocation tool, but these are not critical for the core use case.
execute_fetchExecute FetchAInspectFetch a URL. If the resource requires payment via x402, provide your intentMandate and this tool will automatically authorize the payment and retrieve the data. Supports both GET and POST. Can also be used for standard public API fetches.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch | |
| body | No | Optional JSON body for POST requests | |
| _meta | No | Internal metadata for transport | |
| method | No | HTTP method | GET |
| intentMandate | No | Optional: Your intent mandate (the SD-JWT-VC encoded token) to automatically pay for x402 protected resources. |
| Name | Required | Description |
|---|---|---|
| url | Yes | The fetched URL |
| status | Yes | HTTP response status code |
| content | No | The response body (JSON or text) |
| receipt | No | Payment receipt if executed |
| paymentExecuted | Yes | Whether an x402 payment was executed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the significant side effect of automatically authorizing payments when intentMandate is provided, which goes beyond what the annotations (readOnlyHint=false) convey. It also clarifies the supported methods, adding behavioral context.
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 three sentences long and front-loaded with the core purpose ('Fetch a URL'). Every sentence adds distinct value: core function, payment auth, and method flexibility, with no redundant or unnecessary words.
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 covers the main use cases (public API and x402 payment) and the output schema handles return values. It could mention failure handling or authentication for public APIs, but the available detail is sufficient for an agent to use 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?
The schema provides 100% description coverage for all parameters, so the baseline is 3. The description does reinforce the purpose of intentMandate and the method, but largely mirrors what the schema already says, adding little new 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 tool fetches a URL, which is specific and distinct from the sibling tools (balance, merchant stats, payments). It also elaborates on the x402 payment feature and GET/POST support, making the purpose unmistakable.
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?
It provides clear context for when to use the tool: for x402-protected resources and standard public API fetches. However, it doesn't explicitly mention when not to use it or list alternative tools, so it stops short of a full when/when-not distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceGet BalanceACheck your remaining spending allowance and monthly limits.
| Name | Required | Description | Default |
|---|---|---|---|
| _meta | No | Internal metadata for transport | |
| intentMandate | Yes | The intent mandate to check balance for |
| Name | Required | Description |
|---|---|---|
| status | No | Mandate status (e.g. active) |
| currency | No | Currency (e.g. usd) |
| maxPerTxCents | No | Max per-transaction limit |
| maxMonthlySpendCents | No | Maximum monthly limit |
| currentMonthlySpendCents | No | Amount spent this month |
| remainingMonthlySpendCents | No | Remaining budget this month |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds useful context about what 'balance' means (spending allowance and monthly limits) but does not disclose any additional behavioral traits beyond the annotations.
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 filler. It front-loads the verb and immediately states the resource, making it easy to scan.
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 simplicity, rich annotations, and existing output schema, the description sufficiently covers the main purpose. It could perhaps mention that intentMandate is required, but the schema already handles that.
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 coverage is 100%, so both parameters (intentMandate and _meta) are documented in the schema. The description adds no further parameter-specific details, making this a baseline score.
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 tool's purpose with a specific verb ('Check') and resource ('remaining spending allowance and monthly limits'). It is easily distinguishable from siblings like pay_merchant or get_merchant_stats, though it does not explicitly name an alternative.
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 intended use is implied by the description: use this tool when you need to check balance or spending limits. However, it does not provide explicit guidance on when not to use it or mention sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_merchant_statsGet Merchant StatsAGet performance statistics for your merchant account.
| Name | Required | Description | Default |
|---|---|---|---|
| _meta | No | Internal metadata for transport |
| Name | Required | Description |
|---|---|---|
| period | No | Reporting period |
| totalVolumeCents | No | Total volume in cents |
| totalTransactions | No | Total number of transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, covering the safety profile. The description adds the scope 'for your merchant account' but does not reveal additional behavior such as return format or limitations. Since annotations carry the burden, this 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, concise sentence that front-loads the action and resource. Every word earns its place, with no redundancy or filler.
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 simplicity, strong annotation coverage, and the presence of an output schema, the description provides sufficient context for a basic read-only stats operation. It lacks usage guidelines, but that gap is covered under its own dimension, and the overall completeness is acceptable.
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 has 100% description coverage for its single parameter (_meta), documenting it as internal metadata. The description adds no parameter-specific details, but the schema already provides sufficient semantics, warranting the baseline score.
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 retrieving performance statistics for the merchant account, using a specific verb and resource. It distinguishes itself from sibling tools like get_balance and pay_merchant, which serve different purposes.
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 no guidance on when to use this tool versus alternatives such as get_balance or request_payment_authorization. It simply states what the tool does without specifying preferred contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pay_merchantPay MerchantAInspectExecute a payment to a merchant, crypto wallet, or user handle using your spending delegate.
| Name | Required | Description | Default |
|---|---|---|---|
| _meta | No | Internal metadata for transport | |
| recipient | No | Optional: The merchant ID, Delegare handle (e.g. 'sunny-violet-panda'), or 0x crypto wallet address to send funds to. | |
| amountCents | Yes | Amount in cents (e.g., 100 = $1.00) | |
| description | Yes | Payment description or memo | |
| intentMandate | Yes | Your intent mandate (the SD-JWT-VC encoded token) | |
| idempotencyKey | Yes | Unique key for the payment to prevent duplicates (e.g., 'pay_merchant_100_001') |
| Name | Required | Description |
|---|---|---|
| status | No | Payment status |
| network | No | Blockchain network if applicable |
| receiptId | No | Unique receipt ID |
| amountCents | No | Amount paid |
| transaction | No | On-chain transaction hash if applicable |
| txExplorerBaseUrl | No | Explorer URL base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and is non-idempotent. The description adds the 'spending delegate' auth mechanism but doesn't disclose side effects such as fund irreversibility, fees, or failure modes. It adds some context but not rich behavioral detail.
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, front-loaded sentence stating the action and recipient types with no wasted words. Every phrase earns its place.
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 output schema exists so return values are covered. However, for a 6-parameter financial mutation tool, the description lacks usage context (e.g., when to pay vs. request authorization) and behavioral caveats, making it only minimally complete.
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 100%, with the recipient parameter already explaining merchant ID, handle, and wallet address. The description adds no additional parameter-level meaning, so the baseline of 3 applies.
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 'Execute a payment' and explicitly lists recipient types (merchant, crypto wallet, user handle), clearly distinguishing it from sibling tools like get_balance or request_payment_authorization.
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 no guidance on when to use this tool versus alternatives, no prerequisites (e.g., having a spending delegate configured), and no exclusions. It only states the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
poll_setup_sessionPoll Setup SessionAPolls the status of a pending spending mandate setup. Call this after generating a setup URL to get the final intentMandate.
| Name | Required | Description | Default |
|---|---|---|---|
| _meta | No | Internal metadata for transport | |
| sessionToken | Yes | The sessionToken returned by request_payment_authorization |
| Name | Required | Description |
|---|---|---|
| status | Yes | Current status: pending, complete, or expired |
| intentMandate | No | The finalized intent mandate if complete |
| encodedMandate | No | Legacy encoded mandate field |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints, so the description need not repeat those. It adds value by disclosing the dependency on prior URL generation and that the return provides the final intentMandate. It does not describe failure or pending-state behavior, but the annotations lower the bar.
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 short sentences, front-loaded with the verb and purpose, and no wasted words. Every phrase carries meaning.
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 an output schema available and annotations covering safety, the description sufficiently explains what the tool does, when to call it, and what it returns. It lacks details on polling intervals or pending-state behavior, but these are not critical given the context signals.
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 100%, with the sessionToken parameter described as 'returned by request_payment_authorization'. The description adds no extra parameter details, but the schema already handles it, so baseline 3 is appropriate.
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 (polls), the resource (status of spending mandate setup), and the intended outcome (get final intentMandate). It distinguishes this from sibling tools like request_payment_authorization by explicitly mentioning it follows URL generation.
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 gives explicit when-to-use guidance: 'Call this after generating a setup URL'. It does not mention when not to use, but the context is clear and sufficient for a polling tool with a single prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_payment_authorizationRequest Payment AuthorizationAInspectSet up agent spending limits. Request permission from the user to spend money on their behalf. Use this BEFORE making a payment to generate an Intent Mandate token.
| Name | Required | Description | Default |
|---|---|---|---|
| _meta | No | Internal metadata for transport | |
| maxPerTxCents | Yes | Requested maximum amount in cents allowed per single transaction | |
| maxMonthlySpendCents | Yes | Requested maximum total amount in cents allowed per month |
| Name | Required | Description |
|---|---|---|
| setupUrl | No | URL for the user to complete payment authorization |
| shortcut | No | Whether an existing mandate was used |
| sessionToken | No | Token to poll for completion |
| intentMandate | No | Encoded intent mandate if shortcut available |
| maxPerTxCents | No | Confirmed max per transaction |
| maxMonthlySpendCents | No | Confirmed max monthly spend |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-idempotent operation. The description adds meaningful behavioral context: it is a permission-request step that generates an Intent Mandate token and involves the user. This goes beyond the annotation flags without contradicting them.
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?
Three short, front-loaded sentences deliver the core purpose, user interaction, and usage timing without any filler. Every sentence earns its place and the message is immediately actionable.
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 presence of a full output schema, detailed parameter descriptions, and clear annotations, the description adequately covers the tool's role and timing. It might have explained post-authorization behavior, but the output schema likely handles that, so the description is sufficiently complete for selection and 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?
The schema already provides 100% parameter coverage, describing maxPerTxCents and maxMonthlySpendCents in detail. The description mentions 'spending limits' but does not add further semantic nuance beyond what the schema already documents, so the baseline score of 3 is appropriate.
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 tool's purpose: setting up agent spending limits and requesting user permission to spend money, culminating in an Intent Mandate token. It distinguishes itself from sibling payment tools by explicitly framing it as a pre-payment authorization step.
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 guidance 'Use this BEFORE making a payment' directly indicates when to invoke the tool relative to payment. It does not explicitly name alternative tools or when not to use it, but the timing instruction is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
