Skip to main content
Glama

x402 Echo Test

x402_echo
Read-onlyIdempotent

Cheapest possible Base-mainnet x402 conformance call: settle $0.001 of USDC and receive payer identity, request echo and receipt. Built for agents testing wallets, Payment-Signature, facilitators and settlement. Try GET /x402-echo/sample.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageNoOptional test message to echo after successful settlement.hello agent

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
payerNo
networkYes
purposeYes
requestYes
price_usdcYes
x402_receiptNo
price_atomic_usdcYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / message / description
      Added value: +"Optional test message to echo after successful settlement."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "network": {
      +      "type": "string"
      +    },
      +    "ok": {
      +      "type": "boolean"
      +    },
      +    "payer": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "price_atomic_usdc": {
      +      "type": "string"
      +    },
      +    "price_usdc": {
      +      "type": "number"
      +    },
      +    "purpose": {
      +      "type": "string"
      +    },
      +    "request": {
      +      "type": "object"
      +    },
      +    "x402_receipt": {
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "ok",
      +    "purpose",
      +    "network",
      +    "price_usdc",
      +    "price_atomic_usdc",
      +    "request"
      +  ],
      +  "type": "object"
      +}
  2. Added

TDQS

B3.1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description says the tool settles $0.001 of USDC on Base mainnet, which is a state-changing financial transaction on an external network. This directly contradicts the annotations readOnlyHint=true and openWorldHint=false, and no permissions, auth flow, or failure behavior are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and compact, using three sentences to cover cost, function, audience, and a sample call. 'Cheapest possible' is slightly promotional, but the structure is efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema and full parameter coverage, the description omits critical execution details for a payment-settlement tool, such as how the $0.001 is authorized and what happens on failure. The contradiction with the safety annotations further undermines completeness for a tool that appears to move funds.

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?

Schema description coverage is 100% and the single optional message parameter is already fully documented in the schema. The description adds no syntax, format, or constraints beyond what the schema provides, so baseline 3 applies.

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 names a specific action (settle $0.001 of USDC) and its outputs (payer identity, request echo, receipt), making the tool's purpose clear as an x402 conformance test. It does not, however, explicitly distinguish itself from siblings like can_pay or wallet_balance.

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 states a clear use case ('Built for agents testing wallets, Payment-Signature, facilitators and settlement') and gives a concrete sample endpoint. It lacks explicit when-not-to-use guidance or named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.