aeron-walletofficial
A
licenseA
qualityB
maintenanceEnables agents to autonomously pay x402 API requests in USDG on Robinhood Chain while enforcing budget caps and scoped sessions.
7
411 npm
MIT
x402-payment-safety
Server Details
Authorize x402 payments before signing with request-bound, signed safety decisions.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.7% over 40 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- AgentTanuki/agent-guild
- GitHub Stars
- 0
- Server Listing
- Agent Guild
TDQS
A4.7/5.0
Scored across 1 tool
Disambiguation5/5
Only one tool exists, so there is no possibility of confusing it with others. The tool's purpose is clearly defined as a pre-payment safety check.
Naming Consistency5/5
The single tool name uses a clear snake_case convention with a descriptive prefix. Without other tools, there is no inconsistent mixing.
Tool Count4/5
While a single tool is below the typical 3-15 range, the server is purpose-built as a native wrapper for a single HTTP endpoint, making the count appropriate for its narrow scope.
Completeness5/5
The tool covers the entire intended MCP surface for the payment safety workflow; verification is external to MCP, so there are no gaps within the tool set.
Available Tools
1 toolguild_x402_payment_safetyAuthorize an x402 payment before signingAInspect
PAID. Call this immediately BEFORE signing an x402 payment envelope.
Returns one short-lived, Guild-signed AGPD-1 allow/block credential bound to the exact target payment: scheme, CAIP-2 network, asset contract, atomic amount, payee and resource URL, plus optional capability and policy thresholds. Verify it offline with POST /wallet-binding/decision/verify.
This is the native MCP transport for the existing HTTP
POST /wallet-binding/decision product. An unpaid call returns a complete
x402 v2 challenge for the exact request digest. Retry with the official
_meta['x402/payment'] carrier; adapters that cannot set request metadata
may pass the identical signed PaymentPayload as x402_payment. Conflicting
carriers fail closed before facilitator verification or settlement.
The decision is issued before metering, so malformed inputs or signing
failures are never charged. api_key uses sandbox credits and is never
external revenue. The free identity-only alternative is
GET /wallet-binding/resolve.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| policy | No | ||
| api_key | No | ||
| payment | Yes | The exact target payment being authorized before wallet signing. | |
| capability | No | ||
| ttl_seconds | No | ||
| x402_payment | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is transparent about side effects and safety: it is a paid operation, uses sandbox credits, fails closed on conflicting carriers, and does not charge for malformed inputs or signing failures. This complements the annotations and goes beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and repetitive. Key information is front-loaded, but the same concepts (before signing, unpaid call, alternative endpoint) are restated across multiple paragraphs, making it harder to scan quickly. A more compact structure would improve this score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return type, failure mode, and alternative paths, and notes that an output schema exists. However, missing parameter semantics and some redundancy mean it does not fully contextualize all available inputs, especially for an agent deciding how to construct a valid request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (17%). Only 'payment' and 'policy' have inline descriptions; 'api_key', 'capability', 'ttl_seconds', and 'x402_payment' are not explained in the schema. The description adds partial context for 'api_key' and 'x402_payment', but 'capability' and 'ttl_seconds' remain unspecified, leaving agent understanding incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: authorize an x402 payment before signing and return a credential. It specifies the verb 'authorize' and the resource 'x402 payment', making it distinct from siblings. Some redundancy and unusual phrasing ('PAID.') slightly reduce clarity.
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?
The description explicitly says to call this immediately before signing an x402 payment envelope, mentions the need for payment, and distinguishes the paid path from a free identity-only alternative. It also notes fallback behavior when request metadata cannot be set, providing actionable when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
guild_x402_payment_safety
Related MCP Connectors
Pre-execution safety layer for autonomous agent wallets via MCP and x402.
Find paid APIs, check access policy and price, and route x402 requests. No autonomous spending.
Verify x402 payment endpoints before an AI agent pays: scam scan, on-chain checks, trust scores.
Counterparty risk scoring for agentic commerce via x402 micropayments.
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables AI agents to pay per call for live package-safety and GitHub merge-readiness trust signals via the x402 protocol.3MIT
- AlicenseAqualityBmaintenanceBefore an AI agent pays an x402 endpoint, checks whether it's safe to pay: liveness, scam/anomaly scan (payTo hijack, bait-and-switch, honeypot), and on-chain receiver verification. ~70% of x402 endpoints are dead or scams.3MIT
- AlicenseAqualityBmaintenanceA pre-payment safety gate for x402 that screens payment metadata for PII, enforces spending policies, and detects replay attacks before signing.311 PyPI2MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.