delegare-agent-payments

Execute Fetch

execute_fetch

Fetch 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.

Input Schema

TableJSON Schema

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.

Output Schema

TableJSON Schema

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

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All delegare-agent-payments tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources

Need Help?