Taifoon coordination layer

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description is consistent with a mixed read/write tool. It adds non-obvious context beyond the annotations: topup is LEGACY and 'frozen by the top-up policy' with vault top-ups replacing it, and reseller_child mints a key whose markup is booked as a reseller_markup leg. It does not state auth/permission requirements, which is a minor gap.

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 front-loads the overall purpose, but the action list is a dense em-dash run-on that is hard to scan and mixes several operations into one sentence. Most content earns its place, yet the structure impedes quick parsing.

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 16-parameter, no-output-schema tool, the description enumerates every action and ties each to its relevant parameters, which is enough for an agent to call it correctly. Auth requirements and return shapes are the only notable omissions, and there is no output schema to defer to.

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 every parameter already documents the actions it applies to, so the schema does the heavy lifting. The description restates the markup and params examples (e.g. { "*": 1000 }, { "vault": ... }) rather than adding syntax beyond the schema, so it sits at the high-coverage 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?

The description names concrete verbs and resources per action (reads tenant/keys/traffic, access rents, metrics, mints child keys, computes earnings), so the agent knows what the tool does. It is a multi-action aggregator rather than a single verb+resource, but the capability set is explicit and it distinguishes itself from taifoon_register and taifoon_vault.

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

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

It gives explicit routing for two cases: 'For a new key use taifoon_register; for vault money use taifoon_vault.' That is real when-to-use-elsewhere guidance. It stops short of stating exclusions or prerequisites for the read actions, but the alternative-tool routing 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?

Annotations already cover mutation and open-world traits, but the description adds substantive context: charging only occurs after 'code checks the answer', and an unpaid call returns payment terms instead of an error. It omits failure/refund behavior and whether repeated calls re-charge, which are the remaining risks for a paid operation.

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 first sentence is well front-loaded and dense with meaning, but the nine-entry action enumeration repeats 'sold per call by Taifoon at ... USDC (x402)' verbatim each time, roughly tripling the length for the same 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 3-parameter tool with no output schema, the description covers the payment handshake, per-call costs, and the alternative tool. It stops short of describing what a successful response contains or what happens on a rejected/underpaid call.

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 baseline is 3, but the description adds decision-relevant pricing per action value (0.001–0.027917 USDC), which the schema does not carry. Minor gap: the schema promises each class 'lists its example in the action list', yet the description lists only prices, not per-class input examples.

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 ('Buys one call of a skill the layer sells per call (x402)') and explicitly distinguishes itself from the sibling taifoon_hire. An agent can tell this is the pay-per-call purchase path versus the job-hiring path without opening any 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?

Names the alternative (taifoon_hire) and its selecting condition, and explains the no-payment flow (returns payment terms) so the agent knows the two-step pattern. It does not rule out other siblings such as taifoon_find or taifoon_grade, which would make routing fully unambiguous.

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

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

Annotations cover safety (destructiveHint=false, openWorldHint=true) and the description adds real behavioral context beyond them: 'paged' reads with cursor/limit, a scan job that must be 'advance[d]', a 'priced' x402 query, and api_key auth for most actions. However, it never explains the notable tension that readOnlyHint=false while the tool is framed as a read surface (presumably the paid x402 path), nor does it mention cost, rate limits, or error 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?

One dense paragraph that is well front-loaded: purpose first, the sibling hand-off second, then the action catalogue. Each action gloss earns its place, but nine semicolon-separated clauses in a single block would scan far better as a list, and the actions/cost order is slightly 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?

For a nine-action, 31-parameter mega-tool with no output schema, the description correctly covers the action surface and the field-to-action mapping. It stops short on the things an agent still needs: what each action returns, the payment/retry flow for the priced query when unpaid, and why the annotations mark it non-readOnly.

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 every field already carries an '(actions: X)' tag, so the schema does the heavy lifting. The description's action glosses add some cross-field meaning (e.g. account = events or txs for one address, query = a priced x402 read on Base), but for the majority of the 31 parameters it largely restates what the schema tags already say.

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

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

