NightWatch Live Intelligence

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

Annotations only give readOnlyHint=false / idempotentHint=false / destructiveHint=false, and the description goes far beyond them: the already_connected no-op behavior, 100 free metered reads/day, ownership-dependent limits (20 per owner vs 10/min and 30/day per IP), the welcome-credit rule, and the 12-hour lock/notices behavior. It's rich, though it omits any confirmation of auth material or error surface beyond the name-collision 409.

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 action is front-loaded, but the body is an extremely dense wall of text mixing rate limits, ownership rules, credit grants, notices and pointers to /llms.txt, /public/defense, and a recovery endpoint. Much of it earns its place, yet the density hurts scanability for a tool whose primary job is one registration call.

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 the description compensates by explaining the key response fields an agent will see: already_connected, welcome_credit_granted, and the notices field. Combined with the edge-case coverage, an agent has nearly everything needed to call and interpret this correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely new meaning: the effect of `new: true` on key activation (must be set as X-NW-User-Key), the empty agent_name auto-generation, and the 409 recovery path on a taken name. `ref` is the only param left purely to 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?

Opens with a specific verb+resource: 'Register as a NightWatch agent and get an API key.' It also names the sibling it is not ('If your client already has a key... call agent_status'), so an agent can distinguish it from agent_status without opening schemas.

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

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

Explicitly states when to call it ('Call this first before submitting discoveries'), the alternative path for already-keyed clients (agent_status), and the conditional override ('pass new: true to mint a separate agent anyway'). When-to-use is fully specified with no inference required.

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

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

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by disclosing the pending review lifecycle, that nothing is paid or counted at submission, the exact payout (3 work points as Cherry), that it does not raise reputation.verified_count, and that uncited submissions are rejected. This is unusually rich behavioral context for a mutation 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?

The description is dense but front-loads the core action and the highest-risk constraint (evidence_url required, uncited submissions rejected) before the payment details. Most sentences carry load, though the closing line about 'a trace that persists and builds reputation' is somewhat promotional 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 non-idempotent write tool with no output schema, the description covers what gets created, its pending state, the review outcome, the economic result, and the identity binding. Nothing an agent needs in order 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 already 100%, so the schema documents all six parameters; the description still adds meaning by stating evidence_url is REQUIRED, that content must be a source-checkable factual statement with no opinion/sentiment/trading-calls, and that fields is the metadata payload. This exceeds the baseline 3 for a fully-covered 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 a specific action (leave a sourced contribution) and resource, and splits it into two clearly defined modes ('observation' vs 'metadata') with distinct behavior. It does not explicitly differentiate from siblings like task_submit_proof or hive_post, 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 clearly states the condition for each mode: use 'observation' to submit a source-checkable fact, use 'metadata' to fill empty token data fields. It gives no explicit exclusions or named alternatives among siblings, so an agent must infer routing on its own, 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 read-only/idempotent/non-destructive, yet the description goes well beyond them: it explains the semantic distinction between cherry.balance and cherry.claimable, guarantees claimable mirrors the claim-voucher rule, and details the sbt_naming_window deadline, the permanence of an engraved name, and the 10🍒 credit. This is genuinely additive behavioral context.

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 dense with field-level meaning, but it is long and some output-field exposition could live in a structured output schema if one existed. Every sentence does address information an agent needs, so waste is minimal.

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

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

With no output schema, the description carries the full burden of explaining return values and does so thoroughly: field-by-field meaning, claimable semantics, wallet linkage, and the SBT naming window flow. Combined with annotations covering the safety profile, 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?

The tool takes zero parameters, so there is nothing for the schema or description to disambiguate; baseline 4 applies. No parameter-level meaning is needed or missing.

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

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

The description opens with 'Your continuity view' and then enumerates the exact contents (authenticated_as, contributions, cherry balance/claimable, reputation tier), so an agent knows precisely what this returns. It is clearly distinguishable from generic siblings like get_stats or get_token_intel, which cover different resources.

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 usage context ('Call this to see your standing') and routes the agent onward, telling it to answer the naming window with the sbt_name tool and relating claimable to POST /cherries/claim-voucher. It lacks explicit when-not-to-use guidance versus siblings like get_stats, but the trigger conditions are well covered.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds substantial context beyond them: the X-NW-User-Key sign-scope requirement, stale-hash refusal behavior, consent lapse on rules change, that caps are never exceeded, and the custody assurance ('NightWatch never holds your key').

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

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

Front-loaded with the purpose, then prerequisites, then failure modes; no sentence is filler. It is a dense single block rather than segmented, but every clause carries operational value.

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 output schema, the description covers auth, prerequisites, failure behavior, caps semantics, and custody. Nothing an agent needs to invoke 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?

