pegproof

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the description's added value is the result semantics: a look-alike answer names the imitated token, and another issuer's listed token is reported as unknown with an issuer_list field. That is real behavioral content, but with no output schema there is no fuller picture of the response shape or what an "unknown" verdict should imply for the caller.

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 purpose and pre-purchase trigger are front-loaded in the first clause, and the short "Free." sentence earns its place as a decision-relevant fact. The closing sentence referencing the equivalent REST endpoint is slightly extraneous for a tool-calling agent but is compact and supports consistency checks.

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 a single required parameter, no nested objects, and no output schema, the description carries most of the burden for return semantics and does deliver the three verdict categories plus one named field. It remains thin on the full response shape for verified/look-alike results, which is the main residual gap.

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% and the schema already specifies the 0x + 40 hex format, so the description does not need to repeat it. It does add meaning the schema lacks: the address is interpreted on Robinhood Chain, which matters because an EVM address is otherwise chain-agnostic and could produce a different verdict elsewhere.

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 opens with a specific verb and resource ("Check a contract address on Robinhood Chain") and enumerates the three outcome classes the tool resolves an address into: Robinhood-listed, known look-alike, or unknown. That makes the operation clearly a verdict/classification tool rather than a lookup like find_token or token_snapshot, though it never names those siblings to draw the line explicitly.

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 concrete trigger context: "before buying, holding or accepting it," which tells the agent exactly which workflow step calls for this tool, and "Free" removes a cost consideration. It stops short of naming an alternative tool or a when-not-to-use condition.

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 readOnly, openWorld and idempotent, so the safety profile is covered; the description adds genuine value with provenance and trust caveats (look-alikes, third-party issuers whose supply is unchecked), a 10-match cap, total count and a truncated flag. The ordering between Royerhood-issued and third-party results is implied but the term 'pegproof' is unexplained, leaving some behavioral vagueness.

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?

Front-loaded with the action, then result composition, then the truncation contract - each sentence earns its place. Some clauses are dense ('with the look-alikes pegproof knows of') and the unexplained product name costs a little clarity.

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?

No output schema exists, so the description carries the return-value burden and does so: ordering, provenance tiers, result cap, total counts and truncation signaling are all disclosed. Nothing essential for calling it correctly is missing.

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% with a single documented parameter ('A ticker (NVDA) or a company name (Nvidia)'), so the baseline is 3. The description reinforces the dual ticker/name lookup mode and ties it to the search target, adding modest confirmation value without introducing new syntax rules.

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?

States a specific verb plus resource ('find the contract address of a stock token on Robinhood Chain') and the lookup key (ticker or company name), which cleanly separates it from check_address and token_summary.

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 phrase 'before an agent buys it' establishes the pre-trade lookup context, giving clear usage timing. It does not explicitly name an alternative or state when not to use it, so it stops short of full routing guidance.

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 readOnlyHint, openWorldHint and idempotentHint=false, so the safety profile is covered; the description adds genuinely non-structured context: result ordering (newest first), the fields carried per incident, and a concrete cost model ($0.005 per call, paid via x402 in USDC on Base or Arbitrum One). The payment requirement is exactly the kind of behavioral detail an agent cannot infer from annotations. It stops short of describing pagination/truncation behavior beyond what the schema says.

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?

