payment_guardValidate a live x402 challenge, price, Base network, USDC asset, recipient, funding, gas reserve, and destination immediately before signing.
| Name | Required | Description | Default |
|---|---|---|---|
| serviceUrl | Yes | ||
| payerAddress | Yes | ||
| expectedPayTo | No | ||
| maxAmountUsdc | Yes | ||
| minGasReserveEth | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating the validation is 'live' and includes funding and gas-reserve checks, implying real-world network state is read. It does not mention failure behavior or edge cases, but it does not contradict 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 compact sentence, front-loaded with the action ('Validate') and timing ('immediately before signing'). The nine-item list is dense but free of filler. It could be better structured for readability, but it earns no redundancy penalty.
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?
There is no output schema, no per-parameter documentation, and no mention of what the tool returns or how success/failure is signaled. For a security-sensitive payment guard, the agent needs to know whether the result is a boolean, a report, or a signed payload. The description validates a list of concerns but leaves the outcome and follow-up behavior unspecified.
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?
With 0% schema description coverage, the description carries the burden of explaining parameters. It gestures at 'price,' 'recipient,' 'funding,' and 'gas reserve,' which loosely map to maxAmountUsdc, expectedPayTo, payerAddress, and minGasReserveEth, but it never explicitly defines each parameter, its requiredness, or its exact meaning. The agent is left to infer the mapping, which is risky for a payment guard.
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 ('Validate') and enumerates the exact scopes: challenge, price, Base network, USDC asset, recipient, funding, gas reserve, and destination, with a clear timing constraint ('immediately before signing'). It does not explicitly differentiate from sibling tools such as treasury_preflight, so it falls 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 phrase 'immediately before signing' gives a clear context for when the tool should be used, but the description provides no exclusions or alternatives. An agent cannot determine when payment_guard is preferable to related sibling tools like treasury_preflight or base_balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools have overlapping purposes: check_url and verify_web_evidence both inspect URLs, merchant_snapshot and merchant_audit both analyze merchants, and payment_guard and treasury_preflight both do pre-signing checks. Descriptions clarify the differences, but an agent could still misselect between these pairs.
Naming conventions are mixed: some tools start with verbs (check_url, verify_web_evidence), others with nouns (base_balance, merchant_audit, payment_guard). The pattern is not chaotic but lacks a consistent verb_noun or noun_verb structure across the set.
Eight tools is a well-scoped count for a paid agent utility server. Each tool represents a distinct capability area—balance, URL checks, merchant analysis, and payment preflight—without feeling bloated or sparse.
The tool set covers URL verification (single, batch, evidence), merchant assessment (snapshot, audit), and Base payment safety (balance, preflight, guard). Minor gaps exist, such as no tool for checking transaction status or on-chain receipt validation, but core workflows are well covered.