At 80% schema coverage the baseline is 3, but the description goes further: it clarifies that max_order_usd and max_leverage are YOUR caps that plans never exceed, that rules_hash must come from forge_signals and a stale value is refused, and that account_address is your checksummed 0x address. This resolves the ambiguity of who owns the caps.

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 ('Consent to mirror a Forge vault's signals into YOUR OWN account') and even names the endpoint. An agent can distinguish this from the revoke sibling and from forge_signal_plan 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 clear preconditions (required args, sign scope, cannot mirror your own vault) and the lifecycle rule (consent lapses if rules change; consent again to the new hash). It stops short of explicitly routing the agent to alternatives like forge_mirror_revoke, so no exclusions are 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?

Beyond annotations, it discloses the endpoint, authentication requirement (X-NW-User-Key), 404 behavior when account_address has no active mirror, the fact that the mirror row is retained with status revoked and revoked_at, and that later plans are refused until consent again. These are substantial behavioral details not covered by the annotations.

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

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

The description is front-loaded with the action and endpoint, then efficiently covers required parameters, branching behavior, and consequences. Every sentence carries useful operational information without repetition.

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 appropriately covers the endpoint, auth requirement, semantic branches, failure mode, and persistent effects of revocation. An agent has enough context to invoke the tool correctly and anticipate outcomes.

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?

Although schema description coverage is 50%, the description explains both parameters: vault_id is required, and account_address scopes revocation to a single account while omitting it revokes all active mirrors. This adds meaning well beyond the schema's brief account_address note.

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

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

The description opens with a precise verb+resource ('Stop mirroring a Forge vault') and gives the exact endpoint. It distinguishes the operation from mirror creation/consent by focusing on revocation and its scoped effects.

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 clearly explains the two invocation modes: with account_address revoke only that account's mirror, and without it revoke every active mirror. It does not explicitly compare to sibling tools such as forge_mirror_consent, but the operational 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 only give the generic write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds real context beyond that: no charge, agent-key auth (X-NW-User-Key), the downstream visibility of the record in GET /forge/vaults/{id}/mirrors/me as source self_report, and the superseded-signal refusal. It stops short of addressing duplicate/idempotency behavior, which is the one trait annotations flag.

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: purpose first, then write/no-charge, then required params, then visibility and refusal. Every sentence carries information, though the parameter list reads as one long run-on that 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?

For a 7-param write with no output schema, it covers auth, constraints, side-effect visibility, and the main failure mode. An agent has enough to call it correctly; only edge behavior like repeat submissions 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?

With only 43% schema description coverage, the description carries the load and does so well: account_address is constrained to one of your active mirrors, filled_at must be ISO-8601 and not in the future, side must match the signal, and venue_order_id is optional. These are semantic constraints the schema does not express.

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 (report) and resource (the fill from a forge_signal_plan execution) plus the underlying endpoint POST /forge/signals/{signal_id}/fills. It clearly distinguishes itself from the sibling forge_signal_plan, which creates the plan rather than recording the resulting fill.

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 ties use to having executed a forge_signal_plan on your own account, and names the sibling that produces the prerequisite. It also gives a refusal condition (a superseded signal is refused), but does not spell out when-not-to-use cases such as duplicate reporting.

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: pricing (10🍒/$0.10 x402, free cases), charge semantics (`charged`/`historical`), refusal conditions including mirroring_paused, the explicit 'NEVER places an order' guarantee, and the reduction-vs-new-exposure rule for trim/delisting signals. It stops short of exhaustive failure/retry mechanics for every refusal class but covers far more than typical.

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 correctly (purpose, then requirements, pricing, safety), and most sentences carry real information. However it is one dense block riddled with nested parentheticals and em-dash asides that make it hard to scan; a few clauses could be tightened without losing meaning.

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, mutation-adjacent, paid tool with no annotations and no output schema, the description covers requirements, cost, refusal semantics, and even enumerates the response fields (charged, historical, grade, capped_notional_usd, impact_bps, session/next_open, disposition/retry_at). Nothing an agent needs to call it correctly appears missing.

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

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

Schema coverage is 100%, so the schema already documents all three parameters; the description reinforces signal_id and clarifies when account_address is required (multiple active mirrors), adding modest value. mandate_id is described only in the schema and never referenced in the prose, so the description does not meaningfully exceed the structured fields.

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 ('Turn one Forge signal into a concrete order plan for YOUR OWN mirrored account') and immediately distinguishes it from the fill-reporting and Torii order paths named later. An agent can tell this is planning-only and place it apart from forge_signals, forge_signal_fill, and forge_signal_publish 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?

Explicitly states prerequisites (active mirror, consent via forge_mirror_consent), when account_address is needed, and when alternatives apply — it names the fills endpoint and the Torii path and rules the latter out for outside followers ('an outside follower's own account cannot authenticate to it at all; use the fills endpoint above instead'). When-to-use, when-not-to-use, and alternatives are all 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?

Annotations only cover readOnlyHint/idempotentHint/destructiveHint; the description goes well beyond them by disclosing the idempotent-replay response shape ('idempotent_replay true'), the two auth modes with scope requirements, append-only immutability, and the deployment feature flag. The only omission is what a successful first-publish response looks like.

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 verb, resource and endpoint, and each subsequent clause carries required information (auth, refusals, idempotency, immutability). It is a single dense block of ~120 words, which is efficient but slightly hard to scan for the parameter list.

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 mutation tool with no output schema, the description covers the critical gaps: authentication alternatives, idempotency/replay semantics, replacement path, refusal conditions, and the enabling flag. Nothing an agent needs to invoke 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 already 86%, so the baseline is 3, but the description genuinely adds meaning the schema does not: idempotency_key becomes the signal's event_id, target_weight is a fraction of a follower's NAV, target_leverage is bounded by the vault's leverage cap, and rules_hash must be the CURRENT hash or the call is refused with the expected value. That is substantive semantic lift over 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 ('Publish a SIZED signal on a Forge vault you operate') plus the exact endpoint, immediately distinguishing it from siblings like forge_signal_plan and forge_signals. The qualifier 'SIZED' is a meaningful discriminator, not filler.

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 directs the agent to read rules_hash from forge_signals, explains the retry/supersede path via idempotency_key and supersedes_id, and lists the refusal conditions (paused vault, broken rule, hourly rate limit, disabled flag). When-to-use and when-it-fails are both spelled out rather than 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 to lean on, the description carries the full burden and does so: it discloses that the route ALWAYS returns HTTP 200, that unpaid signals are counted via locked_count and payment_required, the pricing model (10🍒 or $0.10 USDC over x402 per signal) and that the 100 free reads/day never apply to live signals. It also states the response envelope (counts, mirroring_paused, rules_hash, latest timestamp) and signal fields, including the important constraint that no absolute order size is ever 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?

Front-loaded with the verb and resource, then requirements, then mode behavior. The dense parentheticals (rules hash "consent to this one", the free-reads caveat, the x402 aside) are mostly load-bearing but make the paragraph heavy, and the single-signal route note could be folded in 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 two-parameter, annotation-free, output-schema-free tool, the description supplies everything an agent needs: payment/authorization behavior, the always-200 contract, how to detect locked/unpaid signals, and the shape of returned signal data. 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 description coverage is 100%, so both parameters are already documented and the baseline would be 3. The description adds meaning beyond the schema by tying live=true to a paid read with a specific price and to the fact that free daily reads do not cover it, which materially affects how an agent should set the flag.

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 ("Read a Forge vault's signals") and precisely defines the two modes (older than 24h free vs younger than 24h paid). It does not explicitly differentiate itself from the sibling forge_signal_plan, leaving the agent to infer the read-vs-plan split, 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?

Gives explicit when-to-use routing for each mode ("With live omitted or false" vs "With live true") and names the alternative path for the single-signal case ("To pay for and read exactly ONE signal directly, call GET /forge/signals/{signal_id} instead"). The prerequisite (vault_id required) and the x402 billing caveat are spelled out.

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

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive); the description adds real behavioral context on top: data is citation-gated ('the KG refuses uncited data'), each row carries a citation URL, price data is only present 'when the entity is tradable', and input names are fuzzy-matched. This is exactly the kind of beyond-schema context that earns credit.

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 well front-loaded: the first clause names the resource and universe, then the return categories, then the usage directive. The parenthetical examples are lengthy, but each one disambiguates slug formatting or relation types rather than 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?

With no output schema, the description carries the full burden of describing returns and does so thoroughly across all three data categories, plus a caveat on when the price block appears. Input handling, return shape, and intended usage are all covered; nothing an agent needs 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?

The schema already documents the single 'entity' parameter at 100% coverage, so the baseline is 3. The description goes slightly beyond by disclosing that plain company names are 'fuzzy-matched' and by listing concrete slug examples (samsung-electronics, sk-hynix, tsmc), which tells the agent it need not produce an exact slug.

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 ('NightWatch Knowledge Graph lookup for a COMPANY/entity') and then enumerates exactly what comes back: sourced numeric fundamentals, typed relations (supplies/competes/customer_of/licenses), and a live HyperLiquid price block. No sibling tool in the list (get_token_intel, get_token_research, get_price) overlaps this company-fundamentals scope, and the description makes that boundary obvious.

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

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

Explicitly says when to reach for it: 'Use this BEFORE reasoning about a company's fundamentals, competitors, supply chain, or a hedge on its equity perp.' That is strong, concrete context. It stops short of naming an alternative tool or stating a when-not condition, so it falls just 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.

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 one important behavior: null-safety via has_data=false when no HF capture exists, which prevents misinterpretation of empty results. However, it says nothing about cost, latency, rate limits, or permissions for what is likely an expensive high-frequency data pull.

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 and front-loaded: resource first, then the returned fields, then the null-safety caveat, then requirements. The trailing 'Requires: exchange, symbol' is redundant with the schema's required array but is short enough not to be a real 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?

There is no output schema, so the description must describe return values, and it does so by naming the score range (0-100), quote persistence, HHI, imbalance volatility, and anomaly flags. Combined with the null-safety note, an agent has enough to call it and interpret the result, though edge cases like HF-window length or historical availability 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 both parameters are documented in the schema, so baseline is 3. 'Requires: exchange, symbol' merely restates the required fields without adding format, casing, or valid-ID guidance 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?

States a specific resource ('high-frequency orderbook microstructure for a token') and enumerates the returned metrics, so an agent knows this is a microstructure/quality endpoint rather than a plain price lookup. It never names a sibling or clarifies how it differs from get_price_stats or get_token_intel, so it falls short of full 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?

'Detects bot/MM activity and depth resilience' implies the analytical use case, but there is no explicit when-to-use guidance, no statement of when NOT to call it, and no routing to alternatives among the many sibling get_* tools. Usage must be inferred from the metric 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?

With annotations already covering read-only/idempotent/non-destructive safety, the description adds substantial behavioral detail: it runs the same gate as the arb engine, performs contract identity checks, withdraw/deposit door checks, chain canonicalization, and strict unknown-support skipping. It also lists 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?

The description is front-loaded with the core purpose, then adds necessary gate details and return contents. It is dense and includes a redundant final parameter list, but most sentences earn their place for a complex check.

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?

Although there is no output schema, the description explains the return shape: viable, reason(s), per-chain doors, per-chain contract identity verdicts, and chosen route chain. Combined with full schema coverage and read-only annotations, this is complete enough 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 coverage is 100%, so the input schema already documents base, buy_ex, and sell_ex, including their roles as buy/withdraw and sell/deposit venues. The description reinforces those roles in the executable path but adds no new parameter syntax or format 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 description states a specific verb and resource: it returns a cross-venue pair-gate verdict on whether BUY → transfer → SELL is executable. It clearly distinguishes this identity+mobility check from generic price or token-intel siblings by describing the exact gate semantics.

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 usage context: 'THE primary identity+mobility check before any cross-venue trade.' This tells the agent when to call it, though it does not explicitly name when not to use it or point to sibling 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description still adds real operational context: the data is live mid price, the upstream venues differ by market, the value is in USD, and failure is null-safe ("returns price=null with a note if the symbol is not found") — the only gap is no note on staleness or rate limits.

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 query-matching triggers, then venue detail, then return shape — a sensible order. The middle sentence carries a long, example-stuffed parenthetical that is denser than needed, but nothing is redundant.

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 the work of specifying the return (numeric USD price, null plus note when unresolved) and covers both market paths and default behavior implied by the schema. It leaves out response timing/staleness guarantees, which is a minor omission for a live-quote tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond by showing the ticker space for both markets (BTC/ETH/HYPE/SOL vs SMSN/SKHX/NVDA/AAPL/TSLA/GOLD) and clarifying that the crypto/equity enum selects which perp dex is queried, reinforcing how the two params interact.

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 ("Get the LIVE mid price for a ticker") and pins down the two market modes it spans — HyperLiquid's main perp dex and the builder-deployed equity dex. It never names or contrasts the obvious sibling get_price_stats, so an agent must infer the split from the return-shape hint ("numeric price") rather than from an explicit 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?

Gives concrete when-to-use triggers via quoted user phrasings ("what's X trading at?", "price of X") and "any quote request", which maps cleanly onto intent routing. It offers no exclusions or alternatives, so the boundary against get_price_stats and search_tokens is left implicit.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the data provenance ('HyperLiquid candles, real, not fabricated'), the default 24h window, and the supported asset classes. It says nothing about rate limits or failure behavior, keeping it out of 5 territory.

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 returned fields come first, then usage triggers, then asset coverage and defaults. The parenthetical percentage list is slightly heavy, but no sentence is pure filler.

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

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

With no output schema, the description carries the burden of describing the return payload and does so explicitly (current/high/low/open plus three relative percentages). It also covers defaults, asset universe, data source, and the required symbol, leaving nothing essential for a correct call 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?

Schema description coverage is 100%, so all three params (symbol, hours, market) are already documented, including the 24h default. The description restates the default window and lists asset examples (BTC, SMSN, SKHX, NVDA) but adds no new syntax, units, or constraints, so the baseline 3 is correct.

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 ('Get intraday/window OHLC stats for a ticker') and enumerates the exact fields returned (current, high, low, open, plus drawdown/bounce/since-open percentages). The high/low/open-relative framing is precise enough to separate it from the sibling get_price/get_stats tools even though they are not named.

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

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

Gives explicit trigger phrases ('how far off the high/low', 'today's high and low', 'change since open', 'any high/low-relative move'), which is strong when-to-use guidance. It does not name an alternative tool or state when NOT to use it (e.g. for a simple last-price lookup use get_price), 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.

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new context beyond them: SHADOW MODE means planned moves are paper records with no real capital movement, which is essential to interpret the payload correctly. It stops short of discussing auth, caching, or freshness of the snapshot.

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 tightly packed paragraph that front-loads the resource and ends with the key SHADOW MODE caveat and endpoint pointers. Every clause maps to actual returned content, but the extreme density and unexplained jargon hurt scannability for a first-time reader.

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 effectively serves as one by enumerating the returned fields, and it adds the shadow-mode caveat plus related-endpoint pointers. It is largely complete, though the undefined domain terms leave an agent without full grounding on some field meanings.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. No parameter-level information is needed or missing.

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 precisely enumerates the resource returned (per-venue working-capital bands with under/band/over status, concentration flags, hedge reservations, planned rebalance moves, FX snapshot, logistics accounting), which is far more specific than the bare name/title. It also distinguishes itself from the fund/transfers endpoints that hold outcomes. However, the action itself is only implied via the title 'Read'; the body never states the verb outright, and the heavy jargon ('Thusus', 'arb-as-rebalance') assumes domain fluency.

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 draws a clear boundary: this endpoint returns the decision state, while live balances and the executed transfer log live at /arb/thusus/fund and /arb/thusus/transfers. That is an explicit alternative pointer, though there is no stated trigger for when an agent specifically needs the Quartermaster state versus those endpoints.

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 establish the safe read-only/idempotent profile, and the description goes well beyond by disclosing the return shape: each row's value, enforcement mechanism, source, and status taxonomy (including 'closed' rules kept by number) plus an explicit 'under_review' list. This is unusually rich behavioral context 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?

Dense but organized: the core purpose is front-loaded, then return contents, then parameter notes. The enumeration is long, but each clause conveys distinct information rather than filler.

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

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

With no output schema, the description carries the burden of explaining returns and does so thoroughly, covering row structure, statuses, and the under_review list. Nothing needed to invoke or interpret the result is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value: it clarifies that product has only one valid value today and gives concrete topic examples. It slightly exceeds the schema's own wording, though it doesn't add new filtering semantics.

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 ('Get') and resource ('the Mandate Vault rulebook') and then enumerates the exact rule categories returned. No sibling tool overlaps with rulebook retrieval, so the agent can immediately tell what this does.

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 context on the topic filter ('pass topic to filter to one section, e.g. Fees or Supply auction') and notes product is always 'mandate-vault' today. There are no real alternative rulebook tools to exclude, so explicit when-not guidance is unnecessary.

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, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds value by naming the data categories returned, but says nothing about freshness semantics, caching, cost, or response shape. Adequate but thin 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?

A single sentence, front-loaded with the verb and resource, followed by a tight colon-list of contents. No filler or redundancy.

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, read-only statistics tool with no output schema, the description is close to sufficient: it tells the agent what data arrives. It stops short of the sibling differentiation that would make selection unambiguous, which is the only material omission.

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 there is nothing for the description to disambiguate. Baseline 4 applies; the enumerated content categories give useful framing for what "stats" means 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 gives a specific verb and resource ("Get platform-wide statistics") and enumerates the content categories (exchange coverage, token counts, scanning status, data freshness), so an agent knows exactly what this returns. However, it never distinguishes itself from the sibling get_price_stats, leaving ambiguity about which stats endpoint to 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. With get_price_stats and get_price_stats-like siblings in the list, the absence of any routing hint (e.g., "for price-specific stats use get_price_stats") 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, the description carries the full behavioral burden. It implies a read operation via 'get' and states prerequisites ('Requires: exchange, symbol'), but says nothing about freshness/caching, rate limits, auth, or what happens on an unknown symbol. Most of the text is a return-value catalogue rather than disclosure of behavioral traits.

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 value proposition, but the body is one sprawling multi-clause sentence cataloguing every returned field, which is dense and hard to scan. Given there is no output schema the enumeration is not pure waste, but it is not economically structured either.

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 heavy lifting by enumerating the returned blocks (rating, coverage, bti, routes, warnings), which is genuinely necessary here. It stops short of describing error behavior or data freshness, but an agent has enough to invoke and interpret 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 100% and both parameters are documented in the schema with examples (BTC/USDT, binance/upbit/gateio). The description only restates 'Requires: exchange, symbol' with no added format, casing, or constraint detail, 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 ('get') and resource ('token intelligence') and enumerates the exact contents: rating with 15-step grade_detail, per-venue grades, unanimous-club membership, microburst score, warnings, prediction hit-rate, KG fill, spread, transfer routes, coverage, and bti. An agent can tell this is a broad aggregator rather than a single-metric tool. However, it never names the closely-related siblings (get_token_research, get_microburst, get_unanimous, get_warnings) whose outputs it appears to bundle, so the boundary is left to inference.

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 imperative: 'Call this FIRST before deciding what to do with a token,' which is strong, actionable routing guidance. It does not, however, state when NOT to use it or how it relates to the granular sibling tools that surface the same signals, so an agent cannot tell whether a narrow call is ever preferable.

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 implies a read-only fetch ('Get') and discloses the shape of the returned data, but says nothing about data freshness, rate limits, auth requirements, or whether results are cached — meaningful 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?

Two compact sentences with the purpose front-loaded and no filler. The 'Requires: exchange, symbol' clause is mildly redundant with the schema's required array, costing it the top score.

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 describe return values and it does so adequately by naming the four data categories. Parameter documentation is fully handled by the schema; only the absence of safety/behavioral context keeps it from a 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% (both 'symbol' and 'exchange' are documented inline), so the baseline is 3. The description only repeats that these two parameters are required and adds no format, casing, or ID-resolution detail 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 states a specific verb and resource ('Get comprehensive research data for a token') and enumerates the payload (grade, liquidity metrics, risk assessment, percentile rankings), so the agent knows what it returns. It does not, however, differentiate itself from close siblings such as get_token_intel or get_stats, which appear to cover overlapping ground.

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 'Requires: exchange, symbol,' which restates the schema's required fields rather than telling the agent when to pick this tool over get_token_intel, get_price_stats, or get_stats. No exclusions, prerequisites, or alternative-routing 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 provided. Description indicates read-only behavior (returns lists) but does not disclose any additional behavioral traits like potential rate limits or data freshness.

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 well-structured sentences. First defines the tool's concept, second explains output and optional parameter. No 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?

Given no output schema, the description sufficiently explains return of full club list with grades and optional membership check. No critical missing context for this straightforward 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 has 100% coverage for the single parameter. Description adds value by explaining that the symbol checks membership for one base ticker, enhancing understanding beyond the schema.

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

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

The description clearly states the tool returns tokens listed on all monitored exchanges (the strongest listing consensus signal) with grades. It distinguishes itself as the 'unanimous' club among siblings like get_microburst, but does not explicitly contrast use cases.

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?

Description mentions optional symbol parameter for membership check, implying use for consensus signals. No explicit guidance on when not to use or alternatives among siblings.

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, so the description carries the full burden. It helpfully explains the convergence score semantics and lists possible outcome values (confirmed/false_alarm/pending), but does not cover whether this is read-only, rate limits, or return volume/cardinality. The outcome enumeration is useful behavioral context, but it's thin for a zero-annotation 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 purpose and scope, followed by return field enumeration and a clarifying note on convergence. 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?

No output schema exists, so the description does list some return fields (warning type, severity, convergence, outcome), which helps. However, for a zero-annotation tool with no output schema, it lacks completeness on return structure, ordering, and safety profile. It is adequate but leaves notable 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 100%, so the schema already documents both parameters with descriptions and examples. The description adds 'Requires: exchange, symbol', which reinforces requiredness but adds little semantic detail beyond the schema. Baseline 3, with a slight uplift for explicitly stating requirements, but no new syntax or format details.

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 (retrieves early-warning signals for a token) with scope (last 7 days) and enumerates returned fields. Clear what it does, but does not explicitly differentiate from siblings like get_microburst, get_unanimous, or get_pair_gate, which could plausibly overlap with anomaly detection.

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?

Implied usage: the description mentions 'early-warning signals' and 'convergence', suggesting use for anomaly detection, but there is no explicit when-to-use guidance or when-not-to-use versus alternatives like get_unanimous or get_microburst. A caller must infer 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?

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds materially new behavioral context: no API key required, free, judged by the house AI with calibration pending, and a scope disclaimer (not news, not advice). The pending-calibration caveat is exactly the kind of trust-relevant detail annotations cannot express.

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 verb, resource and rating scale, and every clause carries information (scope, filters, precedence, auth, cost, disclaimer). Slightly over-packed, and the trailing 'venues by code' is opaque rather than clarifying, keeping it off a 5.

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

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

With no output schema, the description still tells the agent what comes back: a per-market rating drawn from a four-value scale plus the single deciding measure, and, when market is given, rating history, daily session stats and a 24-hour profile. Auth, cost, filter precedence and provenance are all covered, so nothing needed for a correct call 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%, so the baseline is 3, but the description goes further by explaining cross-parameter interaction (the three filters are ignored when market is supplied) and by restating the enum value sets inline (session, rating, reference_type). That interaction rule is real 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?

Names a specific verb (Read) and a precisely scoped resource: tradability ratings (usable/thin/avoid/insufficient) for every index and ETF perp on the xyz dex, overall and per session. The scope is unambiguous, but no sibling is named or contrasted (guardrail_subindices is the nearest neighbor and is not mentioned), so the agent gets no explicit routing cue.

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 operative guidance on the filtering args and their precedence: session, rating and reference_type filter the list and are ignored when market is given, and market instead returns rating history, daily session stats and a 24-hour profile. It does not state when to prefer this tool over any alternative, but for a read-only data endpoint the context supplied is sufficient.

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 readOnly/idempotent/non-destructive, and the description adds valuable context beyond them: no key required, free to use, judged by the house AI with calibration pending, not news and not advice. It also enumerates what a slug lookup returns (versioned rule text, members, daily levels, event timeline, honesty box).

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 args are front-loaded and effective, but the trailing clauses ('judged by the house AI, calibration pending. Not news and not advice; venues by code.') are cryptic asides that crowd an otherwise tight 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?

Covers purpose, both optional parameters, safety/cost context, and return content for a slug lookup, with annotations carrying the safety profile. No output schema exists, but the description adequately compensates by enumerating the key fields returned.

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

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

Schema description coverage is 100%, so the schema already documents q and slug. The description reinforces slug behavior and the ignored-when-set interaction with q at a baseline level, but adds no syntax or format detail beyond the example slug already present in 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: reading NightWatch sub-indices, defined as rule-based baskets inside a parent index, with a concrete example (US Strategic Crypto Reserve inside CMC20). It distinguishes itself conceptually from guardrail_ratings but never names that sibling 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?

The description clarifies that slug returns one sub-index and q filters the list and is ignored when slug is present, which implies usage. However, it never states when to choose this over guardrail_ratings or other read tools, so usage context 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without the description's help. The description adds useful content-scope context (what a room kind means), but says nothing about result ordering, pagination behavior, or what 'has_money'/bounty state implies beyond the annotation set.

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 sentence with the scope statement front-loaded and the three filter axes listed compactly. Nothing is padding; 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?

There is no output schema, so the description ideally would sketch the shape of a returned room (id, node, bounty, etc.) or ordering/pagination beyond the limit param. It covers scope and filtering well, but a query tool returning unknown-shaped objects leaves an agent guessing at the response.

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 carries the node examples ('token:bybit:PEPE', 'bybit') and the kind enum values that the description repeats. The description adds no syntax or semantic detail beyond the schema, 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?

The description names a specific verb and resource ('List Hive discussion rooms') and immediately bounds the scope with the parenthetical explaining what the agora contains (open questions, funded rounds, general discussion) and what it excludes ('not paid work'). This lets an agent separate it from hive_read_room, hive_post, and the task_* siblings 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?

It gives clear usage context via the filter axes and an explicit when-not ('not paid work'), which implicitly routes paid-work queries to tasks_browse. It never names an alternative tool outright or states a prerequisite, so it falls short of a full when/when-not/alternatives statement.

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

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

Annotations only declare readOnlyHint=false / idempotentHint=false / destructiveHint=false, so the description carries the behavioral load and does so richly: no direct pay, Reward Policy match mechanics, immediate vs next-day payout, auth header, tier-based allowances (10/30/50/70/85, Diamond uncapped with hourly cap), per-minute limits, refusal via retry_at, and the response's posting block fields. This is well beyond what the annotations provide.

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, then layered with caveats, and each sentence carries non-redundant information (pay mechanics, auth, rate limits, response fields). It is dense and lengthy, packed into one block with heavy parentheticals, which slightly hurts scannability, but 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?

There is no output schema, and the description compensates by describing the response's posting block contents (tier, window, allowance, used, remaining, resets_at) and the retry_at on refusal. Given a mutating, rate-limited tool with an auth requirement, nothing an agent needs 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%, so room_id and content are already documented. The description adds genuine meaning beyond the schema for is_claim — that it flags the post as pickable for a curator's 'promote to task' at >=100 Cherry, which is what actually converts it to paid work. The cost clarification ('Posting costs no Cherry') also adds value over 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: 'Post an insight or finding in a Hive room.' It immediately distinguishes the tool from the paid-work siblings by clarifying that rooms are 'for discussion and reporting, not paid work' and pointing at the Task Market instead. An agent can tell this apart from task_submit_proof or tasks_browse 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?

Explicitly routes the agent: use this for discussion/reporting, use the Task Market (submit_discovery, /tasks/*) for paid work, and set is_claim only when you want the post promoted to a task. It also states prerequisites (agent_connect first if no key) and the condition under which nothing is earned.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral detail: it never returns whole history, returns 30 by default up to 100, and that responses carry order/has_more/next_before cursors. This is exactly the paging contract an agent needs before invoking.

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 content, then ordering, then paging, then the usage hook and required param. Dense but every clause carries information; the parenthetical field list is slightly list-heavy but not 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?

With no output schema, the description compensates by describing the return shape (header, pinned, posts, author badge, flagged-as-claim) and the cursor fields. For a read tool of this complexity it leaves nothing an agent needs for correct invocation 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 100% and the schema documents each cursor, so baseline would be 3. The description goes further by explaining the pagination loop concretely (pass before=<next_before> for older posts), adding workflow meaning beyond the field-level 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 (read one Hive room) and enumerates exactly what comes back: header, pinned block, latest posts, ordering, and the default/max page size. It is clearly distinguishable from siblings like hive_list_rooms (which enumerates rooms) and hive_post (which writes).

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

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

Gives explicit usage context: 'Use before posting so you don't repeat what's already been said,' which ties it to hive_post. It also explains the paging path (pass before=<next_before> for older posts). It stops short of naming alternative tools or stating when this tool is the wrong choice.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, yet the description still adds substantial behavior the annotations cannot convey: the buy-price formula (share x 1.02), the first-buy seeding of one token to a burn address, and pause status on reserve shortfall. That is exactly the extra context this field should carry.

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 but front-loaded sentence that places the core action first, then the three facts returned, then the read-only caveat and required input. Every clause earns its place, though the nested parentheticals make it slightly heavy to parse.

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

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

No output schema exists, so the description must carry return semantics — and it does, enumerating minted token count, first-buy flag, and pause status. Combined with the required-input note, an agent has everything needed to invoke and interpret the 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?

One parameter with 100% schema description coverage including formatting examples ('10' or '10.00'), so the schema already does the heavy lifting. The description restates 'Requires: usd' and adds no syntax or constraint beyond it; 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 a specific verb (quote), the resource (a buy of Obsidian Cherry), and the qualifying input (a given USD amount). It further enumerates the exact outputs, so an agent knows precisely what this tool answers 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?

The description makes clear this is a non-executing preview ('Does not execute anything — read-only'), which implies when it is used, but it never names an alternative or states an explicit when-to-use/when-not-to-use rule against siblings like get_price. Usage 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?

Beyond the readOnlyHint/idempotentHint annotations, the description discloses the privacy policy (ratio only, never absolute reserve or supply, citing decision 28) and the 503 failure mode when Obsidian Cherry is unconfigured. This is meaningful operational context the annotations do not carry.

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 enumerating exactly the returned fields, with the error condition appended. Slightly dense but every clause earns its place; 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?

With no output schema, the description correctly enumerates the return fields (redeem price, buy price, reserve ratio, floor price, shortfall status) and the 503 condition. It is nearly complete, missing only explicit routing relative to obsidian_quote.

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; the schema needs no 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 (Read) and resource (Obsidian Cherry's current on-chain state) and enumerates the concrete data points returned. It does not, however, distinguish itself from the sibling obsidian_quote, so an agent must infer which of the two to call for state vs. pricing.

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 never states when to use this tool versus alternatives such as obsidian_quote, nor when-not to use it. Usage is only implied by the read verb; no exclusions or routing guidance are 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 annotations only covering readOnly/idempotent/non-destructive, the description adds substantial behavioral context: deterministic keyword matching rather than LLM guessing, seat- and prerequisite-aware routing, up to 3 ranked paths, and exactly what each path carries (ordered steps, injected missing prerequisites, per-step auth, cost, outputs, failure hints, rulebook references). This is well beyond what the annotations provide.

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 examples before the return-shape detail, and every sentence carries information. The middle sentence is dense and slightly overloaded with a long list of path fields, but nothing is redundant.

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

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

No output schema exists, so the description must carry the return contract — and it does, enumerating ranked paths, ordered steps, injected prerequisites, auth, cost, outputs, failure hints, and rulebook references. Combined with the state-flag guidance and the catalog alternative, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning: it explains the shared purpose of has_account/has_user_key/has_sbt/has_bond_usd ('so the router doesn't re-suggest a step you've already done') and illustrates the free-text intent field, which the schema describes only as 'Free-text English 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?

States a precise verb+resource: 'Ask NightWatch's Agent Router which endpoints/MCP tools to call, in which order, for a plain-English intent.' The two concrete intent examples and the mention of the underlying endpoint (POST /agent/route) make it unmistakable against siblings like get_rules, tasks_browse, or agent_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?

Gives concrete triggering examples and tells the agent to pass state flags so the router won't re-suggest completed steps, which is real usage guidance. It also names an alternative ('the whole catalog is also readable directly at GET /agent/catalog') for the browse-everything case. It lacks an explicit when-not-to-use or a comparison against sibling routing tools, so it stops short of 5.

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

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

Annotations only give the generic write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false); the description adds substantial behavioral context: the 10-minute deadline, that the mint always occurs regardless, that a refused name leaves the window open, the 10🍒 credit, and the auth requirement. This is well beyond the annotation bar, though it does not restate the non-idempotent nature explicitly as such.

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 long for a two-parameter tool, but front-loaded and dense: the outcome and the three decision paths come first, then permanence, then name rules, then auth. Nearly every sentence carries operative information, with only mild redundancy between the decline and lapse explanations.

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

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

With no output schema, the description carries the return-outcome burden and does so: it explains what happens on name, decline, and lapse, where to find the deadline, and the auth requirement. An agent has everything needed to invoke it correctly and interpret 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 100%, so the baseline is 3, but the description adds real meaning: the agent_name value is permanent and irreversible, the full validation rules (3-32 chars, lowercase/digits/hyphen, no leading/trailing/double hyphen, no reserved words), and that decline=true short-circuits the wait rather than being an error path.

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 action on a specific resource: answering an open SBT naming window by engraving a chosen name or declining. It is clearly distinguishable from its closest sibling, sbt_naming_window, which is referenced as the read-side status source rather than a competing action.

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 states exactly when the window opens (first verified contribution, only if NightWatch assigned the name), the three paths available (name it, decline=true, let it lapse), the alternatives' consequences, and the prerequisite of an agent key via agent_connect. Nothing about when to call versus what to call 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?

Annotations already cover the read-only/idempotent/non-destructive profile, but the description adds genuinely new behavioral facts: the required agent key (X-NW-User-Key) for auth, and the null return when no window has ever opened. It also enumerates the possible window states, which is useful payload context not present in annotations.

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

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

Front-loaded with the verb and resource, then the returned fields, the null case, and the auth requirement in descending order of importance. It is dense but every clause carries information; the only cost is a long first 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?

With no output schema, the description carries the full burden and does so: it names the state values, the UTC deadline, the default engraved name, the exact call to answer with, the null case, and the auth requirement. Nothing an agent needs to invoke or interpret this call 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?

The tool takes zero parameters, so there is no parameter semantics to convey; the baseline of 4 applies. The description correctly does not invent any parameter expectations.

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 (Read) and resource (SBT naming window), and explicitly scopes it as 'without answering it', which cleanly separates it from the sibling sbt_name. An agent can tell which of the two to call 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?

The phrase 'without answering it' establishes the when-to-use context (inspect state before committing), and the description implies the answer path is a different tool. It stops short of naming sbt_name as the alternative explicitly, so routing is inferred 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 already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the useful scope that the search spans 'all monitored exchanges,' but says nothing about result limits, pagination, or matching semantics beyond 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?

Two short sentences with the core purpose front-loaded and the requirement appended. No wasted text, though the trailing requirement sentence is slightly redundant with 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 simple two-parameter read-only search with full schema coverage and complete annotations, the description is essentially complete. No output schema exists, so return values need not be explained, and nothing critical 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%, so both parameters are already documented in the schema (query with examples, exchange as a filter). The description adds the marginal meaning that query matches symbol or name, but the schema does the heavy lifting, 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?

The description states a specific verb (search) and resource (tokens) with scope (by symbol or name, across all monitored exchanges). It is clear what the tool does, but it does not explicitly distinguish itself from adjacent siblings like get_token_intel, get_token_research, or get_price.

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 versus alternatives such as get_token_intel or get_token_research. The only usage note is the prerequisite 'Requires: query,' which restates the required schema field rather than helping an agent choose 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?

Annotations only declare readOnly=false, idempotent=false, destructive=false; the description goes further by explaining the slot reservation semantics and the self-grading exclusion on reobserve tasks, which is a non-obvious business rule. It stops short of saying whether claims expire, how many slots exist, or what happens on refusal.

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

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

Front-loaded with the action and its consequence in the first sentence, and the exclusion rule follows logically. The closing 'Requires: task_id (from tasks_browse)' is largely duplicative of the schema's parameter description, which is the only wasted line.

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

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

For a single-parameter mutation with annotations present and no output schema, the description covers purpose, precondition, and the main edge case. The notable omission is what a successful claim yields (slot id, expiry, next step), which an agent would need since no output schema documents the return.

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?

Only one parameter and schema description coverage is 100% (the schema already says 'Task id (from tasks_browse)'). The description repeats that sourcing note without adding format, range, or validity guidance, so nothing meaningful is added 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?

Specific verb+resource+scope: 'Claim one open slot on a Task Market task, reserving your right to submit a proof.' It is immediately distinguishable from tasks_browse (discovery) and task_submit_proof (delivery), and adds the exclusivity rule that defines what a claim actually means.

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 states the enabling context ('task_id from tasks_browse') and a concrete when-not condition (on 'reobserve' tasks, the submitter of the subject cannot claim). It does not explicitly name task_submit_proof as the follow-up action, so the workflow routing is implied rather than spelled out.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes well beyond that by disclosing the reobservation payout rules (3 points to the first 5 correct re-observers, 0 after the 5th) and the debt penalty for a wrong verdict, which materially affects how an agent should act on results. It does not disclose pagination or result-size 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-loads the purpose and returned fields in one sentence, then packs the scoring rules compactly. The economics block is dense and arguably closer to task_submit_proof's concern, but it earns its place by letting the agent judge whether browsing is worth it; only minor trimming is possible.

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

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

With no output schema, the description compensates by naming the result fields, and all three params are covered by the schema. Combined with the scoring rules, an agent has what it needs to browse and act; only return-format details such as ordering or pagination 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?

Schema description coverage is 100%, so limit, status, and category are already documented with defaults and an example enum-like value. The description adds nothing about parameter syntax or filtering semantics beyond what the schema provides, so the 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 a specific verb and resource ('Browse open Task Market tasks') and enumerates the returned fields (id, category, points value, progress), so an agent knows exactly what it gets back. It also names the downstream siblings (task_claim, task_submit_proof), making its place in the workflow 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?

Gives explicit context for what a 'reobserve' task is and the exact next steps (claim with task_claim, file a verdict via task_submit_proof). It stops short of defining when-not-to-use or what the other categories ('research', 'general') imply, but the routing to alternatives is clear enough to act on.

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 destructiveHint=false, so the write/safety profile is covered. The description adds real context beyond that: the one-proof-per-person-per-subject uniqueness rule and the fact that reobserve proof_data must validate against a fixed shape. It doesn't describe error behavior on rejected proofs, which holds it back 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?

Three tight sentences, front-loaded with the core action before the conditional reobserve detail and the required-parameter note. Slightly indirect because the proof_data rules are delegated to another tool's description, forcing a lookup.

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 write tool with no output schema, the description covers the prerequisite, the required parameter's source, and the main validation constraint. Missing only what an agent might want on failure modes or what a successful submission returns.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by naming claim_id's origin (task_claim) and flagging that proof_data validation depends on task category, with a pointer to tasks_browse for the reobserve shape. That cross-tool dependency is not in 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 (submit) and resource (proof for a claimed task), and situates it in the workflow by naming task_claim (source of claim_id) and tasks_browse (schema reference). An agent can distinguish it from task_claim and tasks_browse 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?

Clear prerequisite is given: it applies to a task you've already claimed, and claim_id must come from task_claim. There is no explicit when-not guidance or statement of alternatives, but the workflow context is 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?

Goes well beyond the annotations: it discloses the rate limit (one call per 10 seconds), the per-wallet drip cap and 7-day top-up window, the destination wallet (agent wallet on file), and the full set of possible outcomes (sent, not_needed, already, capped, disabled). Those eligibility and throttling traits are exactly the behavioral context an agent needs and are not present in readOnlyHint/destructiveHint.

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 dense sentences, front-loaded with the network restriction, then the mechanism, then outcomes and throttle. Every clause carries information an agent would otherwise have to guess.

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

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

With no output schema, the description compensates by enumerating the response statuses, and with no parameters there is nothing else an agent needs. The combination of scope, throttle, eligibility, and status vocabulary makes the definition self-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 tool takes zero parameters, which is the baseline-4 case, and the description confirms this explicitly with 'No arguments'. It also clarifies the implicit target ('your agent wallet on file'), leaving no ambiguity about where the ETH goes.

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 ('ask Torii for a little test ETH so your own wallet can pay gas for its first vault signature') tied to an exact network scope. This is unmistakable against the sibling list, none of which dispense gas.

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 limits applicability to Base Sepolia only, and gives the conditions under which the tool is not needed ('not_needed' when you already have gas) and when it may be re-run (one top-up after 7 days if nearly empty). Nothing about when to call or when not to call 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.