Loading ToolBench
Independent attestation infrastructure for the agentic economy. Every claim is cryptographically signed (Ed25519) and settled against verifiable external ground truth — on-chain state, GitHub, market data, or structured API responses — producing an audit-grade, independently re-verifiable receipt with no reliance on counterparty trust. Complimentary tier, no account required, engineered fail-closed. Institutional capabilities include OFAC SDN entity screening, corporate distress ranking (held-out AUC 0.769; a ranking input, not an alarm), and a bonded dispute-resolution path ($1.00, x402) to formally contest a verdict.
The server defines 5 tools with clear, action-oriented names (verify_receipt, claim_verdict, file_dispute, screen_entity, distress_score). All tools have descriptions and input schemas with type information. However, there are significant gaps: (1) Output schemas are completely undocumented, the code shows HTTPS calls to stillosdigitalholdings.com but no response structure is declared, forcing LLMs to reason about unknown return shapes; (2) Parameter descriptions are minimal, many lack formatting guidance, constraints, or examples of valid input; (3) No error handling guidance or recovery paths documented; (4) No indication of which operations are idempotent or safe to retry. Tool names are strong (verb_noun pattern), but descriptions average ~150 chars and lack context on when/why to use each tool relative to others. Composition is clean, each tool does one thing, but the lack of output documentation and error guidance significantly weakens usability for autonomous agents.
Submit a claim-verdict. Takes an agent name, claim text, and resolver specification (http_status, github, market_data, or structured API response) and submits it for cryptographic signing and settlement against verifiable external ground truth.
Corporate distress ranking using machine learning model (held-out AUC 0.769). Free tier allows 3 calls per day; additional calls require payment ($0.15 USD, x402 protocol, Base network).
File a bonded dispute against a receipt verdict. Paid endpoint ($1.00 USD, x402 protocol, Base network). No free tier.
OFAC SDN name screening. Free tier allows 5 calls per day; additional calls require payment ($0.001 USD, x402 protocol, Base network).
Verify a receipt hash. Returns receipt details if valid.
Output schemas completely undocumented for all 5 tools. Tool implementations call the Stillos notary API over HTTPS, but the response structure is never declared. LLMs cannot plan downstream tool calls or extract the correct fields without seeing what each tool returns.
Input parameters lack format constraints and validation guidance. 'hash' in verify_receipt has no format (hex? length?). 'resolver' in claim_verdict is a bare object without declared properties or required fields. 'ticker' in distress_score has no case-handling guidance. LLMs will guess and pass invalid values.
No error handling or recovery guidance. The code shows x402 payment continuation with multiple error codes (PAYMENT_REQUIRED, PAYMENT_REJECTED, etc.), but these are not documented in the tool definitions. LLMs receive an error but do not know: is it retryable? Should they ask the user? Is it fatal?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
No idempotency hints or confirmation patterns. claim_verdict and file_dispute perform writes and cost money, but are never marked as destructive or warned against retry without user confirmation. An agent in a retry loop could submit duplicate claims or file duplicate disputes.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The code comments in index.cjs suggest awareness of payment flows and state changes, but these semantics are never exposed to the MCP client, leaving agents uninformed about cost and side effects.