Skip to main content
Glama

Dispute evidence pack

dispute_pack
Read-only

Use when a buyer agent was charged by an x402 seller and not served: given the payment's transaction hash, the seller URL, the accepted 402 and the response, get the settlement on Base, the Fair Offer terms at quote time (failed calls free, receipts, refunds), what Agoranome observed of that seller in that hour, the seller's published contact and a draft claim addressed to it, all signed. Price: $1.00 in USDC per call, paid with x402 inside the tool call. Or send a Skyfire pay or kya-pay token in the kyapay-token header (or in this tool's kyapay-token argument), and this tool charges $1.00 to it. Failed calls aren't charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tx": "<tx>",
      "seller": "<seller>"
    },
    "name": "dispute_pack"
  }
}

Input Schema

NameRequiredDescriptionDefault
txYesThe payment's transaction hash on Base
claimNoWhat went wrong, in your words
offerNoThe accepted 402 as received
pay_toNo
sellerYesThe x402 offer's URL
ticketNoOptional: true to get a ticket instead of waiting. The run then has minutes instead of 85 s and waits for a busy slot; the paid answer is the ticket, and its result is free with the job_status tool.
responseNostatus, body or body_sha256, headers, received_at
kyapay-tokenNoA Skyfire pay or kya-pay token made for Agoranome's service, from a client that can't set the kyapay-token header. Leave it out when paying with x402 or the header.
expected_price_usdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / ticket
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional: true to get a ticket instead of waiting. The run then has minutes instead of 85 s and waits for a busy slot; the paid answer is the ticket, and its result is free with the job_status tool.",
      +  "title": "Ticket"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / kyapay-token
      Added value: +{
      +  "description": "A Skyfire pay or kya-pay token made for Agoranome's service, from a client that can't set the kyapay-token header. Leave it out when paying with x402 or the header.",
      +  "type": "string"
      +}
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the $1.00 USDC price, the two accepted payment paths (x402 inside the call, or a Skyfire/kya-pay token via header or argument), that failed calls are free, that outputs are signed, and the ticket-mode latency trade-off (85 s vs. minutes, results retrieved with job_status). Annotations only say readOnlyHint and openWorldHint; the description carries the money, auth, and timing behavior that actually governs invocation.

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 the use case before any pricing detail, and each clause is informative. The price paragraph repeats '$1.00' three times and could be tightened into a single sentence without losing the x402/kyapay/no-charge-on-failure facts.

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?

With no output schema, the description correctly enumerates the returned evidence bundle and its signed nature, and it covers payment, latency mode, and free-on-failure behavior. It omits what happens when the transaction hash is unknown or the seller is not on Base, which is the main remaining gap for a 9-parameter, paid, open-world tool.

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 coverage is 78%, so most parameters are already documented in the schema. The description adds workflow framing by naming the four evidentiary inputs (tx hash, seller URL, accepted 402, response) that pair with the required and optional fields, but it says nothing about claim, pay_to, or expected_price_usd, so it does not meaningfully exceed the schema's own detail.

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?

Names the precise trigger (a buyer agent charged by an x402 seller and not served) and then enumerates the concrete artifacts returned: Base settlement, Fair Offer terms at quote time, Agoranome's observations of that seller, published contact, and a signed draft claim. This is a specific verb-plus-resource statement that no sibling (buyer_check, check_fair_offer, server_standing) duplicates.

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?

The opening clause 'Use when a buyer agent was charged ... and not served' gives an explicit activation condition, and the payment sentence clarifies what happens on failure. It stops short of naming an alternative sibling for the pre-payment or non-disputed case, so the agent must infer routing from the surrounding catalog.

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.