Skip to main content
Glama

x402 Bureau — reputation from signed observation history (PAID $0.10)

v1_bureau_reputation

Computes reputation from signed observation history for a subject to support trust decisions; paid x402 route settles in USDC on Base and returns a transaction hash.

Instructions

x402 Bureau — reputation from signed observation history (PAID $0.10)

Remote route: POST /v1/bureau/reputation (0.10 USD x402/base/usdc on eip155:8453).

Input Schema

NameRequiredDescriptionDefault
eventsNo
subjectYes

Output Schema

NameRequiredDescriptionDefault
statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.3/5.0
Behavior3/5

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

The description adds useful behavioral context beyond annotations by disclosing that the route is paid at $0.10 via x402/base/USDC on eip155:8453. Annotations already indicate this is not read-only, is open-world, non-idempotent, and non-destructive, so the lower bar applies. However, it does not explain payment flow, auth requirements, or what happens to supplied observations.

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 short and the route/payment details are useful and front-loaded enough to scan quickly. Its main inefficiency is that the first clause duplicates the title almost exactly rather than adding new information.

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?

Although an output schema exists, the description is incomplete for a paid, open-world, non-idempotent reputation tool with an undocumented required subject and events parameter. It gives no usage guidance, no parameter semantics, and no explanation of how payment is handled beyond the price and route.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain either parameter. The required 'subject' and optional 'events' array are left entirely undocumented; the phrase 'signed observation history' only loosely hints at events and gives no semantics for subject.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description largely restates the title/name: 'reputation from signed observation history' is already conveyed by the tool name and title. It adds the paid remote route, but does not clarify what computing reputation actually means or how it differs from sibling reputation tools such as v1_agent_reputation or v1_agent_reputation_trusted_route.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the many sibling reputation or attestation tools. The only contextual information is the paid route and price, which does not tell an agent when this tool is appropriate or when another tool should be selected.

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