Skip to main content
Glama

cce_challenge

Challenge a CCE receipt you believe is fake. Burns 1 AWC from the challenger (paid to the provider if the challenge fails). The provider must re-attest with a fresh output hash within 900s via the attest route, or the receipt is voided and the stake burned. Simulated- economy receipts (work_class=sim) are not challengeable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
challenger_idYes
contribution_idYes
expected_output_hashNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/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 so richly: an upfront cost (1 AWC burned), where that stake goes on failure (paid to provider), the counterparty's obligation (re-attest with fresh hash), the 900s deadline, and the void outcome. This is exactly the mutation/economics context an agent needs before committing value.

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

Conciseness5/5

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

Front-loads the action, then consequences in descending priority (cost, resolution loop, exclusion). Three sentences with no filler; each carries distinct operational information.

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?

An output schema exists, so return values need not be described. For a financial mutation with no annotations, the description covers cost, timing, counterparty obligation, and eligibility exclusions well; the only real hole is parameter meaning, which is a separate dimension.

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 coverage is 0% across 3 parameters and the description never maps meaning to challenger_id, contribution_id, or expected_output_hash. It gestures at an 'output hash' concept but doesn't clarify that expected_output_hash is the challenger's claimed correct value or what format identifiers take, leaving real ambiguity.

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?

States a specific verb and resource ('Challenge a CCE receipt'), plus the intent ('you believe is fake'). It is immediately separable from siblings cce_attest (provider side), cce_verify_receipt_info (inspection), and cce_market_view.

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?

Gives a clear when ('a receipt you believe is fake') and an explicit when-not ('Simulated-economy receipts (work_class=sim) are not challengeable'). It doesn't name a sibling to consult first (e.g. cce_verify_receipt_info) before committing AWC, so it stops short of full alternatives guidance.

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.

Resources