aspern

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

No annotations are provided, so the description must carry the burden. It usefully discloses the 50-address cap and cost ('one cent a call over x402'), but it does not state whether the operation is read-only, what 'observations' contain, or how invalid or partial results are handled.

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?

Each sentence earns its place: the first covers the action, limit, and target use case; the second covers pricing. The colon before 'for an agent...' is a bit awkward, but the description remains compact and readable.

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?

For a one-parameter call, it covers the purpose, batch limit, audience, and cost. However, with no output schema and no annotations, the description leaves 'observations' undefined and does not describe the response shape, which an agent needs to consume the result.

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 only parameter 'addresses' is already documented in the schema with 'Up to 50.' The description adds that these are counterparty addresses and repeats the limit, but provides no extra detail on address format or validation, so it adds little beyond the schema.

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 ('Check') and resource ('up to fifty addresses'), each returning observations, so an agent understands the bulk checking action. The batch scope is explicit, though it does not name the sibling counterparty_check to distinguish single-address checks.

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?

Gives a concrete scenario: 'for an agent or a desk holding a list of counterparties before paying any of them.' It does not explicitly say when not to use it or point to an alternative for a single address, but the use-case context is clear.

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?

With no annotations provided, the description carries the full transparency burden and succeeds: it outlines what data is returned, notes that the tool is free, and explicitly spells out two interpretational limitations (independence does not prove separate parties, and all-time records do not guarantee current activity). This goes well beyond a typical description and prevents misuse.

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 front-loaded with purpose and output categories, followed by cost, limitations, and accepted inputs. It is longer than typical, but every section earns its place, especially the caveats that are essential for correct interpretation. A slightly tighter layout would push it to 5.

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?

For a single-address check with no annotations and no output schema, the description is remarkably complete: it covers the trigger, the data fields returned, the caveats, the cost, and the accepted input formats. An agent has everything needed to call and interpret the tool 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 coverage is 100%, so the baseline is 3, but the description adds meaningful semantics by enumerating accepted address formats: EVM, Cardano (addr1…), and Solana. The schema only says 'the address you are about to pay or hire,' so the description enriches the parameter with concrete acceptance criteria.

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 the exact use case ('Before paying or hiring an agent') and specifies the resource ('what the chain records about that address'). It enumerates distinct output categories (independent payers, paybacks, concentration, ACP jobs, service responsiveness, last payment), making it easy to distinguish from siblings like counterparty_bulk or counterparty_history.

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 clearly states when to use the tool: before paying or hiring an agent. It does not explicitly name alternative tools for other scenarios, so it earns a 4 rather than a 5, but the context is strong enough that an agent can infer this is the single-address pre-payment check.

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?

No annotations are present, so the description carries the burden. It discloses a pay-per-call requirement (one cent over x402), the unpaid response behavior (returns price and how to pay), and a data-availability limitation (history starts when record-keeping began). This is useful, but it doesn't clarify read-only nature, return format, or side effects, leaving gaps.

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 relatively short but stylistically ornate ('how one agent's record has moved' and 'a record we keep, not one the chain gives away'). It front-loads a vague metaphor rather than a direct purpose, and the payment details are embedded mid-description rather than clearly separated. Efficient in length but not optimally structured.

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 annotations and no output schema, the description must compensate. It mentions payment behavior and data scope, but it omits what the tool returns (e.g., fields, format), prerequisites beyond payment, and how the parameters shape results. For a two-parameter tool, this leaves agents uncertain about successful invocation and interpretation of results.

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 exactly 50%: 'days' is described (1 to 365, default 90), but 'address' has no schema description. The tool description adds no meaning for either parameter—it doesn't clarify what 'address' refers to or how 'days' interacts with the history. Given the moderate coverage and no compensatory description, the score is low.

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 hints that the tool shows how an agent's record has moved (dealings, payers, concentration, delivery) over days, which aligns with the name 'history'. However, it lacks a crisp verb+resource statement and does not explicitly differentiate from sibling tools like counterparty_check or counterparty_bulk, leaving the purpose somewhat inferential.

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?

No guidance is given on when to use this tool vs. the listed siblings (counterparty_bulk, counterparty_check, find_agents, preflight_payment). The description only mentions payment mechanics, not selection criteria or 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?

With no annotations, the description carries the full burden and does well: it names the data rails, the filter criteria, and adds an important caveat that absence from results only means no payment was seen on a tracked rail. It does not disclose output format or pagination, but this is a read-only find tool and the behavioral picture is reasonably complete.

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: the first sentence establishes purpose and core filters, and the final sentence adds a valuable interpretive caveat. The standalone 'Free' sentence is slightly unusual but still relevant; overall there is little wasted text.

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?

For a 10-parameter tool with no annotations and no output schema, the description provides substantial context: rail scope, filter semantics, cost, and data-coverage limitations. It is still incomplete for full invocation because it does not explain return values, sorting behavior, or the meaning of every parameter such as registered.

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 only 40%, so the description must compensate. It adds meaning to several parameters by describing filters like independent payers, dealings, ACP completion, and paying own payers back, which map to minIndependent, minDealings, minCompletion, and noTwoWay. However, it never connects these terms to parameter names and leaves sort, registered, and other params unexplained.

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 states the tool finds agents to hire based on on-chain payment evidence across named rails, with specific filter dimensions. It is distinct from the sibling counterparty_* tools by focusing on agent hiring rather than counterparty checks, though it never explicitly differentiates itself.

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 usage context is implied: use this tool when you need to identify agents with verifiable on-chain work history rather than self-reported claims. However, there is no explicit when-not guidance or routing to alternative sibling tools, and 'Free' is the only additional usage hint.

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?

No annotations are provided, so the description carries the full burden. It discloses the three possible verdicts and their precise meanings, including that 'nothing-against-it' is NOT a safety guarantee, and that 'cannot-say' must never be read as the first. It also explains that missing fields mean checks didn't run. This is exemplary transparency.

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 a single coherent paragraph that front-loads the immediate action ('Call this immediately before sending a payment'). It is longer than minimal but every sentence adds substance, explaining the checks, verdicts, and limitations. Structure is logical and scannable.

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's complexity (4 parameters, no output schema, no annotations), the description is remarkably complete. It explains the verdicts, the impact of missing parameters, the free nature, and the inherent limitations (cannot see the purpose of payment). Nothing an agent needs to call it correctly is omitted.

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 schema already documents each parameter. The description adds value by explaining that each missing parameter means a check didn't run, and specifically highlights 'resource' as the sharpest check with the seller's own price and payee address. This goes beyond the schema.

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 states the tool's purpose: preflight a payment against historical data to get a verdict. It specifies the verb 'preflight' and the resource 'payment', and explains what it weighs (amount, chain, endpoint vs. address history). It doesn't explicitly name sibling tools or contrast with them, but the purpose is distinct and unambiguous.

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 explicit when-to-use guidance: 'Call this immediately before sending a payment, every time — not once per counterparty.' It also advises on what to provide ('Give as much of amountUsd, chain and resource as you have'). It doesn't explicitly state when not to use it or mention alternatives, but the context is clear.

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