Opens with a specific verb and enumerated resources ('Reads blocks, transactions, logs, accounts and protocol state from the layer's own index and coord RPC') and then names each of the nine actions with a distinct gloss. It also actively differentiates from the sibling taifoon_prove ('For a proof use taifoon_prove'), so an agent can place it relative to the rest of the family.

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 explicit alternative is named with its selecting condition (proofs go to taifoon_prove), and the action glosses function as routing guidance (lookup vs logs vs account vs rpc vs query vs scan). What is missing is when-NOT guidance or disambiguation between closely related actions, e.g. rpc vs query, or logs vs account.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine workflow context the annotations cannot: posting triggers an autonomous 'match, hire, grade and settle' loop, and status exposes 'every step written on it'. It stops short of stating irreversibility or what post returns.

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 and the alternative before the per-action enumeration, and the action list is compact. The opening clause ('Posts work in plain words and lets the layer match, hire, grade and settle it; reads demands') is slightly run-on but earns its place by conveying the pipeline.

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 14-parameter, four-action tool with no output schema, the description covers each action, its inputs, and the buyer/seller routing decision. It does not describe return payloads for post/list or error behavior, but the action descriptions for status/list/work partially imply them.

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 each parameter already tags its action ('actions: post'), so the schema does the heavy lifting. The description echoes the action-to-parameter bindings (need, budget, id) but adds no format or constraint detail beyond what the schema states, 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 specific verbs and resources for a multiplexed tool: 'post — post a need', 'status — one demand and every step written on it', 'list — demands, newest first, by state', 'work — the newest demands whose classes match yours'. It also explicitly names the sibling it is not (taifoon_hire), so an agent can route without opening either 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 an explicit alternative and selection condition: 'For choosing the seller yourself use taifoon_hire', implying this tool is for the auto-match path. Each action carries its own use case (buyer posting vs seller-side discovery via 'work').

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's job is to add context — and it does, disclosing pricing semantics ('ours (seller + routing fee)'), catalog cover/wall-payability, and what each action returns (e.g. seller 'classes, venues, price, record'). It omits pagination behavior despite limit/offset params, but otherwise adds real value beyond the annotations.

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

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

Front-loaded with purpose and routing before the action list, and every clause carries information. The action enumeration is a dense semicolon run rather than a structured list, which is harder to scan, but there is little outright waste.

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-action, 25-parameter dispatcher with no required params and no output schema, the description covers what each action yields but leaves the param-to-action contract reliant on schema tags whose 'descriptions' often just restate the parameter name. Adequate but not complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description ties groups of parameters to actions, but that mapping is already encoded in the schema's own 'actions: ...' tags, and several opaque parameters (jev, typesafe_key, api_key, findings) get no meaningful explanation 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+resource+scope ('finds agents, capabilities and resold skills for a job, ranked') and then enumerates all ten actions with a one-line scope for each. It also explicitly distinguishes itself from two siblings (taifoon_hire, taifoon_demand), so an agent can separate it from the rest of the toolkit without opening any 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?

Explicit routing is given for the two most confusable siblings: hiring a found result goes to taifoon_hire, posting a need goes to taifoon_demand. Within the tool, action selection is only implied by terse per-action one-liners (e.g. 'match — a ranked shortlist for required_skills'), with no stated when-not conditions across the ten actions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is carried by structured data. The description adds the auth requirement ('on your own TypeSafe key'), which is useful context, but says nothing about mutation effects, idempotency of the write actions, or rate limits beyond what annotations supply.

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

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

Front-loads the purpose, then the sibling alternative, then a compact action list. Dense but well organized, though jargon like 'recomputable digest' and 'release rubric' costs some clarity without adding much for the agent.

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

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

With 23 parameters, nested objects, and no output schema, the description covers the four actions but omits the many supporting parameters (job_id, execution_id, handshake_id, trading, price_usdc, answered_by, prepare_digest). Return-value behavior is not described and no output schema exists to compensate, leaving gaps for a tool this complex.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by mapping the action enum to concrete semantics ('up to 4 items in one calibrated call', 'one question about an item, with value, probabilities and confidence'). It still leaves many of the 23 parameters (job_id, execution_id, price_usdc, prepare_digest) unexplained in the prose.

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 ('Grades work ... reads the judge's decisions') and enumerates the four actions it dispatches. It explicitly names taifoon_prove as the sibling for proving a chain fact, so an agent can distinguish it from that alternative. The multi-action nature makes the top-line purpose slightly diffuse, but it is clearly conveyed.

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 routing: 'For proving a chain fact use taifoon_prove' gives an explicit alternative with its selecting condition, and each action gets a one-line when-to-use gloss (grade, compose, ref, decisions). No explicit exclusions beyond the prove pointer, but context is clear.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the safety profile is partly covered. The description adds real behavioral context the annotations don't: metered/measured work, quotes attached to 'hire', earnings from measured probes on 'join', and GRID-denominated pricing across operations — enough to signal this is a paid, side-effecting, non-reversible workflow. It stops short of stating auth/permission or rate-limit 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?

Front-loaded with the core purpose and the sibling routing before the action enumeration, and the dense clause list carries no filler sentences. It is, however, a very long run-on that largely mirrors the schema's action enum and per-parameter action tags, which makes it heavier than a 14-action router strictly needs.

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 correctly compensates by describing what each action returns ('hire — usable providers ... with endpoints and a quote', 'avenues — the outlets where Taifoon resells community capacity'). It still omits prerequisites such as when an api_key or wallet is required and how failures surface, which matters for a 34-parameter, zero-required-parameter mega-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% and each parameter already documents which actions it applies to, so the baseline is 3. The description's action list restates the meaning of the 'action' enum values rather than adding new parameter-level detail (the one exception, 'with your key' for gpu, is minor), so it does not meaningfully exceed 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 opening states a specific verb pair and resource ('Buys and sells measured compute and RPC on the Taifoon Grid') and then enumerates all 14 actions with a one-line meaning each, so an agent knows exactly what every call returns (e.g. 'status — what the Grid accepts and pays now', 'settlement — a wallet's Grid ledger'). It also names sibling alternatives ('For agent work use taifoon_find and taifoon_hire'), distinguishing itself from adjacent 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 explicit routing away from the tool for agent work ('use taifoon_find and taifoon_hire') and clear context for what each action does. However, with 14 actions there is no explicit guidance on when to pick 'ai' vs 'gpu' vs 'hire' beyond the terse per-action glosses, and no negative guidance for the read-only actions.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the mutation profile is covered. The description adds genuinely new behavioral context the annotations cannot: the funding/settlement calls are UNSIGNED and 'you sign', pool_open is 'simulated', and signing runs 'from' a specified wallet. It stops short of error/limits behavior beyond the single 409 line_closed mention.

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 and information-dense (~12 words per action, no filler), which is good. But the entire 17-action catalog is a single em-dash/semicolon run-on, so an agent must read the whole blob to locate its action; a structured list would earn the same content more cleanly.

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 17-action, 42-parameter, nested-object tool with no output schema, the description names each action but gives almost no information about what each returns or the required parameter combinations per action. The 100%-covered schema carries the input burden, but the complexity is only partially mastered.

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 every parameter already carries an '(actions: ...)' tag, so the baseline is 3. The description exceeds that by explaining what several actions actually mean/contain — e.g. quote returns 'deposit, premium, cover', assurance returns the unsigned fund/submit/complete/expire/reject calls — adding semantics the bare enum cannot.

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 gives a specific verb+resource+scope ('Hires a chosen agent end to end: terms, offer, delivery ... settlement plan, lifecycle') and explicitly names the siblings it is not (taifoon_find, taifoon_grade). It falls short of 5 because the tool is really a 17-action router, and the paragraph never states a single crisp purpose beyond the broad 'end to end' umbrella.

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

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

It explicitly routes two competing needs: 'For finding the agent use taifoon_find; for grading a delivery use taifoon_grade.' It also flags the default action ('what to do (default offer)'). However, it gives no guidance for choosing among the 17 in-tool actions versus the other 13 siblings, which is the harder routing decision.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds two useful operational facts: reads target 'live' state and api_key is optional for keyless reads. It says nothing about rate limits, freshness/latency, or error behavior for the many actions.

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?

Purpose and the account routing are front-loaded, which is good, but the 16-item action enumeration duplicates the schema enum almost verbatim and turns the description into a dense run-on list. It is informative yet padded with content the agent can already read from 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?

For a 13-parameter, 16-action read tool with no output schema and annotations covering safety, the description supplies the domain vocabulary but omits return-shape expectations, pagination behavior, and which actions require api_key versus keyless access. Adequate as a map, incomplete as an operating guide.

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 every parameter, including the action enum and its per-action applicability, is already documented in the schema. The description's action list restates the enum rather than adding format or semantics (e.g. what a chain id looks like, what 'reason' values exist). 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 set ('Reads the live network, the stream and protocol order state') and enumerates the domains it covers (sellers online, RPC health, stuck orders, Lambda Studio, etc.). It also explicitly distinguishes itself from taifoon_account. Because it is a 16-action multiplexer, the single-sentence purpose is necessarily broad, but an agent can still tell what it observes.

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 routing guidance is 'For your own account use taifoon_account.' The long action list implies when each mode applies but never states prerequisites, exclusions, or which sibling to prefer for overlapping reads (e.g. taifoon_chain, taifoon_demand, taifoon_op). Usage is inferable, not 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?

Annotations already declare readOnlyHint=false and openWorldHint=true, so the description is not carrying the safety burden alone. It still adds real value beyond them: how path parameters are bound by name (:protocol → params.protocol), how remaining params become query string vs. JSON body for POST, and that api_key is only needed for keyed operations. Note the destructiveHint=false annotation is a bit optimistic for a tool that can POST to arbitrary operations, but the description does not directly contradict it.

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

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

Three tight sentences, no filler. The core purpose is front-loaded, and the discovery hint, param-mapping rule, and auth note each carry distinct, non-redundant 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 no-output-schema generic dispatcher, the description covers discovery, param binding, method/body routing, and auth, which is most of what an agent needs to invoke it correctly. The one notable omission is explicit guidance on when to prefer this tool over the operation-specific siblings.

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 baseline is 3, and the description earns above that by explaining cross-parameter mechanics the schema cannot: the name-based binding of params to path segments, the query-string vs. body routing, the GET default for method, and the keyless-read/keyed-write split for api_key. It adds genuine semantics on top of the per-field schema text.

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: 'Call any public operation of the coordination API by its /v1 name'. This clearly identifies it as a generic dispatcher, which is distinct in kind from the operation-specific siblings. However, it never explicitly says how it relates to the 14 named siblings (taifoon_buy, taifoon_sell, etc.), leaving the agent to infer when the generic path is preferable.

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 tells the agent how to discover valid operation names (GET /v1/ops/search, GET /v1/openapi.json), which is useful procedural guidance. But it gives no rule for choosing this generic tool over the dedicated sibling tools that presumably wrap the same operations, so usage is only implied.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: 'deposit — credit a deposit that already landed on chain', 'withdraw — withdraw to the principal's operator wallet (the only destination)', 'register ... returns its one-time key', and the note that omitting the signature yields the exact message to sign. Only the irreversibility/error behavior of order and withdraw is left 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?

Purpose and the sibling escape hatch are front-loaded, then the action glossary follows in one dense block. Given 20 parameters and 7 dispatchable actions, the size is justified, though the run-on action enumeration ('account, deposit route, orders, withdrawals, settlement records') is slightly muddled before the per-action breakdown.

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-action dispatcher with 20 optional params and no output schema, the description does cover all seven actions plus some return behavior (one-time key from register, reconcile reading from settlement) and key constraints. It omits which parameters each action actually requires and how the api_key is obtained, which an agent would still need to discover from the schema 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 100% and every parameter already carries its own '(actions: X)' tag, so the schema does the heavy lifting. The description's action list largely restates that mapping rather than adding parameter-level meaning (units format, TIF semantics, market values are all in the schema). Baseline 3 is correct here.

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 concrete scope (Taifoon orderbook, spot ETH-USDG on Robinhood Chain) and enumerates all seven actions with a one-clause meaning each, so an agent knows what surface this tool covers. It distinguishes itself from taifoon_vault explicitly but not from the many siblings with overlapping names/actions (taifoon_buy, taifoon_sell, taifoon_register, taifoon_account), so it falls 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?

It gives one explicit routing rule — 'For tenant vaults use taifoon_vault' — which is genuine when-not guidance. However, with 15 siblings and several sharing action names (buy/sell/register/account), the description never says when this venue tool is the right choice versus those alternatives. Usage for the remaining actions is only implicit in the action list.

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?

The annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds proof-specific context such as proof.verify.v5, CCTP transfer attestation, and finality type-id interpretation, though it does not describe auth requirements or output shape.

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 and compact, using semicolons to keep the action map dense without wasted prose. It is appropriately sized for a tool with six distinct actions, though the single-paragraph action list is somewhat heavy.

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

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

With rich annotations, complete schema parameter descriptions, and no output schema, the description covers the tool's purpose, alternative sibling, and action semantics well. It omits return-value or error details, but those are not essential for selecting and invoking the tool in this context.

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 complete, so the baseline is 3, but the description adds meaning for the action enum beyond the schema's raw value list. It explains what each action does and associates some actions with relevant parameters, which helps the agent invoke the right mode.

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 blocks, transactions, logs and transfers under the Taifoon superroot. It also names the sibling taifoon_chain and clearly differentiates proof-based reads from ordinary chain reads.

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

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

It explicitly says to use taifoon_chain when reading chain data without a proof, and it enumerates each supported action with enough meaning for an agent to choose the right one. The action list functions as concrete per-mode usage guidance.

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

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

Annotations already declare non-read-only, non-idempotent, open-world. The description adds real context beyond them: the key is shown once, nothing is signed for wallet_address, and payment credits an existing key. It doesn't cover error/rate-limit behavior, but adds meaningful operational detail.

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 and alternative, then organizes detail by action. Dense but every clause carries information relevant to one of the actions; 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 9-parameter, no-output-schema tool, the description covers both actions, key delivery ('shown once'), and the x402/payment path, so an agent has enough to call it. Return-value detail is partially implied rather than fully 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 100%, so all nine parameters are already documented with per-action tags. The description largely restates schema facts (chain_id default 1284, wallet_address as optional label) rather than adding syntax or format beyond it, 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 (creates) and concrete resources (tenant with free key, or free RPC key), and explicitly names the sibling taifoon_account for the read case. An agent can distinguish it from taifoon_account without opening either 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?

Explicitly routes the read case to taifoon_account and breaks out the two actions (tenant vs rpc) with what each returns. It lacks an explicit statement of when to pick rpc over tenant beyond the descriptions, but the context is clear.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), so the description only needs to add context. It does add some: 'enrich an agent as its ERC-8004 owner (signed)' signals a signature/auth requirement, and 'pending — the protocol manifest approval queue' discloses an async review step. It still omits idempotency and conflict behavior for 'register' and says nothing about what a write actually changes.

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 purpose, then the sibling routing, then the action glossary — good ordering with no filler. Slightly eroded by a run-on first sentence and the vague phrase 'with what came back' for the inbox action.

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 36-parameter, five-action tool with nested objects and no output schema, the description does the minimum viable job of explaining each action. It never describes return shapes (e.g. inbox results, register outcome), pagination for the 'inbox' action despite a limit parameter, or error conditions, so an agent knows what to send but not what to expect.

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 every parameter is already tagged with its applicable action(s), so the schema carries the load and 3 is the baseline. The description's action summaries add operational meaning (signed enrich, https card URL, decoding contracts/events) but name almost no parameters directly, so it does not meaningfully extend 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 opening line and the action-by-action breakdown ('register — register an agent by the https URL of its own card; enrich — ...; inbox — ...') give a concrete verb+resource for each of the five modes and clearly frame the tool as the seller side. It also distinguishes itself from the buy path. It loses a point because the umbrella purpose ('Lists you as a seller') undersells a heterogeneous tool that also registers protocols and reads approval queues.

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?

