erc8004-agent-finder

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

Annotations already establish readOnlyHint=true and destructiveHint=false. The description goes beyond this by disclosing methodology: 'Every id read, nothing extrapolated' and highlighting that some registrations may not even be readable. This adds honesty about scope and limitations without contradicting 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 description is a single, information-dense sentence that front-loads the core purpose. The enumerated metrics are each meaningful, and the closing methodological note earns its place. It is slightly stylized but not padded.

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 read-only, zero-parameter statistical tool, the description is sufficiently complete: it names the chain, the registry standard, the specific metrics, and the scope of the read. Without an output schema, it could theoretically describe the return shape more explicitly, but the listed counts give a strong expectation of what will be returned.

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?

With zero parameters and 100% schema description coverage, there is no parameter burden for the description to carry. Baseline 4 applies because no additional parameter-level meaning is needed.

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 a registry census for ERC-8004 on BNB Smart Chain and enumerates the specific metrics it reports. This distinguishes it from sibling tools like find_agents_on_bnb_chain, which focus on locating agents rather than aggregating registry-level statistics.

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 makes the context unmistakable: this is the aggregate overview tool for the agent registry, listing counts such as registered agents, readable registrations, endpoint availability, responsiveness, and operators. It does not explicitly name alternatives or when-not-to-use, but the census framing is clear enough for an agent to select it appropriately.

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 readOnly/non-destructive annotations: it discloses cost and auth (free, no key), data freshness (as of the last daily read, with measured_at), and two edge cases — an unregistered id returns a plain "is not registered" message, and an uncensused agent returns in_census: false. Those are exactly the failure modes an agent needs to interpret a result.

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 the purpose, then routing, then returns, then freshness and edge cases — a sensible order with no filler. The return-value enumeration is long, though it is doing necessary work because there is no output schema.

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 carries the return contract itself and does so thoroughly: uptime, response time, escrow jobs, delivery rate with its exclusion rule, price-naming, third-party ERC-8004 ratings, and a decomposed 0-100 evidence score. Nothing needed to call it or read the answer 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%, so the format detail (digits only, not an address, not another chain's id) is already documented. The description still adds provenance — where a valid candidate id comes from — which the schema does not say.

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: "Get the measured track record of ONE AI agent on BNB Smart Chain by its ERC-8004 id." The capitalised ONE plus the id-based lookup make it clearly distinct from the census and evidence-listing siblings.

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?

Explicitly says to use this when a candidate id is already in hand (from find_agents_on_bnb_chain or bnb_agents_by_evidence) and directs the agent to those two tools to find candidates first. Both the when and the alternative are named, not implied.

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 destructiveHint=false, yet the description still adds real context: free, no key required, and critically that results are a dated snapshot of the last full read rather than a live call, with measured_at indicating recency. It also discloses that a provider with no sales returns zeros rather than an error. The only gap is return volume/shape beyond 'totals and top providers' and how 'top' is ranked.

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?

Dense but front-loaded: the core purpose comes first, then the credential/snapshot qualifiers, then sibling routing. Each sentence carries information, though the middle is packed tightly enough that a reader must parse carefully. No filler or repetition of the tool name.

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-optional-parameter read tool with no output schema, the description covers what is returned (totals plus top providers, or one provider's counts), the zero-result case, snapshot freshness via measured_at, and the absence of auth/cost barriers. Nothing an agent needs to call it correctly or interpret the result 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%, so the single address parameter is already documented, including the 'provider address or agentWallet' distinction and omitting for the whole-kernel summary. The description reinforces the omit-for-summary behavior and adds the meaningful edge case that an address with no sales returns zeros, which the schema does not state.

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: counting providers who were 'actually been hired and paid' on BNB Smart Chain via the ERC-8183 job escrow, with the concrete pipeline (created, funded, delivered, escrow released) spelled out. It distinguishes itself from siblings by contrasting self-reported registration against funded jobs, so an agent can separate it from census/chart tools without opening schemas.

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 explicit routing: use this for the whole-kernel market view or one provider's totals, use erc8183_escrow_status for a job-by-job list of a wallet you hold, and bnb_agent_chart for a single hiring decision. Both alternatives and the selecting condition are named, leaving nothing to inference.

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 only declare read-only, but the description adds substantial context: the ranking inputs (uptime up to 30 days, ERC-8183 delivery rate, outside buyer count, quoted price), the anti-bias disclosure that paid listings never change order, freshness ('as of the last daily read'), and access conditions ('free, no key').

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 purpose and alternatives, then ranking criteria, then return fields; every sentence carries information. The ranking-criteria sentence is dense and run-on, which costs a point but no content is 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 output schema provided, the description compensates by enumerating the returned agents[] fields (id, score parts, uptime_30d_pct, days_measured, median_ms, delivery pct, buyers, quote, hire info, chart link). Nothing an agent needs to select or invoke it 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%, so both parameters are already documented, but the description adds the intent behind category ('the job to hire for' among four DeFi jobs). It does not restate the limit range, relying on the schema, which is acceptable given full coverage.

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 ('Rank the AI agents on BNB Smart Chain') and narrows the scope to four named DeFi jobs ranked by measured evidence. It immediately distinguishes itself from find_agents_on_bnb_chain and bnb_agent_chart by name.

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 an explicit when-to-use ('when you need to hire for one of these four jobs'), an explicit alternative for other tasks (find_agents_on_bnb_chain), and a drill-down path (bnb_agent_chart with an id). Both the inclusion and exclusion conditions are spelled out.

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, idempotentHint, non-destructive and openWorld, so the baseline is covered. The description still adds real context beyond them: free/no key, the 21:45 UTC daily snapshot and its staleness implication, the excluded campaign address, and the refusal/empty-result behavior. It does not cover pagination or result ordering, but with strong annotation coverage this lands between an adequate 3 and a 4.

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 purpose, then usage, then explicitly labeled 'Returns:' and edge-case sentences. It is long, but with no output schema the return enumeration earns its space; only the exclusion parenthetical about the campaign address is slightly heavy.

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?

Covers everything needed to call it correctly and interpret results: the return shape (summary, as_provider[], as_client[]), data freshness, malformed-input behavior, and the empty-wallet case. Since no output schema exists, the description properly carries the return-value burden.

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 is already documented as '0x + 40 hex (a provider, an agentWallet, or a client)', so the baseline is 3. The description adds meaning beyond it by naming the three wallet roles in context of the returned as_provider/as_client split and by stating the exact validation outcome for a malformed address.

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 ('List every ERC-8183 escrow job one wallet sells or buys on BNB Chain'), plus the value-add of next step and deadline per job. It explicitly separates itself from bnb_agent_chart and bnb_agent_employment, so an agent can route correctly without opening a 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?

Gives a positive trigger (you hold a provider wallet, agentWallet or client wallet) and the concrete questions it answers: waiting for delivery, in dispute window, pay waiting to be released, expired with refund due. It also gives an explicit exclusion with named alternatives for pre-hire vetting and kernel-wide totals.

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=true and destructiveHint=false, so the safety profile is given; the description nonetheless adds genuinely useful context beyond them: free, no key, sourced from the last daily census, and that a no-match outcome returns returned: 0 rather than an error. It does not cover latency, rate limits, or pagination beyond the limit parameter, so it is good but not exhaustive against a lower bar set by 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?

Front-loaded with the core purpose and the disambiguation before the long return-shape enumeration, and every clause carries information. The return-field list is dense and long, but since there is no output schema it is load-bearing rather than filler; slight trimming of the enumerated fields would improve scanability.

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 carries the return contract and does so in detail: results[] ordering, per-result fields (id, name, description, speaks, endpoints, tools, skills, escrow, match, next step), plus searched and the count of additional matches. Combined with the no-match-is-not-an-error note and the sourcing caveat, an agent has everything needed to call and interpret 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 baseline is 3 and every parameter (query, limit, speaks, hireable) is already explained in the schema with examples and allowed values. The description reinforces 'in plain words' and mentions speaks (mcp, a2a, x402) and price-answering in the return field list, but adds no filtering or syntax detail the schema lacks.

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 ('Search the AI agents on BNB Smart Chain that can do a given task') and immediately bounds the corpus to ERC-8004 agents that actually answered, matched against returned tools and on-chain descriptions rather than self-reported categories. It also names two sibling tools and what they do differently, so an agent can distinguish it from bnb_agents_by_evidence and bnb_agent_chart without opening schemas.

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 explicit when-to-use ('Use it before assuming no agent exists for a task') and explicit alternatives with selection criteria: bnb_agents_by_evidence for the four named DeFi jobs because it ranks by track record, bnb_agent_chart to check one result before hiring. Both the positive case and the routing rules are stated.

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