Skip to main content
Glama
Sign In
x402-pilot

x402-pilot

by DrVelvetFog
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

decode_402

Parse and validate an x402 PaymentRequired (HTTP 402) response to explain each field and flag missing economic fields, non-atomic amounts, or missing decimals.

Instructions

Parse and validate an x402 PaymentRequired (HTTP 402) response and explain every field. Flags missing economic fields (scheme/network/asset/payTo/amount), number-typed or human-decimal amounts (must be atomic-integer strings), and missing explicit decimals. Provide ONE of: url (does an unpaid GET and decodes the 402), raw (a JSON or base64-encoded-JSON body string), or json (an object). Deterministic; the only network is the optional unpaid GET.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "decode_402"
  }
}

Input Schema

NameRequiredDescriptionDefault
rawNoA PaymentRequired as a JSON string or base64-encoded JSON.
urlNoResource URL to GET unpaid; expects a 402 with a PaymentRequired body.
jsonNoA PaymentRequired as an object.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses determinism, that the only network side effect is the optional unpaid GET against the supplied URL, and the specific classes of problems it flags. It omits permission/rate-limit expectations for the GET and says nothing about error behavior when the URL returns a non-402 status.

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?

Front-loaded with purpose, then checks, then input modes, then determinism note — a logical order with no filler. The flag list and the three-mode clause are dense parenthetical runs that could be tightened, but no sentence is redundant.

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?

No output schema exists, so the description covers return content at a high level ('explain every field', named flags) without specifying the response structure or how validation failures are reported. For a deterministic parser with fully documented parameters this is nearly enough, but the absence of any return-shape hint leaves a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description adds value by explaining what each mode does ('url' performs an unpaid GET and decodes the 402, 'raw' accepts JSON or base64-encoded JSON, 'json' takes an object) and by stressing that only one may be supplied, which the schema does not enforce.

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?

States a specific verb+resource: parse/validate/explain an x402 PaymentRequired (HTTP 402) body. It also names exactly what it checks (scheme/network/asset/payTo/amount, atomic-integer amounts, explicit decimals). It does not differentiate itself from the sibling inspect_payment_response or validate_extension, so an agent must infer the boundary.

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?

Explicitly defines the mutually exclusive input modes ('Provide ONE of: url, raw, or json') and clarifies which mode triggers a network call versus a purely local parse, which is real usage guidance. It offers no when-to-use-versus-sibling guidance and no exclusions.

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

Deploy Server

Other Tools