'For buying use taifoon_find' is the only explicit routing rule, and it is genuinely useful. However, the tool overlaps heavily with siblings that go unnamed (taifoon_register for agent registration, taifoon_grade for manifest grading), and the description never says when to pick this tool's 'protocol' or 'pending' actions over those siblings. Usage is therefore implied by the action list 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?

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, and the description adds material context beyond them: the tool never signs (stated for both arm and owner), programs act only while armed and within caps, and some operations are gated with stated unlock conditions. It does not cover rate limits or error/auth failure behavior, so not 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?

Front-loaded with purpose, then model, then an action list, which is reasonable for a six-action tool. However it is a dense semicolon-chained run-on, repeats 'never signs' twice, and includes a tangent pointer ('GET /v1/vault/policy ... or the prompt vaults explains it all') that dilutes rather than informs.

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, multi-action tool with no output schema, the description covers all six actions, the three-address vault model, arming/caps, gating and the no-signing guarantee, and even implies return content for read ('three addresses with balances, caps, arm state and owner'). Return shapes for the other actions remain implicit, keeping it below 5.

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

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

Schema description coverage is 100% and the schema already tags each field with its applicable actions, so the description is largely redundant on parameters. It adds some value by tying arm/owner payloads to what the owner signs, but gives no format details beyond the schema. 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?

States specific verbs and resource: reads a tenant vault and constructs the owner-signed EIP-712 acts (arm/owner) that control it, then enumerates all six actions with one-line scopes. It also distinguishes itself from the sibling by name ('For the legacy key balance use taifoon_account'), so an agent can route correctly without opening a schema.

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

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

Each action carries its own selection cue (read for one-call state, model for how vaults work, policy for the signing register, receipts for verified acts, arm/owner for the exact EIP-712 payload to sign), and the account alternative is named for the legacy-balance case. It lacks explicit when-not-to-use framing beyond that one exclusion, so it stops short of a 5.

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