Front-loaded with the core action and the definition of an incident, then filters, then cost. Dense but every clause is load-bearing, with only the 'not financial advice' disclaimer being marginal filler. No structural confusion.

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 output schema, the description compensates by stating the return shape ('with its type, status and block window') and ordering, and it discloses the paid-x402 access model. For a two-parameter read tool this is close to complete; only explicit sibling differentiation and limit/pagination behavior are missing.

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 description's 'type=integrity (default), operational (collector errors) or all' essentially restates the enum plus one gloss ('collector errors'). It says nothing about `limit` beyond what the schema already documents. Baseline 3 is appropriate when the schema does the heavy lifting.

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 opens with a specific verb and resource ('Monitor all of Robinhood's stock tokens... integrity incidents, newest first') and explicitly defines what an incident is (supply/treasury divergence from the mint/burn ledger, or a ledger rebaseline). That is far beyond a restatement of the name. It does not explicitly say how it differs from siblings like token_events or token_snapshot, so it falls short of a 5.

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?

Usage is implied by 'Monitor all ... in one call' and the type filter (integrity default, operational for collector errors, all), which tells the agent which variant to pick. However, there is no explicit statement of when to use this instead of token_events/token_snapshot or what the prerequisite payment flow implies for calling order. Adequate but with clear gaps.

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 (readOnly, openWorld, non-idempotent), the description discloses the two facts an agent most needs and cannot get elsewhere: this tool costs $0.005 per call and payment is settled via x402 in USDC on Base or Arbitrum One. It also states the data provenance (reconstructed from chain event logs) and the keyset ordering basis, which sets expectations about determinism during pagination.

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?

Four dense sentences, front-loaded with the resource and event scope before parameter mechanics and cost. Nearly every clause carries weight, with only the 'not financial advice' disclaimer being questionable filler for an agent audience.

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?

No output schema exists, yet the description still reveals the pagination contract (data.next_cursor) and the ordering, which is exactly the return-shape detail an agent needs to loop correctly. Combined with cost, payment rail, and data provenance, nothing material for correct invocation is missing for a three-parameter read-only 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, but the description adds real meaning: the token parameter's ticker example (NVDA) versus a 40-hex contract address, and the fact that the cursor is opaque and keyset-based on block plus log index rather than a simple offset. Limit clamping behavior is left to the schema, which handles it adequately.

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 opens with a specific verb and resource — auditing when a stock token's supply was created or destroyed — and enumerates the event types (mint, burn, issue, redeem, transfer) with a defined ordering (newest first). That cleanly separates it from aggregate-style siblings like token_summary and token_snapshot, though it never names those siblings explicitly.

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 solid invocation guidance — pass a ticker like NVDA or a contract address, page with the cursor — but this is how-to-call guidance rather than when-to-use guidance. There is no statement of when to prefer token_snapshot, token_summary, or find_token instead, and no exclusions.

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?

Goes well beyond the annotations by disclosing that results come from the newest confirmed snapshot at or before the block (not an exact-block read), that data is reconstructed from chain event logs, and that each call costs $0.01 via x402 in USDC on Base or Arbitrum One — critical behavior given no payment parameter exists in the schema. The idempotentHint=false annotation is consistent with a 'newest confirmed snapshot' that can shift as confirmations arrive, so nothing contradicts 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?

Front-loads purpose, returned fields, usage, inputs, provenance and pricing in four tight sentences with no repeated boilerplate. The 'not financial advice' clause and payment sentence consume space but carry real decision value for an agent.

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 output schema, the description still names the three returned values (supply, treasury balance, multiplier) and explains the snapshot selection rule. Provenance, cost and payment rail are all supplied, leaving nothing an agent needs before calling a paid read 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 description coverage is 100%, so both parameters are already fully documented, and the description's 'Pass a ticker or contract address and block=<number>' merely restates them. The only added nuance is the at-or-before snapshot selection, which the block schema field already carries, so baseline 3 applies.

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?

States a specific verb and resource ('Verify a Robinhood stock token's state at a past block') and enumerates exactly what comes back: total supply, treasury balance and multiplier. The 'at a past block' / snapshot framing implicitly separates it from token_summary and token_events, so an agent can route without opening the schema.

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?

'Use it to check a historical position, report or trade against what was on-chain then' gives concrete when-to-use context tied to historical reconstruction. It stops short of naming an alternative sibling (e.g. token_summary for current state) or an explicit when-not condition, which keeps it below a 5.

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 readOnlyHint and openWorldHint, yet the description still adds material context: a per-call price ($0.002), the payment rail (x402 via USDC on Base or Arbitrum One), the data provenance ('reconstructed from chain event logs'), and a non-advice disclaimer. That payment/auth requirement is exactly the kind of operational fact an agent must know before invoking, and it is not recoverable from the 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?

The purpose and the decision it serves are front-loaded in the first clause, followed by input shapes, then return contents, then cost. It is a single dense paragraph rather than a list, and the trailing 'not financial advice' plus the duplicated enumeration of fields push it slightly past what is strictly needed, but essentially every sentence carries information.

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?

There is no output schema, so the description compensates by naming the return payloads (supply, treasury balance, multiplier, ledger coverage, integrity flags, known look-alikes), and it covers input shapes, chain, cost and payment. For a one-parameter read-only tool, an agent has everything required to decide and to invoke.

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% and the single parameter already documents the ticker or 0x-address format, so the baseline would be 3. The description earns an extra point by adding that the address must live on Robinhood Chain (chain ID 4663) and by explaining that the two input shapes produce semantically different result types (listed-token report vs. 'which token it imitates').

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 opens with a specific verb and resource plus the decision it supports: 'Check a Robinhood stock token before an agent buys, holds or accepts it', and it names what it resolves (Robinhood-listed contract vs. a known look-alike). It then enumerates the returned fields, which is unusually concrete. It never names a sibling tool outright, so the differentiation from token_snapshot and find_token is inferred from the 'is this legit?' framing rather than stated.

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 when-to-use condition is explicit and situational: before buying, holding or accepting a token. There is no when-not guidance, no statement of what to use instead for price/history (token_events, token_snapshot), and no note about what happens for an unlisted ticker. Clear context, missing exclusions and alternatives.

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