Taifoon coordination layer

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the auth requirement (only the on-chain owner's signature; EIP-191/personal_sign), replay protection (a nonce works once), the two-phase protocol, and the concrete side effects on the write path (stores enrichment, probes the first endpoint, queues for the harvester, returns new readiness).

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?

Three sentences, front-loaded with purpose, then the two mode-split flows, then the constraint on accepted signatures. Dense but every clause (nonce freshness, EIP-191, harvester queueing) carries information; nothing 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?

For a mutation tool with no annotations, no output schema, six params and a nested data object, the description covers the protocol, side effects, and auth constraints well. It stops short of explaining chain_id and confirmation/error behavior an agent might need on the write path, but the omission is minor relative to what is provided.

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 only 17%, so the description must compensate. It adds meaning for the enrichment payload fields (card_url, endpoints, skills, classes) and the signature/nonce/expires flow, but leaves agent_id and chain_id unexplained and gives no format detail for the signature string itself, so the gap is only partially closed.

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 (Enrich) and resource (an agent) plus the exact owned fields (card URL, endpoints, skills, class opt-in), and qualifies it as the ERC-8004 owner action. This clearly separates it from siblings like taifoon_agents_register and taifoon_register, which handle registration rather than post-registration enrichment.

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 two-mode flow (no signature -> get message to sign; with signature/nonce/expires -> store) provides real invocation context, but it never states when to prefer this over sibling tools such as taifoon_agents_register or taifoon_agent_readiness, nor any prerequisite beyond being the owner. Usage is implied through the flow description rather than explicitly routed.

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. It does disclose the return structure in detail (13-step ordered checklist, ok|missing|pending|blocked statuses, fixer role, exact API/on-chain call, evidence), which is genuinely useful. But it never states whether the tool is read-only or side-effect free, nor any auth/permission needs, leaving the safety profile unstated.

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 opening sentence is a long, run-on construction packed with parentheticals and undefined pipeline jargon ('pool_eligible', 'graded', 'calibrated'). It is dense rather than front-loaded, forcing the reader to parse a 13-step chain to extract the core purpose.

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 4-parameter, no-output-schema, no-annotation tool, the description does describe the return shape well. But it omits tenant semantics and does not size the response or clarify what 'summary' changes about the returned shape, leaving gaps an agent would want before calling it.

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 50%, so the description must compensate. It explains the summary flag's behavior and implies agent_id via 'one agent', while agent_id/chain_id are already documented in the schema. The 'tenant' enum (moonbeam | taifoon) is left unexplained in both schema and description.

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 makes clear this is a readiness/diagnostic computation over a single agent, and explicitly contrasts the single-agent mode with the summary funnel over every harvested agent. It lacks a clean leading verb, but the resource ('agent readiness') and scope are discernible despite the jargon-dense phrasing.

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 one concrete usage instruction ('Pass summary:true for the funnel over every harvested agent'), which is real guidance. However, it never states when to use this versus overlapping siblings like taifoon_hire_lifecycle, taifoon_hiring_stages or taifoon_onboarding_flows, and names 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?

With no annotations, the description carries the full burden and does disclose notable behavior: the card is fetched server-side, a caller cannot register a description (only a URL), and the ERC-8004 binding semantics. It does not mention auth/ownership requirements or rate limits, so it is strong but not exhaustive.

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 core action, then the parameters, then the next steps. It is dense and mostly earns its length, with only minor embedded detail (the parenthetical and next-step alternatives) that could be trimmed.

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 multi-step registration tool with no annotations and no output schema, the description supplies a return summary, binding semantics, and a follow-up routing path. It is nearly complete, missing only explicit auth/permission expectations for who may register.

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 0%, so the description must compensate, and it does — it explains card_url accepts three card formats, and that chain_id + agent_id reference the ERC-8004 record that binds the owner. It adds real meaning beyond the bare property names, though the exact format of agent_id/chain_id values is not spelled out.

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+resource (register an agent) and the mechanism (by the https URL of its own card). It is clear and detailed, but it never explicitly distinguishes itself from the sibling taifoon_register, so the agent must infer the boundary between the two.

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 clear usage context: pass chain_id + agent_id of the ERC-8004 record to bind its owner, and outlines the next steps (mint with taifoon_assurance_call or read with taifoon_offers). It also states a constraint (only a URL, not a description, can be registered), though it doesn't state when NOT to use this tool versus taifoon_register.

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 substantial work: it discloses that the node is measured per pass (fresh arithmetic battery), pricing is live GPU unit-hour pro-rated to measured seconds, an evidence digest keccak256(request||response) is produced, settlement is UNSIGNED assurance calls (fund-job → submit → complete), and that 'you sign'. That is rich behavioral context — auth/signing, side effects, pricing — though it omits failure handling and reversibility.

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 is front-loaded, but the opening is one very long, jargon-dense sentence (

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 5-param tool with no annotations and no output schema, the description conveys the operational flow, pricing model, settlement steps, and signing requirement, which is close to complete. Minor gaps remain around return payload and error behavior, but the core is covered.

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 all five parameters are already documented; the baseline is 3. The description mostly restates schema content (hirer records intent in the Grid ledger) and adds only the prompt-absent listing behavior, so it adds little meaning 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 and resource ('One AI call against a node the gateway has MEASURED for that model') with concrete scope — measured nodes, GPU-priced, on-chain settlement. It is clear what the tool does, but it never names a sibling (e.g. taifoon_assurance_call or taifoon_grid_hire) to distinguish it from the many other call/hire tools.

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 implies usage through 'Give `hirer` to record the intent' and the fallback 'Without a prompt it lists the measured nodes and the rate', which is a useful mode switch. But there is no explicit when-to-use-this-vs-alternatives guidance or prerequisites for choosing it over sibling hiring tools.

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 load and does disclose a critical behavioral trait: the output is unsigned and this tool never signs or sends anything, which is the safety-relevant fact an agent needs. It also states each call self-describes its effect and required signer. It stops short of describing permissions or the concrete output format, keeping it off a 5.

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?

Two dense sentences that front-load the core purpose and the non-signing guarantee. The parenthetical chain list is information-dense rather than padding, though the em-dash aside slightly interrupts flow.

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 and no annotations, so the description must do more work than it does. It establishes the tool's purpose and non-mutating nature but leaves the structure of the returned calls, signer requirements per action, and the full action-field contract to inference.

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 50 percent. The description adds real meaning for chain_id by mapping 8453 to Base, 5042 to Arc, and 36927 to the Taifoon devnet, which the schema does not explain, and it names the action kinds tied to action.kind. The individual action object fields and the return shape remain undocumented.

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 states a specific verb+resource: it produces 'the exact UNSIGNED calls for an assurance action', and it enumerates the seven action kinds (fund-job, submit, complete, expire, reject, create-pool, back-seller). An agent can tell this is a transaction-call builder rather than an executor, though it does not explicitly name a sibling alternative to distinguish it from tools like taifoon_judge_compose.

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 implies the usage context by noting 'nothing here signs or sends', which suggests this is a preparation step ahead of signing, but it never states when to prefer this tool over the many sibling tools or what prerequisites the caller must satisfy. Usage is inferable but not 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?

With no annotations, the description carries the full burden and does disclose key traits: nothing is signed or sent (non-mutating), fees are levied through a CCTP router at 10 bps with a 0.02 USDC minimum, and the return is a set of approve + bridge calls. Auth requirements and any rate limits are still unstated, keeping it from a 5.

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?

Two dense sentences, front-loaded with the purpose and the API route before the behavioral and parameter detail. Every clause carries information; it is compact without being cryptic.

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 planning tool with no annotations and no output schema, the description supplies the essential context: what it returns, that nothing is signed, and the fee model. Remaining gaps are sender/recipient/speed semantics and any auth notes, but overall it is sufficient for correct invocation.

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 0% across 6 params, so the description must compensate. It covers src_chain_id/dst_chain_id (with 8453 Base and 5042 Arc examples) and the amount unit (USDC smallest units, 6 decimals), but sender, recipient, and speed enum remain undocumented in both schema and description.

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?

Specific verb (Plan) plus resource (USDC transfer across chains), with the API route named and the exact output framed as 'the exact approve + bridge calls... the fees and what arrives.' The 'plan / nothing is signed' framing cleanly distinguishes it from execution siblings like taifoon_transfer_attest.

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 'Nothing is signed or sent' implies this is the pre-execution dry-run, which helps an agent infer when to reach for it. However, no sibling is named as the alternative (e.g. taifoon_transfer_attest for the actual signed transfer), so the when-to-use routing is left 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?

With no annotations, the description must carry the safety profile, and it does state 'Free, read-only', which is a genuine behavioral disclosure. It also describes the pricing composition (seller price + fee.bps) and that settlement happens on devnet 36927. Gaps remain: pagination behavior for limit/offset and result-set shape are not described.

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?

It is a single compact paragraph, but it is a run-on that mixes this tool's behavior with downstream buy/pool/settlement mechanics, making it dense and hard to scan. The key purpose is front-loaded, which saves it from being worse.

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 7-parameter tool with no annotations and no output schema, the description partially compensates by enumerating returned per-agent fields (seller price, our price, cover, grade). But pagination semantics and the exact response shape are left unstated, so an agent must still infer some call details.

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 57%, so the schema carries much of the semantics. The description adds meaning for id ('id reads one entry') and status ('buy_now entries'), and the catalog_id convention, but says nothing about q, class, protocol, limit or offset beyond what the schema already 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 opening clause states a concrete verb+resource ('Every hireable agent the coordination layer resells' at GET /v1/catalog) and adds scope detail ('id reads one entry'). It is reasonably distinguishable, but offers no explicit contrast with nearby listing tools like taifoon_discover or taifoon_offers, leaving the agent to infer the split.

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 one useful routing rule ('status buy_now entries are bought with taifoon_post_demand { catalog_id }') and mentions the cover comes from taifoon_pool_quote/post open. However there is no explicit when-to-use-this vs the many sibling discovery/hire tools, so guidance is only partial and 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?

With no annotations, the description carries the full burden and discharges it well: it discloses the full state machine, what terminal:true means, the transition sequence, and the timing envelope. It omits auth/permission requirements and any rate-limit specifics, but the return-shape and terminal semantics are thoroughly covered.

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 what is returned, then the state flow, then the polling contract. It is dense but nearly every clause (state names, terminal flag, cadence) carries useful information, with only minor redundancy between the endpoint string and the 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?

There is no output schema, so the description must explain the return payload, and it does so thoroughly (state, seller, handshake, code grade, devnet job id, transaction). Combined with the terminal flag and polling cadence, an agent has what it needs; only auth expectations are unaddressed.

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 id format (dm_ + 24 hex) is documented in the schema itself. The description adds only the GET path template, which is redundant with the schema, so the baseline of 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: it retrieves ONE demand plus every step the auto-match loop wrote on it. The state enumeration (open → claimed → matched → hired → graded → settling → settled, or unmatched/failed) and the GET endpoint make it instantly distinguishable from the plural taifoon_list_demands and the related taifoon_grid_status/hiring_stages 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?

Gives concrete operational guidance: poll every 30–60 s and expect settlement within ~15 minutes, plus the terminal:true signal for stopping. It does not explicitly name list_demands as the alternative for querying multiple demands, so routing is implied rather than stated, but the when-to-poll guidance is clear and actionable.

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 must carry the behavioral load. It does state 'Free, read-only,' which discloses the safety/cost profile, but it doesn't explain return formats, pagination behavior, rate limits, or what 'probes' means. For a multi-endpoint discovery tool with zero annotation coverage, this is only partially adequate.

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 packs multiple clauses separated by dashes and semicolons into one long sentence, which is dense and somewhat hard to parse on first read. It is front-loaded with the core purpose but the branching logic is buried in a run-on structure.

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 discovery tool with no output schema, the description covers the main modes and endpoints, but it omits the 'limit' parameter semantics, return value shapes, and the meaning of 'probes' and 'ranked sellers'. Given the 33% schema coverage and no output schema, more completeness is warranted.

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 33%, so two of the three parameters ('limit' and 'hireable') are undocumented in the schema. The description explains what 'class' and 'hireable' do functionally, but says nothing about 'limit' (the pagination cap of 1-200). It partially compensates for the low schema coverage but leaves the limit parameter 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 states a specific verb ('Discover') and resource ('who can do a job') and then breaks down three distinct modes tied to parameters, each mapped to an endpoint. It is clear what the tool does, though some phrasing like 'the seller chooseSeller picks first, with its record and probes' is domain-specific and opaque without prior knowledge of the system.

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 effectively maps parameter combinations to outcomes: without 'class' returns job classes, with 'class' returns ranked sellers, and with 'hireable:true' returns hireable agents. This gives clear conditional guidance for when each mode applies, but it does not name sibling tools (e.g., taifoon_hire, taifoon_match) as alternatives or state when not to use this tool.

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 exist, so the description carries the full burden, and it delivers: 'Free, read-only', reply text is 'never' returned (only the digest), and devnet test tokens 'have no value' while Base 'moves value'. It omits pagination behavior and rate/limit handling, but the disclosed behavioral traits are substantive.

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?

A single dense paragraph, but front-loaded with the resource and scope, and the long field enumeration carries genuine information rather than padding. Denser than ideal, yet nearly every clause earns its place.

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 describe both safety profile and returned data, and it does both thoroughly via the per-job field list and the read-only/free statement. The main omission is pagination and how page/limit interact.

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?

At 56% schema coverage the description adds real meaning: it explains id (single-job lookup), view=counts (totals, no rows), the chain labels and their value implications, the buyer categories, and the seller/doer/payee distinction ('doer_is_payee'). This compensates well for the gaps in kind, page, limit, and class.

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 resource and scope: 'Every job that went through the Taifoon coordination layer', with the endpoint and a detailed per-job field enumeration. It is clearly the jobs explorer, distinguishable from siblings like taifoon_list_demands or taifoon_metrics, though the verb is more implied ('explorer') 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?

Gives parameter-level usage hints ('id reads one job; view counts gives the totals') but no tool-level when-to-use guidance or exclusions relative to sibling list/status tools such as taifoon_demand_status or taifoon_list_demands. Usage is implied rather than routed.

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 behavioral burden. It discloses what the output describes (finality conditions + proof layout) and its provenance ('Synced from TaifoonV5Types.sol + the spinner mapper'), which signals authoritative, likely static reference data. However, it never states that the call is read-only/side-effect-free or whether out-of-range ids error, so disclosure is partial.

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?

Two tight sentences with the core purpose front-loaded and supporting detail (proof layout, provenance) trailing. No filler. The provenance clause is slightly tangential but earns some place as a trust signal.

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 and no annotations, the description sensibly names what the explanation will contain, which is the key thing an agent needs to know before calling. For a single-parameter, read-only explainer this is close to complete; the only missing piece is confirming it is non-mutating.

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 0%, so the description must compensate for the single parameter. It does add meaning: the parameter is a 'V5 L6 finality type id' and its valid range is 0-15. But it does not enumerate what the individual ids mean, leaving the id space opaque. This is more than the bare integer schema but not a full compensation.

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 ('Explain') and a precisely scoped resource (a V5 L6 finality type id in 0-15), plus what the explanation covers: block finality conditions and proof layout. It is clearly a read-only explainer, distinct from the action-oriented siblings like taifoon_grid_* and taifoon_hire_*. It does not explicitly name a sibling alternative, so it lands at 4 rather than 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: an agent would call this when it needs to interpret a finality type id. There is no explicit when-to-use statement, no when-not-to-use, and no alternative tool named (e.g., a general proof or superroot lookup that might overlap). Adequate but with a clear gap.

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 discloses that the key is forwarded but never stored, the exact failure mode (403 byo_key), the batch cap of 4 items, and that it is a single calibrated call. It stops short of describing the response payload or behavior on malformed items.

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?

One tight sentence with the core action front-loaded and the credential/error details tucked into parentheses. Every clause adds information; nothing is padding.

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 and no annotations, so the description is the only contract. It covers the required items and typesafe_key well but leaves three optional parameters (api_key, options, question) entirely undocumented, which is a meaningful gap for a 5-parameter 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 0%, so the description must fill the gap. It usefully enumerates the accepted item shapes ({id,state} | {id,handshake_id} | {id,jobId,chainId}) and confirms typesafe_key is the credential, but api_key, options, and question are never mentioned, and the api_key/typesafe_key overlap is left ambiguous.

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 ("Grade") with a bounded resource ("up to 4 items") and the mechanism used (ONE calibrated TypeSafe/Jev call). It is clearly a grading tool, though it does not explicitly position itself against similar siblings like taifoon_judge_compose or taifoon_assurance_call.

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 real precondition (must supply YOUR OWN TypeSafe key, otherwise the route answers 403 byo_key), which tells the agent when the call will succeed or fail. However, it offers no guidance on when to choose this over the other judge/assurance tools.

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 behavioral burden and discloses substantial context: automation levels (FULL/ASSISTED/HUMAN), staking confirmation responsibility, inclusion of human steps and provider commands, the returned one-line runner, and the important safety note that signing steps are printed for the operator and never run. It stops short of covering auth needs, rate limits, or whether the runner itself executes anything.

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 front-loads the core purpose and then packs in useful detail about output, automation levels, commands, and safety. It is dense and slightly run-on, but the length is largely justified by the catalog-style scope and the exact runner command.

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 must describe return behavior, which it does by explaining that each avenue includes automation level, staking status, pay, human steps, provider commands, and doc links, plus the returned runner command. It is complete enough for an agent to understand what the tool provides, though error handling and pagination are not covered.

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 fully documents both id and resource, including enum values and examples. The description adds only 'Filter by id or resource,' which repeats the schema and provides no additional syntax or behavioral detail beyond 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 states a specific resource and scope: Taifoon workflows for earning elsewhere from a Grid box across named providers, with automation levels and returned runner commands. It clearly distinguishes this from core Grid operations, though it does not explicitly differentiate the tool from all sibling tools such as taifoon_grid_join or taifoon_grid_economics.

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 implies usage through its purpose and mentions filtering by id or resource, but it does not explicitly say when to choose this tool over alternatives or state when not to use it. The runner command mentions plan/check/run modes, which gives some implied usage context, but no sibling routing is provided.

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 it discloses meaningful behavior: the exact shell command that runs on the box, what it inspects (NVIDIA card, VRAM, CPU, RAM, disk), the economic split (70/20/10), and the verification gate ("the gateway asks the model an arithmetic battery before it counts"). It does not state that the tool itself is a read-only/informational operation or note any auth or rate-limit requirements, so it stops short of a 5.

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 lead clause is front-loaded and states the payoff ("see what it could earn"). The single dense paragraph is long but nearly every clause adds distinct information (command, join line, split, verification). Slightly heavy for a definition of this kind.

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 must describe the returns, and it does so concretely: the curl one-liner, the join line, and the quote fields including the 70/20/10 split and per-call price. Combined with the verification caveat, an agent has enough to call it correctly, though the lack of any read-only/auth framing leaves a minor 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 description coverage is 100%, so the schema already documents gpus, vram_gb and owner. The description adds the behavioral meaning of vram_gb/gpus (they yield the model tier without running anything) but says nothing about the owner wallet beyond the schema's own note, 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 ("Benchmark a machine for the Taifoon Grid") and enumerates exactly what it returns (bench command, join line, live quote with splits and per-call price). An agent can tell it produces an economics/preview package rather than performing a join or querying prices. It does not explicitly name the sibling tools it overlaps with (taifoon_grid_join, taifoon_grid_prices), 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?

It gives one conditional usage hint ("Give vram_gb and gpus to get the model tier without running anything"), which is genuinely useful. However it never says when to prefer this over the sibling tools that cover overlapping ground (grid_join, grid_prices, node_command), leaving the routing decision 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?

With no annotations, the description carries the full behavioral burden. It does disclose one genuinely important trait: a null result means the oracle did not answer and must not be read as zero, which guards against a costly misinterpretation. However, it says nothing about authentication, rate limits, caching, or freshness guarantees beyond 'live'.

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 core purpose is front-loaded in the opening clause, and the null-vs-zero caveat is appended at the end where it belongs. The middle clause is dense (GRID hourly/daily, USDC at the oracle peg, and the derivation rule) but each element adds information, so little is wasted.

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 zero-parameter, annotation-free, output-schema-free query tool, the description covers the returned fields (hourly/daily GRID, USDC equivalent, derivation rule) and the key edge case (null oracle response). It is nearly complete; only the surrounding operational context, such as expected freshness or failure modes beyond null, is absent.

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 takes zero parameters, so there is no per-parameter semantics to document and the baseline of 4 applies. The description correctly focuses on what is returned rather than inventing input concepts.

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 states a specific function: returning the earning economics of sharing one resource (GRID per hour/day, USDC equivalent at the oracle peg, and the derivation rule). An agent can tell this is a read/query tool about grid earnings. It does not, however, differentiate itself from the sibling taifoon_grid_prices, which could plausibly be confused with a pricing/economics query.

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?

There is no statement of when to call this versus alternatives, nor any prerequisites or conditions. The closest thing to guidance is the mention that results depend on 'the live scarcity bonus' and the oracle, but there is no explicit when-to-use or when-not-to-use routing.

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 load and does well: it discloses provider ordering (attested, then capacity, then health), the 70/20/10 bonus split, that recording requires a key and mutates the rate, and that settlement is not deployed so a quote reserves nothing. Side effects and limitations are surfaced rather than hidden.

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 core purpose in the first sentence, then handles recording and settlement caveats. Information-dense but every clause carries substance; minor jargon (TSUL) is unexplained.

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 or annotations exist, so the description must cover behavior and it does: it explains the return payload (providers with endpoints, quote, id), the ledger side effect, and the non-settlement caveat. Only the alternative-tool selection 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 83%, so the schema already documents parameters. The description reinforces the hirer/api_key interaction (record vs quote-only), which is useful, but largely restates what the schema descriptions provide.

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 (hire) and resource (measured resources / providers of a kind) with what it returns: endpoints plus a quote. It is clearly distinguishable from adjacent hire_* tools in intent, though it never explicitly names a sibling to contrast against.

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 the key conditional: supplying hirer + api_key records the intent, omitting the key yields quote-only. However it offers no guidance on when to choose this over alternatives like taifoon_pool_quote or taifoon_hire_suggest, leaving the routing 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?

No annotations are provided, so the description must carry the behavioral burden, and it does add real substance: the platform probes the endpoint, verifies rpc chains via eth_chainId, treats submissions as claims vs probes as evidence, and returns a keccak challenge for kind=gpu. It still omits auth/permission requirements and whether registration is immediate or pending, so not exhaustive.

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 purpose and outcome, then the mechanism, then the kind=gpu special case and the endpoint. Four dense sentences with little waste, though the 'claim vs evidence' phrasing is slightly rhetorical rather than operational.

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 and no annotations, the description should cover more of the call lifecycle. It discloses the gpu return (keccak challenge) and the probe/verification behavior, but leaves unclear what an rpc join returns, whether the join is immediate, and what error/failure modes look like.

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 every parameter in detail; the description adds little parameter-level meaning beyond noting the gpu challenge flow. 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?

States a clear verb and resource ('Bring a resource to the Taifoon Grid') and the outcome (earn GRID points), with a concrete side effect (POSTs to /api/grid/join). It does not name the siblings it should be distinguished from (e.g. taifoon_register, taifoon_grid_bench), so it stops short of full sibling differentiation.

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?

There is implied usage: bring a resource here to join the grid and earn, with kind-specific behavior noted for rpc vs gpu. However it never states when to use this versus alternatives like taifoon_register or when not to call it, leaving the agent to infer routing.

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 full burden. It does useful work by disclosing that the value is live ('moves as providers join and hirers ask'), derived from an oracle rule over 24 h hire intents, and framed as a read. It stops short of stating read-only guarantees, caching/freshness semantics, or what consumers do with the returned rate.

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 on the payload and roughly three short sentences with no filler. The middle clause packs several concepts (supply bonus, demand, hire intents, oracle rule) densely, but nothing is wasted.

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 and no annotations, the description must carry the return semantics, and it does: resource kinds, per-kind live rates, the supply×demand derivation, and the 24 h window. It is complete enough for a zero-parameter read tool, with only freshness/precision details left unspecified.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter claims are made.

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 the resource (usable resources per kind: rpc, gpu, fpga, storage, ip) and the payload (the live rate each pays), so the agent knows this surfaces grid pool supply and pricing. It does not name a verb or distinguish itself from near-neighbours like taifoon_grid_prices, grid_economics, or grid_status, leaving the agent to infer the boundary.

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?

One implicit directive is given: 'Read before joining to earn most.' That is a usable trigger, but there is no when-not guidance and no named alternative among the many pricing/status siblings (grid_prices, pool_quote, grid_status). Usage is implied rather than explicit.

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 must carry the behavioral burden. It discloses the output row anatomy (each row names its source, live meter, and state) and the enumerated state vocabulary, which is genuinely useful. It never states that the board is a read-only snapshot, whether rates refresh, or any auth/rate-limit behavior, leaving real gaps for a pricing surface.

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?

It is front-loaded with the core purpose and stays to two sentences, but the first sentence is a dense jargon chain ('MMR twigs and proofs', 'x402 skills', 'n8n instances') that costs readability for an agent with no glossary. Nothing is wasted, yet nothing is easy to parse on first read.

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?

Two optional filters, no annotations, and no output schema, so the description is the sole source of return-value information — which it partly supplies via row anatomy and state meanings. It omits the peg/oracle mechanics (how the GRID rate is sourced) and freshness/authorization details an agent would want before relying on prices.

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 0%, so the description must compensate, and it largely does: 'Filter with group or state' names both parameters, spells out the state values (LIVE, QUOTE_ONLY, RANKED, BILLED_USD, DENOMINATED, PROPOSED), and the category list maps onto the group enum. Only the exact group tokens are left to the schema enums.

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 states a specific resource (a board pricing every Taifoon operation in GRID at the oracle's peg) and enumerates the covered categories (Grid kinds, chain RPC, MMR twigs, AI calls, hosting, bridge, x402 skills, coordination, agents), which lets an agent distinguish it from siblings like taifoon_grid_economics or taifoon_pool_quote. The verb is implicit ('priced'), but the scope is concrete 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 only usage instruction is 'Filter with group or state,' which explains parameters rather than when to choose this tool over taifoon_grid_economics, taifoon_offers, or taifoon_pool_quote. No conditions, prerequisites, or alternative-selection guidance are given.

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 does disclose that the data is 'read live' and that there is a 'next settler run (every 6 h)', which adds system context. However, it does not explicitly state that the operation is read-only and safe, nor does it cover authentication requirements, rate limits, or whether calling it has any side effects.

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, long, comma-heavy sentence with nested parenthetical lists. While information-dense, it is not front-loaded with a clear action verb and is harder to parse than necessary. It could be restructured with bullets or shorter sentences without losing content.

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 must convey what is returned. It lists many of the key output components—ledger, minted GRID, pending, balance, daily cap, next settler run, and network totals when no wallet is given. This is fairly complete for an agent to understand the return shape, though some terms (e.g., 'the rule') remain vague.

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 there is only one optional parameter. The schema itself says 'optional 0x wallet', but the description adds meaningful semantics by explaining what happens when the wallet is provided versus omitted ('Without a wallet: the network totals and the rule'). This goes beyond the schema and helps the agent decide whether to pass the parameter.

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 specifies the resource and scope: a wallet's settlement ledger on Taifoon mainnet, including minted GRID, pending amounts, balance, cap, and next settler run. It is clear this reads settlement/payout information rather than performing an action. However, it does not explicitly distinguish itself from siblings like taifoon_grid_status or taifoon_grid_economics, leaving some ambiguity.

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: call it to read live Grid settlement data. The description notes the conditional effect of the optional wallet parameter ('Without a wallet: the network totals and the rule'), which is a form of usage guidance. But there is no explicit when-to-use versus alternatives or when-not-to-use guidance relative to the many sibling grid tools.

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. It does disclose a valuable behavioral trait beyond the schema ('A collector earns 0 today — the twig-root verifier is designed, not built'), which correctly sets expectations about non-reward. It omits auth requirements, idempotency, rate limits, and whether output is live vs cached.

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 concept (how MMR splits into shards) before detailing parameters and the economic caveat, and every sentence adds information. It is dense and jargon-heavy 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?

With no output schema, the description does describe the return contents (your shard, a spinner config with best RPC per chain, the one command) and flags the zero-earning caveat. It is reasonably complete, missing only prerequisites/when-to-use framing for a read-planning 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 the schema already documents all three parameters. The description's notes on `me` and `collectors` largely restate the schema without adding syntax or format detail; `replication` is unexplained in the prose. 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 states a specific resource (shard assignment of MMR/superroot twigs across collectors) with a concrete mechanism ('balanced into shards, rendezvous-assigned to the swarm nodes'), distinguishing it from siblings like taifoon_superroot and taifoon_grid_pool. However, heavy jargon ('MMR', 'twig-root verifier', 'spinner config') obscures the exact output without prior context, keeping it 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?

It gives concrete usage for one path ('Pass `me` ... to get the shard YOU would take') and notes the `collectors` alternative for synthetic planning, implying when each applies. But it names no sibling alternative and no explicit when-not-to-use condition, leaving usage inferable rather than stated.

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 that this is a live GET (read-only, non-mutating), that the data reflects the current moment, and what categories of information come back. It does not mention auth requirements, rate limits, or caching, which keeps it short of a 5 for an unannotated tool.

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?

Two sentences, front-loaded with what the tool reports, then the ordering guidance, then the backing endpoint. Every clause adds distinct information and nothing repeats the title or 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?

With no output schema and no annotations, the description does the work of enumerating the return fields (open/closed, GRID points, reasons) and the resource kinds. That is enough for an agent to decide whether to call it. Missing only the raw response shape and any freshness/auth caveats.

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 takes zero parameters, which is the baseline-4 case. The description correctly implies no inputs are needed by describing a pure snapshot read, and there are no parameters whose meaning could be lost.

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 resource (the Taifoon Grid's acceptance/payout status) and enumerates the exact breakdown returned: per resource kind (rpc, gpu, tee, fpga) whether open, whether it earns GRID points, and why. It also names the concrete backend GET /api/grid/join, so the agent can tell it apart from sibling reads like taifoon_grid_economics or taifoon_grid_avenues.

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 sequences itself ahead of a named sibling: 'Read this before taifoon_grid_join.' That is a clear when-to-use instruction tied to a specific alternative. It stops short of stating when this tool is NOT the right choice or what other grid-status siblings cover.

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 burden and does well: it discloses that the broker only calls endpoints the agent published itself ('a URL you type is never called'), that dispatch:true delivers the offer, and it enumerates the return payload including the reply head, latency, and keccak digest. It omits auth/rate-limit caveats here (those live in the api_key schema field), so not fully self-contained.

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 delivery mechanism, and the workflow tail is useful. However, the first two sentences are extremely dense, with hyphenated jargon and stacked clauses that reduce scannability; the content is mostly earned but the prose could be tightened.

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?

Good coverage of return values despite no output schema, and the workflow chain fills a real gap. But for a 12-parameter mutation/hiring tool with 33% schema coverage and no annotations, several parameters and the funding/attach requirements remain under-specified.

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 33% across 12 params, so the description must compensate. It does map the protocol branches (MCP tools/call, A2A message/send, legacy tasks/send, n8n webhook) to the kind enum and explains dispatch:true, but leaves hirer, agent_id, chain_id, budget_usdc, required_skills, and args unexplained anywhere.

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: 'Open a brokered hire with a chosen agent,' and scopes it further with the dispatch:true behavior. It differentiates from siblings by naming the assurance_call follow-on. The dense proprietary jargon (ERC-8004 record, x402 wall) slightly muddies a clear core purpose.

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?

Provides an explicit workflow chain: 'Then: taifoon_assurance_call fund-job → attach the job → submit,' which tells the agent where this tool sits relative to alternatives. It does not state when NOT to use it or which sibling to prefer for other hiring flows (grid_hire, hire_assemble), 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?

With no annotations, the description carries full burden and does real work: it discloses that the calls are UNSIGNED, that nothing is signed or sent server-side, and that the api_key must match the one that opened the handshake. It omits response shape and any auth/rate-limit detail, but the key behavioral trait (a non-submitting, offer-constructing tool) is clearly surfaced.

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 action leads, then the signing caveat, then parameter detail. The em-dash clauses make it slightly run-on, but almost every phrase earns its place.

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 tool with no output schema and a nested body object, the description covers purpose, the unsigned/signing responsibility, and both parameters' meaning. An agent has enough to invoke it correctly; only the returned identifier/response is unaddressed.

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 0%, so the description must compensate, and it does: it documents that body is the /v1/jobs request body with an inline example of its fields (chainId, seller, price_usdc, class, handshake_id) and explains api_key's role. That is meaningful semantics well beyond the bare 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 and resource ('Create an offer for a chosen seller') and even maps it to the underlying endpoint (POST /v1/jobs). It is unambiguous what the tool does, though it never distinguishes itself from the crowded set of hire siblings (taifoon_hire_assemble, taifoon_hire_attach, taifoon_hire_suggest, etc.).

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 implies when this belongs in the flow ('nothing is signed or sent here', hirer signs later), giving an agent a sense of it being a preparation step. However, it names no alternative sibling and states no explicit when-to-use/when-not conditions, leaving usage 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: the deterministic-tier routing rule ('DET if an output schema is declared, insurable; else REF, graded never priced'), that the result is recorded as a shareable path, and that typesafe_key is forwarded but never stored. It stops short of describing side effects, permissions, or idempotency, but the routing and key-handling disclosure is substantive.

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 is front-loaded in the opening clause, which is good, but the middle is a single arrow-chained run-on packing many concepts into one unpunctuated sequence, making it hard to parse. It is information-dense without much waste, but the structure works against readability.

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 complex orchestration tool with no annotations and no output schema, the description explains the produced flow well but omits what the caller must supply beyond typesafe_key and what the recorded path looks like. The 0% parameter coverage leaves the calling contract under-specified.

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 0%, so the description must compensate for all five parameters, yet it only explains typesafe_key ('forwarded, never stored'). task, required_skills, api_key, and budget_usdc are named in the schema but carry no semantic guidance in either place, leaving half the parameters undocumented.

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 — 'assembles the whole path to hiring an agent for a task' — and enumerates the pipeline stages it produces (shortlist, verdict tier, Jev question, pins, evidence, prefilled next calls), which lets an agent distinguish it from read-only siblings like taifoon_hire_path. The heavy proprietary jargon ('Jev question', 'Rule-6 digest', 'verdict tier') dulls the edge, but the core purpose is unmistakable.

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 clear this is a first orchestration step that emits prefilled next calls (handshake, quote, attach, trace, verify), implying when to reach for it. However, it never compares itself against the numerous adjacent siblings (taifoon_hire_path, taifoon_hire_suggest, taifoon_grid_hire) or states a when-not condition, leaving the routing inference to the agent.

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 behavioral burden, and it does add valuable auth context (the api_key must match the one used at assembly time). However, it says nothing about whether re-attaching overwrites a prior jobId, idempotency, failure modes, or the effect on the lifecycle trace beyond the vague 'judge's guidance' phrasing.

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?

A single front-loaded sentence with the ownership constraint and rationale appended. It is dense and largely earns its place, though the trailing 'so the lifecycle trace carries the judge's guidance' is more flavor than actionable instruction.

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 4-parameter mutation tool with no annotations and no output schema, the definition covers the core purpose and auth requirement but omits any explanation of the 'id' parameter, the chain_id choices, and what happens after attachment. Adequate but with clear gaps an agent would need to guess at.

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 0%, so the description must document all four parameters. It clarifies job_id ('on-chain jobId') and api_key (owner-matched), but leaves 'id' completely unexplained and does not decode the chain_id enum values (8453/5042/36927). Roughly half the parameters lack meaning in either the schema or description.

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 states a specific verb (attach) and resource (on-chain jobId to an assembled hire path), and the phrase 'assembled hire path' implicitly distinguishes it from the sibling taifoon_hire_assemble that produces that path. An agent can identify the operation 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?

It gives a clear precondition ('owner only: the same api_key that assembled it'), which tells the agent when the call will succeed. It does not name alternative tools or state when not to use this one, 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?

With no annotations, the description carries the full burden, and it does disclose real behavior: which events are traced, that every transaction gets a /v1/proof/tx verify link, and that prove:true changes behavior by proving each state live under the superroot. It still omits safety posture (read-only?), cost/latency implications of prove:true, and any auth requirement, so it is helpful but incomplete.

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 is front-loaded and the two sentences are not padded, but the second half is a dense run of domain jargon (observatory's decode, the layer's records, whitepaper's closed-lifecycle table) that costs parseability without adding routing signal. Not wasteful, but not clean.

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 and no annotations, so the description must carry both; it does describe the return surface (state table, events, proof links), which partially substitutes for an output schema. For a 4-parameter tool it still leaves job_id/chain_id semantics and any safety or cost guidance unstated.

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 25% — only tenant is documented in the schema. The description does add real meaning to prove ("prove:true proves each live under the superroot"), which the bare boolean schema does not convey. However, job_id (the required parameter) and chain_id receive no explanation in either place, leaving half-plus of the semantics undocumented.

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 opening clause names a specific resource and scope — the complete lifecycle of a job, traced and verifiable — which is more than a restatement of the name. It enumerates what is folded in (hook state, on-chain events, observatory decode, layer records, lifecycle table), so an agent knows this is a consolidated trace. It never names or contrasts a sibling such as taifoon_hire_path or taifoon_hiring_stages, so 5 is not warranted.

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?

There is no statement of when to call this versus the many sibling lifecycle tools (taifoon_hiring_stages, taifoon_hire_path, taifoon_hire_assemble). No prerequisites, no when-not-to-use, no named alternative. Usage must be inferred purely from the resource description.

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 behavioral burden and does so well: it discloses the returned content (choices with basis, Jev's pick, distribution, confidence, bar clearance at 0.8 default), the cost behavior of dry:true ('without spending a call'), and batch's ready_jobs calibration criteria (Wilson interval, n ≥ 5, width ≤ 0.35). It stops short of stating whether the call mutates state or what auth/rate-limit constraints apply.

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 is front-loaded and the text is compact, but the high jargon density and colon-heavy run-on sentences make it hard to parse, so not every clause cleanly earns its place for a first-time reader. It is dense rather than wasteful.

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 output schema, no annotations, and 10% schema coverage, the description is thin on how the phases relate and what the majority of inputs (task, seller, skills, api_key, chain_id) accomplish. It covers return content and cost but leaves too many required pieces to inference.

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 10% (just price), so the description must compensate and partially does: it explains phase values, bar (0.8 default), dry behavior, and typesafe_key. Six of ten parameters (task, price, seller, skills, api_key, chain_id) remain undocumented in both schema and description, leaving a real gap.

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 states the mechanism (presenting every field of a coordination phase as a typed multiple-choice question over live data, answered in one battery) and lists the phases matching the enum. However, private jargon ('Jev pad', 'calibrated battery', 'Jev fills in the numbers') obscures what the tool concretely does, and it does not distinguish itself from siblings like taifoon_hire_suggest or taifoon_hire_assemble.

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?

There is one implicitly useful usage hint ('dry:true returns the choices without spending a call'), but no explicit when-to-use guidance or comparison against the many hire_* siblings. An agent cannot tell from the text when to reach for this pad instead of taifoon_hire_suggest, taifoon_hire_path, or taifoon_hire_assemble.

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 it does disclose the return payload (task, shortlist, tier, judge pins, verdict + distribution, Rule-6 digest, next steps, data_as_of). However it never states that this is a pure read, whether it can fail when the path is unassembled, or any permission requirements, leaving notable gaps for an unannotated tool.

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?

A single front-loaded sentence with the verb and resource leading and the return fields compactly listed after a colon. Dense and waste-free, though the field list borders on an output contract.

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 steps in by enumerating the returned fields, which is exactly what an agent needs to know what comes back. The remaining omission is the read-only/permission profile that annotations would normally supply.

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 0% and the schema gives only a bare string, but the description adds the meaningful 'hp_…' id-prefix format hint. That partially compensates for the schema gap, though no failure behavior or sourcing of the id is described.

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 verb (Read) and resource (an assembled hire path by id), and enumerates the returned contents, which lets an agent distinguish it from assembler/lifecycle siblings like taifoon_hire_assemble. It stops short of explicitly contrasting with those siblings, so it lands at 4 rather than 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 only implied: calling it 'assembled' hints the path must first be created via a sibling like hire_assemble, but the description never states when to reach for this versus the alternatives or what preconditions exist. No explicit when/when-not guidance is present.

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 full burden. It does disclose useful behavior beyond the schema: data is LIVE, every field carries data_as_of, and jev:true with typesafe_key adds exactly ONE calibrated ranking. It does not, however, state whether the call is read-only, whether it needs auth, or how many suggestions are returned.

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?

Two dense sentences, front-loaded with what gets suggested, and no filler. The density of internal jargon ('harvester vocabulary', 'TypeSafe/Jev ranking') makes it slightly hard to parse but the structure is tight.

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 six-parameter tool with no output schema and no annotations, the description omits too much: how task is used, what api_key/chain_id do, whether this is read-only, and what the response looks like. It covers data provenance well but leaves the call contract substantially under-specified.

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 only 17% (six parameters, essentially undocumented), so the description must compensate and it largely does not. It explains the jev + typesafe_key interaction and hints that seller supplies terms, but api_key, chain_id, and the required task parameter get no meaning at all.

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 states a specific verb+resource: auto-suggest the inputs of a hire from LIVE data, enumerating what is suggested (skills, budget, terms). However, it does not distinguish this tool from close siblings such as taifoon_hire_assemble or taifoon_hire_pad, which an agent would plausibly confuse it with.

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 describes where the suggested data comes from but gives no when-to-use condition, no prerequisite, and no mention of alternative tools (hire_assemble, match, pool_quote) that also serve hiring setup. The only conditional guidance is the jev/typesafe_key pairing, which is about a sub-feature rather than tool selection.

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 at all, the description carries the full burden, and it does disclose what each stage record contains (who acts, ERC-8183 events, performing operations, Jev's role), which is meaningful content disclosure. But it never states the operation's safety profile — nothing confirms it is a side-effect-free read or that it never mutates hire state — leaving the behavioral profile only implied by 'Read this first.'

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?

It is a single front-loaded sentence listing the pipeline plus one short directive sentence — no filler or repetition. The pipeline enumeration is dense with domain jargon (ERC-8183, Jev, Moonbeam Protocol) but each item is informative rather than redundant, so it is appropriately sized overall.

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, zero-required reference tool with no output schema, the description covers the essential questions: what the stages are, what each entry holds, and that it should be consulted before choosing a stage-specific tool. Nothing needed to invoke it correctly (only an optional stage id, documented in the schema) 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 description coverage is 100% and the single `stage` parameter is fully documented there ('one stage id, or omit for all'), so the baseline is 3. The description adds no semantics about the stage parameter itself — it never says a stage id can narrow the output or what the valid stage ids are, so it does not compensate 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 names the exact resource (the hire lifecycle stages) and enumerates them concretely (listing → intent → bid → ... → price), so an agent knows this is the stage-map/overview tool rather than one of the many taifoon_hire_* action tools. It also states what each stage entry contains (actors, ERC-8183 events, operations, what Jev is asked), making the deliverable explicit. It is clear but its domain-heavy framing means an agent still has to infer that this is purely an orientation/reference listing.

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 final sentence gives an explicit usage directive: 'Read this first to know which tool belongs to which stage,' which positions it as the entry point ahead of the per-stage tools. That is strong when-to-use guidance. However, it offers no exclusions or pointers to specific alternatives once the agent already knows the stage, so it falls short of the 5 benchmark.

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 disclose meaningful behavior: a hard fail terminates the flow, 'answers' is refused on a hard fail, a changed digest, or a malformed answer, auto-completion is capped at 50 USDC, and results are recorded against the caller credential. These are real behavioral traits beyond the schema, though the mode 'single' path and permissions model remain opaque.

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 content is delivered as a single dense run-on sentence with nested parentheticals and no headings or ordering, making it hard to parse and poorly front-loaded. Information density is high but structure and readability are weak, which is a hinderance rather than conciseness.

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 15-parameter, multi-mode tool with no annotations and no output schema, the description covers the overall workflow and refusal behavior reasonably well. Yet key gaps remain (mode 'single', several numeric/credential parameters, undefined internal jargon), so an agent cannot call every path correctly from the description alone.

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 only 13% across 15 parameters, so the description must compensate. It does explain the accepted subject forms (handshake_id, several job_id formats with chain_id, Olas Mech request id, or raw state) and details the 'answers' payload (value, confidence, probabilities) plus model, answered_by, prepare_digest and api_key. However, it leaves price_usdc, execution_id, typesafe_key, chain_id details, record and mode 'single' unexplained, so compensation is only partial.

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 tool clearly involves grading/verdict composition ('grade a subject... code composes the verdict') and returning a receipt plus an anchored decision, which is a recognizable verb+resource. However, the purpose is buried under heavy private jargon ('RUBRIC_v1', 'Jev 1.13', 'TypeSafe node schema', 'assurance-hook job') that an outside agent cannot decode. It also never names or contrasts itself with the sibling judge tools (taifoon_judge_decisions, taifoon_judge_ref).

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 lays out a two-step workflow (mode 'prepare' then mode 'answers') and states prerequisites like using your own TypeSafe credential with no free grade. But the third enum value, mode 'single', is never explained, so the agent cannot choose between all three modes, and no sibling alternative is mentioned.

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 behavioral burden. It usefully discloses ordering ('newest first'), the presence of recomputable digests, and that the log is 'immutable, append-only', which tells the agent the underlying data is read-only. However it says nothing about pagination behavior, the meaning of the limit cap, or auth requirements.

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 core purpose is front-loaded in a single dense sentence, which is good, but the parenthetical kind lists and the opaque 'ask for the genome frames' clause add length without proportional clarity. Some trimming would improve the ratio of signal to words.

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 filtered-list tool with no output schema, no annotations, and three parameters at 33% coverage, the description covers what the tool returns and its ordering but leaves return shape, pagination, and the limit/id interaction unspecified. Adequate as a minimum-viable definition, but not complete.

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 33% — only `id` is documented. The description adds the intent behind `kind` ('Filter by kind') and hints at a mode to 'ask for the genome frames', but leaves the `limit` parameter unexplained and does not clarify whether `id` and `kind` are mutually exclusive. It partially compensates for the coverage gap but not fully.

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 states a concrete verb and resource — retrieving every decision the judge made for a layer — and enumerates the decision kinds (pad picks, skill rankings, assembles, grades, study batteries), so an agent knows exactly what data comes back. It stops short of differentiating itself from close siblings like taifoon_judge_compose or taifoon_judge_ref, which it must be distinguished from.

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 offers partial direction ('Filter by kind') which implies how to narrow results, but gives no explicit when-to-use guidance, no exclusions, and does not name which sibling to pick instead for composing or referencing a decision. The trailing 'ask for the genome frames' is too cryptic to function as usable 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?

With no annotations, the description carries the full behavioral burden: it discloses the two execution modes and what each returns (value, probabilities, confidence, lifecycle ending vs. facts, composed verdict, receipt, anchored record) and warns that keyless mode ignores custom questions. It does not cover credential expectations for api_key, error behavior, or cost/limits, leaving meaningful 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 two-mode contrast is front-loaded, which is good structure, but the sentences are dense with unexplained jargon and the trailing 'A REF answer never produces a cheat' adds confusion rather than usable guidance. Some phrasing earns its place; some does not.

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 and no annotations exist, so the description must explain both behavior and returns; it partially does so by enumerating the outputs of each mode. However, with 5 parameters at 20% coverage, undocumented params (api_key, options) and the mode/key relationship leave an agent unable to invoke it confidently.

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 20%, and 4 of 5 parameters are undocumented in the schema. The description touches typesafe_key (gates mode) and question (only asked in keyed mode), but api_key and options are never mentioned, and the relationship between api_key and typesafe_key is left ambiguous, so it does not adequately compensate for the coverage gap.

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 states a specific action (ask a question about an item / grade an item) and explicitly branches on whether a typesafe_key is present, naming the taifoon_judge_compose pipeline it maps to. This lets an agent tell the keyed and keyless modes apart, though the jargon ('calibrated answer', 'lifecycle ending', 'cheat') is opaque and the core resource noun ('item') stays abstract.

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 an explicit conditional: with your own typesafe_key you ask a custom question, without one you get the Taifoon grade and 'a custom question is not asked.' That routes the primary decision cleanly. It stops short of comparing against the many sibling judge/agent tools, so no explicit alternatives are named beyond the compose reference.

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 it partially delivers by enumerating the returned content (totals, positions, per-ecosystem tags). But it does not disclose behavioral traits such as read-only nature, data freshness/snapshot timing, cost, or rate limits, and references to 'the harvester' are unexplained.

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 content is front-loaded with the core figure described first, but the main sentence is a dense run-on that stacks specialized terms (harvester, handshake-ready, TEE claims, work surfaces) without definition. It is information-dense but not wasteful; readability suffers slightly.

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 must convey what is returned, and it does list chains with agents and counts, work surfaces, TEE claims, unscanned chains with reasons, totals, positions, and per-ecosystem tags. This is reasonably complete for a read-only overview surface, though freshness and format specifics are absent.

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 takes zero parameters, so there is nothing for the description to disambiguate, and the empty schema with additionalProperties=false is self-consistent. Baseline for a zero-parameter tool is a 4.

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 states a clear resource and scope: a single-figure overview of every agent ecosystem the harvester has read, including per-chain agents, handshake-ready counts, work surfaces, TEE claims, and unscanned chains. It does not name a crisp verb, but the 'landscape' framing and content list make its purpose unambiguous. It lightly distinguishes itself by positioning against hire/register, though it does not directly name sibling tools.

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 some context: 'Read this to know where agents are before you hire or register,' which implies a discovery/pre-flight use. However it offers no explicit exclusions, no pointing to a specific alternative tool, and no conditions under which you should skip it.

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 supplied, so the description carries the full behavioral burden. It usefully discloses ordering (newest first), the default page size (20), and the accepted state values, which tells the agent the result is a bounded, presorted read. It stops short of describing auth needs, pagination beyond the limit, or what the response contains.

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?

A single compact sentence with the resource and ordering front-loaded, followed by the filters. The closing clause 'Also lists the classes a demand may name' is weakly connected to any parameter and costs clarity for little gain, but overall there is no padding.

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 two-parameter, no-output-schema listing tool, the description covers filtering, ordering, and page sizing, which is most of what is needed. It omits any mention of pagination/continuation behavior and the shape of returned demand records, and the 'classes' sentence hints at output content without explaining it.

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 0%, so the description has to compensate, and it does: it enumerates the valid state values and supplies the limit range (1–200) and default (20), the last of which the schema does not state. This is largely a restatement of the enum and bounds, but for an undocumented schema it meaningfully fills the gap.

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 the resource (demands) with the endpoint GET /v1/demands and the ordering (newest first), which is enough for an agent to recognize it as a list operation distinct from taifoon_post_demand or taifoon_demand_status. It never explicitly names those siblings, so differentiation is implied rather than stated. The trailing clause about 'classes a demand may name' muddies the scope slightly.

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?

Filtering by state and capping with limit implies 'use this to browse/filter demands', but there is no explicit when-to-use or when-not-to-use guidance and no pointer to alternative tools. The agent has to infer that this is the broad-listing tool and taifoon_demand_status is the single-record one. Minimum viable.

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 disclose non-obvious behavior: results are spam/Sybil/scam-filtered, ranked by trust, carry assurance terms, and include ineligible candidates with the reason. It omits whether the call is read-only, any cost/permission implications, and pagination, but the filtering/ranking semantics are valuable context beyond the tool name.

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?

It is a single front-loaded sentence with no filler, but the nested parentheticals ('the vetted CRM shortlist (spam/Sybil/scam-filtered, ranked by trust, with assurance terms)') make it dense and slightly hard to parse. No wasted words, yet readability suffers.

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 does a fair job sketching the return shape (shortlist plus broader pool plus ineligible-with-reason), which is its strongest contribution. However, it leaves two input parameters unexplained and says nothing about side effects or permissions, so it is not fully sufficient for a 3-parameter, annotation-free 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 0% across 3 parameters, so the description must compensate but only covers 'required_skills' implicitly. It says nothing about what 'task' or 'budget_usdc' mean or how budget affects ranking, leaving two of three parameters undocumented in both schema and description.

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 states a specific verb ('Rank agents') and resource ('for a set of required skills'), which is clear enough to distinguish it from most of the taifoon_* siblings at a glance. It does not explicitly name an alternative like taifoon_hire_suggest or taifoon_pool_quote, but the action itself is 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?

There is no when-to-use or when-not-to-use guidance, nor any named alternative among the many sibling matching/pool tools. Usage is only loosely implied by the phrase 'for a set of required skills', leaving the agent to infer when this beats taifoon_hire_suggest or taifoon_grid_pool.

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 behavioral burden. It does disclose the shape of the returned data (metrics per chain, ours vs customers, on-chain vs off-chain), which partially substitutes for the missing output schema. But it says nothing about auth requirements, rate limits, freshness, or 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?

Front-loaded with the core purpose, then the metric list, then the alternative mode. Two sentences with no filler, though the metric enumeration is dense and could be trimmed.

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 metrics tool with no output schema and no annotations, it is adequate: the metric list and mode description together tell an agent what to expect. Missing pieces are default behavior for 'day', authenticity of the endpoint, and any environmental context, leaving it just at the minimum viable level.

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 50% (day is documented, series is not). The description compensates by explaining that 'series:N gives N days of headlines instead', clarifying both the meaning of N and that it switches the tool's mode. The 'day' parameter adds nothing beyond its schema description, so it isn't fully comprehensive, but it covers the undocumented parameter well.

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 clear verb+resource ('How much went through the coordination layer') and enumerates the specific metrics returned (calls per route/key class, handshakes, gateway λ steps, hires, grades, bridges, fees) plus the breakdown dimensions. It also names the underlying endpoint and the series variant. However, it does not differentiate itself from siblings like taifoon_network, taifoon_landscape, or taifoon_grid_status, which an agent must distinguish on its own.

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 implicitly routes between two modes: default per-route/key-class breakdown vs. 'series:N gives N days of headlines instead'. That is useful mode selection, but it offers no when-to-use guidance relative to the many sibling metrics/status tools, and no prerequisites or 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?

No annotations are provided, so the description carries the full burden. It does disclose two behavioral facts: the operation is a read (GET /v1/network) and it returns no customer data, which is useful privacy/scope context. It says nothing about freshness guarantees beyond the word 'live', rate limits, auth requirements, or response size.

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?

One dense sentence with the endpoint stamped up front and the payload sections enumerated in priority order; no filler. It is slightly list-heavy and would read better front-loaded with a one-line 'what this is' before the inventory, but nothing is wasted.

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 and no annotations, the description must describe the return payload itself, and it does enumerate the four sections an agent will receive (sellers/online, grid health, routes/quotes, gateway steps). What is missing is how to interpret or act on those sections and how this differs from sibling overview tools.

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 takes zero parameters, so there is nothing for the description to disambiguate; schema coverage is 100% and the baseline for a parameterless tool is 4. The description instead spends its words on payload content, which is the right allocation.

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 gives a concrete inventory of what the tool returns: sellers online per job class with latency, grid RPC rotation health per chain, cross-chain routes with a live quote, and gateway step counts. That is far more specific than the name 'taifoon_network' alone. However, it never distinguishes itself from near-neighbors like taifoon_landscape, taifoon_metrics, or taifoon_grid_status, so an agent cannot tell from the text alone which overview tool to pick.

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?

There is no statement of when to call this versus alternatives, nor any prerequisites or exclusions. With 44 sibling tools including several other status/overview endpoints (landscape, metrics, grid_status, grid_avenues), the absence of routing guidance is a real gap.

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 burden and does well: it explicitly discloses that nothing is executed as a side effect, that the return is the command plus a meaning for each env var, and that the operator must run it. It omits auth/wallet requirements and any rate or idempotency notes.

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?

Three short sentences, no filler, and the core purpose is front-loaded ahead of the non-execution caveat and the return description.

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 command-generator with no output schema, the description covers what the tool returns and that it has no runtime effect, which is what an agent needs. It could add guidance on choosing kind or on sibling tools, but nothing essential 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 owner, kind and ref are already documented in the schema, and the enum values are enumerated there. The description only restates the wallet and resource-kind mapping to owner/kind and omits ref entirely, so it adds little beyond the baseline.

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 concrete output (a docker command that joins a box to the Grid) parameterized by wallet and resource kind. The agent knows exactly what it gets back. It does not, however, distinguish itself from the close sibling taifoon_grid_join, leaving some ambiguity about which 'join' tool applies.

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?

'Nothing runs from this tool; the operator runs it on their box' implicitly tells the agent this is a generation-only tool and not an executor, which is useful. But there is no explicit when-to-use vs taifoon_grid_join or any other sibling, and no prerequisites stated.

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 must carry the full behavioral burden. It usefully discloses return contents (status, protocol, reply head, digest, poll URL) and ordering (newest first), but does not address read-only safety, auth needs, rate limits, or pagination behavior.

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 definition is two dense sentences with the core purpose and return shape front-loaded, followed by the orientation variant. The jargon is heavy ("reply head," "digest") but 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?

There are no annotations and no output schema, so the description should be self-contained. It covers purpose, return fields, and orientation adequately for basic use, but missing limit/state semantics and any safety or pagination context leave it only minimally complete for a 4-parameter 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 0% for four parameters. The description clarifies the hirer/provider orientation for buyer outbox versus seller inbox, but it says nothing about limit or state, leaving half the parameters undocumented in both schema and description.

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 states a specific resource and scope: "seller agent’s inbox: the handshakes (offers) addressed to an address, newest first." The second sentence distinguishes the buyer-outbox variant via hirer vs provider, but no sibling tool is named, so differentiation is only partial.

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 provides one usage variant: "Pass hirer instead of provider for a buyer’s outbox." However, it does not say when to choose this tool over alternatives, nor does it give exclusions, prerequisites, or broader context beyond the implied inbox use case.

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 behavioral burden, and it does add real value: flows come from "the delivery loop", have a "TTL 7 days", and are "stamped data_as_of" — useful freshness/expiry context. However, it never states that this is a read-only listing, whether results are paginated or ordered, or what defaults apply, which is a meaningful gap for an unannotated tool.

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?

Two dense sentences with no filler; the itemized list of returned fields earns its length because there is no output schema. Front-loading the resource definition before the filter/fetch instructions is sensible, though the jargon ("harvest", "delivery loop") adds reading cost.

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 enumeration of return contents substitutes for the missing output schema, and the TTL/data_as_of note covers freshness. Still missing for a 4-parameter, unannotated tool: read-vs-write nature, pagination/limit behavior, default ordering, and filter-combination rules.

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 only 25% (only `id`), so the description must compensate, and it partially does by explaining skill/source filtering and id-based fetch. It leaves `limit` completely unexplained and doesn't clarify whether filters can be combined with `id` or what the enum source values mean.

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 concrete resource ("ready-to-run hire flows") and enumerates what each flow contains (task, skills, budget, candidate, prefilled calls, console URL), so an agent knows exactly what comes back. The action is only implied ("filter...fetch one by id"), and it never distinguishes itself from the many hiring siblings such as taifoon_hiring_stages or taifoon_hire_suggest, which is why it doesn't reach 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?

"Filter by skill or source; fetch one by id" is operational parameter guidance, not when-to-use guidance. There is no statement of when this tool is appropriate versus the sibling onboarding/hire tools, no prerequisites, 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?

With no annotations, the description carries the full burden and does so well: it discloses that the returned tx is UNSIGNED, that it is simulated via eth_call + eth_estimateGas, that creating a pool is permissionless and deposits nothing (gas only), and that Moonbeam pools return closed_by_policy. These are exactly the behavioral traits an agent cannot infer from the schema.

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 verb, endpoint and return shape come first, then simulation, permissions, and the follow-on call. Every clause carries information, though the run-on structure could be broken for 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?

No output schema exists, yet the description explicitly enumerates the return payload { to, data, value, chainId } plus gas, fee and resulting pool address, and covers the state-exists and closed_by_policy branches. Complete enough for an agent to call and handle 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?

Schema coverage is 75% and already documents from/default, line defaults, asset default, seller formats and chain IDs. The description adds genuinely new semantics: the mainnet pool-rule requirement and the override: true escape hatch, tying a parameter to a conditional behavior.

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+resource ('Open a coverage pool behind a seller') plus the exact endpoint (POST /v1/pools/open) and the returned artifact, which cleanly distinguishes it from siblings like taifoon_pool_status and taifoon_pool_quote.

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?

Explains the follow-through workflow explicitly — sign and send with your own wallet, then call taifoon_pool_status with the tx hash — and notes the mainnet pool-rule/override condition. It does not contrast against taifoon_pool_quote, but the context for when to reach for this tool 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, the description carries the full burden, and it does add real behavioral content: the pool-selection ladder (seller pool, class pool with per-worker cap, protocol vault, else none), that the buyer never picks, and a why[] for refusals/downgrades. It says nothing about idempotency, auth/permissions, or error behavior for the call itself, so it stops short of full disclosure.

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?

One enormous run-on sentence packed with nested parentheticals overloads the reader; the front-loaded purpose is buried under the return-field enumeration. It is dense rather than concise, and structure does not help an agent parse quickly.

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?

Because there is no output schema, enumerating the returned terms (pool, pool_free, auto_complete_eligible, record, rails, why[]) is genuinely useful completeness. However, input semantics for a 6-parameter tool are largely missing, and the two aspects roughly balance out to a minimum-viable 3.

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 17% and the description clarifies just two things: price is in smallest units of the settlement token and tenant 'moonbeam' quotes against GLMR pools on Base. seller, class, price_usdc, and chain_id are left undocumented, so the description fails to compensate for the coverage gap.

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 opening ('the terms one job would settle on for a seller at a price') does convey a quote/settlement-terms computation, but the label 'The matcher' is jargon and overlaps heavily with siblings like taifoon_match and taifoon_offers without saying how this differs. An agent can guess the purpose but is not given a crisp verb+resource statement.

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?

There is no explicit when-to-use, when-not-to, or alternative-tool routing despite many plausibly overlapping siblings (taifoon_match, taifoon_offers, taifoon_grid_pool). The only implied usage is that it is a pre-settlement quote for a seller.

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 burden itself and largely does: it implies a safe read (GET /v1/pools/networks), declares the enumerable result categories, and proactively discloses policy-driven states ('Moonbeam ... closed by policy; every other chain as not supported yet'), which is behavior an agent cannot infer elsewhere. It omits auth requirements, caching/rate limits, and pagination, but adds genuine context beyond structured fields.

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?

Three sentences, front-loaded with the endpoint and purpose, then the result contents, then the policy edge cases, then the next-step handoff. No sentence is redundant and nothing is buried.

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 has to describe the return: it names factory, hook, pool assets and live status, plus the closed/not-supported policy states. Combined with the explicit downstream tool, an agent has everything needed to call it and act on 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 tool takes zero parameters, which is the baseline-4 case; there is nothing for the schema to document and nothing the description could add. The description correctly spends no words on parameters.

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 verb+resource ('where a coverage pool can be opened') and pins the concrete response shape (every supported chain and line, with factory, hook, pool assets and live status), going so far as to cite the underlying endpoint GET /v1/pools/networks. It is clearly separable from sibling pool tools (pool_quote, pool_status, pool_open_plan) because it is framed as the inventory entry point.

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 an explicit ordering directive ('Start here, then taifoon_pool_open_plan'), which is exactly the routing an agent needs for a discovery tool. It stops short of naming the alternatives to avoid (e.g. when to skip this and call taifoon_pool_status or taifoon_pool_quote), so it is clear context rather than a full when/when-not matrix.

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 a fair job: it discloses the four outcome states, the verification chain (PoolCreated log, factory poolOf, listing in GET /v1/pools), and that 'pending carries retry_after_seconds', which tells the agent it may need to poll. It omits auth requirements and whether results are cached/eventually consistent.

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?

It is a single dense, run-on sentence with inline URL templates and parentheticals that interrupt the flow. The trigger is front-loaded well, but the structure is crowded and would be clearer split into usage and return-value sentences.

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 5-parameter, no-output-schema tool, the description covers outcomes and lookup modes but leaves the required chain_id and the 'line' enum undocumented, and does not say how to interpret a 'pending' final state (timeout/backoff). It is adequate but has clear gaps.

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% (chain_id, line, asset have no descriptions), but the description compensates by clarifying the mutually exclusive lookup modes — tx_hash versus seller+asset — which the schema alone does not express. It still leaves 'line' (layer/v4/v4-glmr) and chain_id semantics 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 states a specific resource (pool status after createPool) and enumerates the possible outcomes (pending | created | reverted | no_pool), so an agent knows exactly what this returns. It is clearly distinguishable from siblings like taifoon_pool_open_plan and taifoon_pool_quote, though it does not name them 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 an explicit trigger ('After you broadcast createPool') and names both invocation modes (by tx via /v1/pools/open/{chain}/{tx}, or by seller and asset). This is clear contextual guidance, though it never states when *not* to use it or which mode to prefer in ambiguous cases.

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 so richly: deterministic (no model) word-to-class mapping, the no_class|ambiguous|incomplete result codes with what each needs, dry_run keeping nothing, the auto-match loop timing, code-based grading, and settlement on devnet 36927 with test dUSDC described as 'nothing of value'. This is unusually candid about side effects and safety.

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?

Information-dense but written as a single sprawling run-on with stacked parentheticals and embedded examples, so the core 'post a need' action is not cleanly front-loaded. Most content is useful, but readability and scannability suffer.

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 an 8-parameter tool with no output schema, the description covers the post-and-settle lifecycle, error-code recovery path, dry-run semantics, and the natural follow-up tool. Only minor gaps remain, such as what a successful response contains.

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 all 8 parameters. The description adds marginal value by illustrating 'need' formats and clarifying dry_run's keep-nothing behavior and the catalog_id/price_units relationship, so it sits at the baseline rather than below 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?

States a specific verb and resource ('Post what you need... POST /v1/demands') and the outcome (the layer hires for you). The mapping between plain words and job class is explained, but differentiation from siblings like taifoon_hire or taifoon_match is only implicit through the follow-up reference to taifoon_demand_status.

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 through worked examples ('the keccak256 hash of "hello world"'), the class+input alternative, and dry_run, with a pointer to taifoon_demand_status for follow-up. However it never states when NOT to use this versus the many hire/match siblings, so a caller must infer 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 provided, the description carries the full behavioral burden and does so well: it names the structured return fields, the portable V5 proof blob location, the six-layer structure, finality typing, off-chain carriage, and the retryable error shape with retry_after_seconds. It still omits permission requirements and rate limits, so it is not fully exhaustive.

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 front-loads the core purpose and return shape, then covers blob portability and retry behavior. Some clauses are packed into a single sentence, but every statement carries relevant 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?

Given an output schema exists, the description need not explain return values, yet it usefully surfaces the structuredContent, blob, and retryable error behavior. It is largely complete for a complex proof-verification call, though it could mention auth or rate-limit constraints.

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 chain_id and block_number are already documented in the input schema. The description adds no syntax, format, or edge-case meaning beyond what the schema provides, making the baseline 3 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 states a specific verb and resource: 'Verify a block under the SuperRoot' and names the proof class 'proof.verify.v5'. It does not explicitly distinguish itself from sibling tools such as taifoon_proof_tx or taifoon_superroot, so it misses full sibling differentiation.

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 clear context for when the tool is used (verifying a block proof) and adds retry guidance for blocks still being built. However, it never names alternative tools or states when not to use this one versus taifoon_proof_tx or taifoon_superroot.

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 behavioral burden. The GET-style path and the enumerated return fields (block, superroot, is_finalized, verified checks) do tell the agent this is a read/verification operation and what it yields, which is genuinely useful. However, it says nothing about which chains resolve, why verification might fail, or what a negative proof looks like, leaving notable 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?

A single front-loaded sentence that leads with the verb and resource and closes with the returned data, with no filler. The parenthetical endpoint adds concrete context cheaply. Slightly dense but no sentence is wasted.

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 and no annotations, the description usefully enumerates the returned fields, covering part of the transparency burden. But it leaves tx_hash format undocumented and gives no routing context against the many sibling proof/finality tools, so an agent has enough to attempt a call but not to choose confidently.

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 50%: chain_id is well documented in the schema (valid chain list, 404 chain_not_read behavior) but tx_hash has no description anywhere. The description's path template '{chain}/{tx}' merely restates the parameter names and adds no format detail such as a 0x-prefixed hash, so it does not compensate for the coverage gap.

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 states a specific verb and resource — proving that one transaction is committed inside the Taifoon superroot — and even names the concrete endpoint path. It lists the returned fields (block, superroot, is_finalized, verified checks), so the agent knows exactly what comes back. It does not explicitly differentiate from siblings like taifoon_proof, taifoon_superroot, or taifoon_finality_explain, which keeps it at a 4.

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?

There is no guidance on when to use this tool versus taifoon_proof, taifoon_superroot, or taifoon_finality_explain, and no prerequisites or exclusions are stated. The singular 'one transaction' hints at scope but is never framed as a selection criterion. Usage is only implicitly inferable from the verb.

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 delivers: the key is shown once (non-recoverable), nothing is signed or paid, what the response contains (api_key, tenant.id, keys live/sandbox, cockpit_url, next_steps), the auth header to use (X-API-Key), and the counter behavior versus the per-IP visitor budget.

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 'START HERE' and dense with actionable content, but it crams conditional instructions, a literal example payload, and raw endpoint paths into one paragraph. Every sentence earns something, though the structure is closer to a wall of text than a clean brief.

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 still fully equips the agent: return fields, endpoint, header convention, rate-limit context, and next steps are all covered. Nothing needed to call 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% and both params are optional, so baseline is 3; the description adds genuine meaning by clarifying both are mere labels, that no arguments are needed, and that wallet_address involves no signing. It goes slightly beyond the schema descriptions rather than merely restating them.

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+resource+outcome: 'Get a free Taifoon key in one call' and explains it onboards a TENANT via POST /v1/register. An agent can immediately distinguish this from siblings like taifoon_tenant (read-only) or taifoon_agents_register 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 unusually explicit routing: 'START HERE', names the immediate follow-up (taifoon_post_demand), the reader for your own numbers (taifoon_tenant), and states this is where a 429 rate-limit points. It does not, however, distinguish itself from the similarly named sibling taifoon_agents_register or state a 'don't call if you already have a key' exclusion.

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 burden and does well: 'Nothing is signed or sent' clearly marks this as a non-destructive dry-run/plan step, and it discloses the fee model (1% fee, min 0.01) and devnet program id. It stops short of describing return format or prerequisites for the fee payment.

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 core purpose and the 'unsigned / nothing sent' constraint are front-loaded, and the sentence count is small. Slightly dense with parenthetical fee and devnet asides, but every clause 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?

For a plan-generation tool with no output schema and an opaque nested body at 0% coverage, the description explains the outcome and safety profile but leaves the request body's required fields undocumented. Adequate but incomplete on the input contract.

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?

One parameter, a nested object, at 0% schema description coverage. The description only says 'body is the /v1/settle request body,' which names the endpoint but gives no field-level structure for a nested object whose keys the agent must construct. This is a real gap, not merely a repetition of 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+resource: produces the unsigned settlement plan of one paid call via POST /v1/settle, and enumerates the plan's contents (job id, terms, calls[] with signers). It's clearly distinct from generic settlement siblings, though it doesn't name a specific alternative tool.

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 explicit when-to-use or when-not guidance, and no sibling alternatives named. The phrase 'via:"us" names our JudgeAdapter as the evaluator' implies a configuration choice but doesn't tell the agent when to pick this tool over taifoon_grid_settlement or taifoon_judge_compose.

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 it does disclose a genuine behavioral trait: that payments_accepted reflects whether the deployment has an x402 facilitator, and that without one every wall returns HTTP 402 with terms. It says nothing about auth, pagination, or side effects, so it is only partially transparent for a read tool.

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?

Two sentences, front-loaded with the resource definition. The second sentence is dense and parenthetical, but nothing is decorative and the key fact (payment state is in the payload) is stated plainly.

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 and no annotations, so the description must be self-sufficient. It hints at the returned fields but omits the effect of the status filter and any auth or pagination behavior, leaving modest gaps for a simple single-parameter catalog listing.

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 enum and default LIVE are already documented. The description does not mention the status filter at all, and its phrase 'every skill' arguably obscures that the default view is LIVE-only; baseline 3 applies since 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?

It states a specific resource (the skills catalog) and enumerates what each entry contains: quoted price, rails, status. That is concrete, but it never distinguishes itself from sibling listing tools like taifoon_grid_prices, taifoon_offers, or taifoon_landscape, so the agent must still guess which catalog it wants.

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?

There is no explicit when-to-use, when-not, or named alternative. The only usage signal is implicit ('the skills catalog') and the aside about payments_accepted, which describes output rather than telling the agent when to reach for this tool.

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 behavioral burden. It usefully discloses that the value updates roughly every 10 seconds and that included chains are listed in the answer, but it does not state whether the tool is read-only, whether it requires any permissions, or what the response format is beyond listing chains.

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 two sentences and front-loads the core resource immediately. Every clause adds relevant context: the value, the frequency, the included chains, and the settlement role. There is 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?

For a zero-parameter getter with no output schema and no annotations, the description gives enough to understand what is returned and how current it is. It could be slightly more complete by describing the return shape or saying explicitly that no arguments are needed, but it is largely sufficient.

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 schema has zero parameters, so per the rubric the baseline is 4. There are no parameter semantics for the description to clarify, and it does not need to compensate for any schema coverage gap.

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 returned resource: the current Taifoon superroot, along with the chains it includes. It does not use an explicit verb like 'get', and it does not directly distinguish itself from any specific sibling tool, but the noun and scope are specific enough for an agent to identify the operation.

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 implies this is the current settlement referent for the coordination layer, but it gives no explicit when-to-use guidance, no prerequisites, and no alternatives such as taifoon_grid_settlement or other settlement-related sibling tools. The agent must infer the usage context.

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 reasonably well: it discloses the auth requirement (api_key or X-API-Key header), and crucially warns that supplying tile triggers a different operation (POST /v1/tenant/try) that is 'counted on your tenant' — an important side-effect/quota disclosure. It stops short of describing pagination, error behavior, or what the GET returns structurally.

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 sprawling run-on sentence cramming returned fields, auth, and the tile mode-switch together. The most important operational fact (the tile-triggered POST that counts against the tenant) is buried mid-sentence rather than front-loaded, hurting scannability.

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 3-param, no-output-schema, no-annotation tool, the description covers auth and the tile side-effect but leaves the tile enum semantics and return shape unexplained. It is marginally adequate but has clear gaps for a tool whose parameters carry enum ambiguity.

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 0%, so the description must compensate. It explains api_key (auth source, including header alternative) and clarifies that range is a time window for traffic (1d|7d|30d|90d), which adds meaning. But it never explains what the eight tile enum values (demand, catalog, pool, rpc, proof, grade, gpu, bridge) actually do, leaving the highest-cardinality parameter under-specified.

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 indicates this returns tenant-level data (id, keys, traffic, credits) and maps to GET /v1/tenant/me, so the resource is identifiable. However, the purpose is buried in a dense enumeration of returned fields ('demands, settles, pools, grades, credits, spend; plus GRID accrued... and GPU credit at the gate') and the dual mode (tile = sandbox action) muddies whether it is a read or an action tool. It never cleanly states what the tool IS in one clause, and it does not distinguish itself from siblings like taifoon_metrics or taifoon_network.

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 does provide a conditional usage rule: 'With tile, runs that sandbox action instead (POST /v1/tenant/try), counted on your tenant,' which tells the agent when the tool switches behavior. It also states auth requirements ('Needs your key...'). But there is no guidance on when to prefer this over sibling tools that surface overlapping data (metrics, network, landscape).

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 so well: it explains the burn is proven under the SuperRoot (receipt read from chain, block hash compared against the V5 proof) and discloses a fallback — the mint is only proven the same way when its chain is in the V5 snapshot, otherwise the reply states it rests on Circle's forwarder record. It omits any side-effect/auth/rate-limit profile, which keeps it from a 5.

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 verb and resource are front-loaded and each clause carries real information (class, proof mechanism, fallback, return shape). It is a dense single paragraph with heavy parenthetical nesting, which slightly hurts scanability but wastes little.

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 cross-chain proof tool with an output schema present, the description supplies the mechanism and the conditional fallback behavior an agent needs to interpret results. It stops short of describing error cases (e.g. burn not found) or failure semantics, but is otherwise complete.

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 documented in the schema (tx_hash = the burn transaction, chain_id = the chain the burn happened on with Base/Arc examples). The description only restates that these identify the CCTP burn, adding no format or constraint detail beyond the schema, so the 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?

The description states a specific verb (attest) and resource (cross-chain transfer / Circle CCTP V2 burn) and even names the operation class transfer.attest.cctp. It is highly specific, but it never contrasts itself against likely-overlapping siblings such as taifoon_proof, taifoon_superroot, or taifoon_finality_explain, so an agent cannot route between them from this text alone.

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 rather than stated: the agent can infer it applies to a Circle CCTP V2 burn given chain_id + tx_hash, e.g. Base → Arc. There is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling tools, leaving the selection decision to inference.

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