Enclave402

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

The description discloses important runtime behaviors beyond annotations: settlement of $0.040 USDC via x402 on Base, no charge on failure, receipts at /api/ledger, attestor key location, and offline verification method. This goes well beyond the readOnlyHint/destructiveHint annotations and gives the agent confidence about side effects and failure economics.

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

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

The description is dense but every sentence carries decision-relevant information: mechanism, use case, exclusions, cost, failure behavior, and receipt location. It is front-loaded with the core mechanism, and the usage guidance is immediately actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers mechanism, verification, use cases, exclusions, pricing, failure policy, and related endpoints, while the output schema covers return values. The only minor gap is that the schema marks state as optional, while the description's 'binding an agentId, the keccak256 digest of a declared state, and the paying wallet' implies a state is always part of the attestation; this edge case is not clarified.

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

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

Schema description coverage is 100%, and the schema already explains keccak256 hashing and that the raw string is never stored. The description adds conceptual framing around agentId and state digest, but does not materially improve the caller's understanding of how to fill the parameters beyond what the schema provides.

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

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

The description clearly identifies the tool as creating an EIP-712 signed, timestamped attestation binding an agentId, state digest, and paying wallet. This is a specific action over a specific resource, and the verifiability/offline nature distinguishes it from the sibling tools that fetch gateway info, market signals, or pin storage.

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

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

It explicitly states when to use the tool ('MUST be invoked when an agent needs third-party, non-repudiable proof...') and when NOT to use it ('Do NOT use for hardware TEE, zk proofs or on-chain EAS'), naming the excluded alternatives. This gives an agent clear selection criteria.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond those annotations: the tool is free/no-payment required, should be called before paid operations, and exposes readiness and public transparency URLs. This complements the annotation safety profile without contradicting it.

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

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

The description is compact but information-dense: it front-loads the free/no-payment nature, lists the exact facts returned, states the mandatory usage point, and gives an exclusion. Every phrase earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no input parameters and no output schema, the description still enumerates the returned facts in enough detail to set expectations. It also covers the critical sequencing requirement and the tool's non-application to market data or attestation, making it effectively complete for this simple info tool.

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

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

The tool has zero parameters and schema coverage is complete, so no parameter documentation is needed. Baseline for zero parameters is 4, and the description adds enough surrounding context to make invocation straightforward.

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

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

The description clearly identifies the tool's resource as gateway facts and prices, enumerating specific contents (network, payee, attestor, prices, readiness, ledger, transparency URLs). It explicitly separates itself from market data and attestation, which distinguishes it from sibling tools like get_market_signal and attest_agent.

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

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

The description gives an explicit timing instruction: 'MUST be invoked before the first paid call from a new agent.' It also provides clear negative guidance: 'Do NOT use for market data or attestation,' which helps an agent choose this tool over alternatives.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds genuinely new behavioral context: it settles $0.010 USDC via x402 on Base, charges nothing on failure, exposes public receipts at /api/ledger, and mentions a deterministic momentum label. This goes well beyond the structured annotations and contains no contradiction.

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

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

The description is compact and front-loaded with the core payload, then quickly moves to usage triggers, exclusions, and billing behavior. Every sentence adds distinct information, and there is no filler or repetition of the annotations without value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a read-only market-data lookup with an output schema and fully described parameters, the description is complete: it explains what the tool returns, when to use it, what not to use it for, cost, failure behavior, and where receipts live. No meaningful gap remains for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the parameters are already fully documented: slug selects one market and limit caps top-market results when slug is omitted. The description doesn't add much parameter-level detail, but it doesn't need to because the schema carries that load. Baseline 3 is appropriate.

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

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

The description names a specific resource (Polymarket prediction-market signal) and the exact data it returns: outcome prices, bid/ask/spread, 24h change with momentum label, volume, and liquidity. It also clearly distinguishes this from other tool purposes by explicitly saying it must be used for crowd-implied probabilities and must not be used for spot token prices or swap quotes.

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

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

It gives explicit trigger conditions: use when an agent needs a crowd-implied probability of a real-world event or the most-traded markets right now. It also states negative usage constraints, such as not using it for spot token prices, swap quotes, or order execution, making the decision boundary unambiguous.

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

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

Beyond the annotations, it discloses pricing and settlement details ($0.008 USDC via x402 on Base), failure behavior (failed/unavailable pins are never charged), and the receipts endpoint (/api/ledger). These are meaningful behavioral traits not present in the structured annotations.

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

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

Every sentence earns its place: the action is front-loaded, usage guidance follows immediately, exclusions are compact, and payment/failure behavior is concise. The description is dense but not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema, the description need not detail return values; it already states the key outputs (CID v1 and gateway URL). It covers purpose, constraints, settlement, failure charging, and receipt access, leaving no critical gap for an agent deciding whether and how to invoke the tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by reinforcing the allowed content types and size limit while explicitly forbidding an existing CID, which is a usage caveat not visible in the schema. It does not add much detail about the optional name parameter, but the schema already documents it.

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

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

The description names a specific action (store), a specific resource (JSON document on IPFS via a managed pinning service), and the result (CID v1 plus gateway URL). It is clearly distinct from sibling tools like attest_agent, get_gateway_info, and get_market_signal.

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

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

The description explicitly states when it MUST be invoked: when an agent needs durable, content-addressed storage for memory, decisions, artifacts, or metadata fetchable by CID. It also gives concrete exclusions: no raw binary, no files over 8 KB, and no re-pinning an existing CID.

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