NightWatch Live Intelligence

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

With no annotations, the description carries full burden and is exceptionally transparent: it explains API key issuance, rate limits for owned vs unowned agents, welcome credit conditions, auto-generated names, 409 conflict recovery, and the notices field. It effectively discloses what will happen and what to check in the response.

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 long but every clause carries operational guidance relevant to a correct call. It is front-loaded with purpose and sequence, though length could have been trimmed by pointing to /llms.txt more aggressively.

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

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

No output schema or annotations exist, so the description must supply all context. It does: prerequisites (read /llms.txt), expected response checks (welcome_credit_granted, notices), error behavior (409), and post-registration rate limits. No critical calling information 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?

Both parameters are already described in schema (100% coverage), and the description adds behavioral detail: leaving agent_name/name empty auto-generates a unique name, and a taken name returns 409. This exceeds baseline schema-only information.

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 action ('Register as a NightWatch agent and get an API key') and frames it as the required first step before submitting discoveries. Detailed owned/unowned distinction removes ambiguity against sibling tools like agent_status or agent_contribute.

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 instructs to call this first before submitting discoveries and to read /llms.txt first. It does not name alternatives because registration is unique among siblings, but the ordering guidance is concrete.

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

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

With no annotations, the description carries the full behavioral burden and delivers: submission is held for review by a NightWatch reviewer, nothing is credited automatically, uncited content is rejected, and metadata routes to a different (mining) path. It omits rate limits, latency, and what an accepted contribution returns, so not a 5.

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

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

Front-loaded with the core action and the mandatory evidence requirement, then the two modes in order. The heavy use of em-dashes and parentheticals makes it slightly dense, but every sentence carries operative information.

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

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

For a 6-parameter, no-output-schema tool, the description covers both modes, the required field, and the review lifecycle. It leaves minor gaps: nothing about the outcome payload or whether symbol/exchange are required for each kind.

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: it flags evidence_url as REQUIRED and rejected-if-absent, constrains content to facts with no opinion/sentiment/trading-calls, and explains that kind=metadata activates the fields array. That is value 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 gives a specific verb ('leave a contribution') plus a clear resource and splits it into two named modes (observation, metadata) with what each does. It does not differentiate itself from sibling write tools like 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 selection condition between the two kinds: observation for source-checkable facts, metadata for filling empty token data fields. It also states the gating condition (evidence_url required, rejected if uncited). It stops short of naming alternative tools or explicit when-not-to-use cases.

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

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

No annotations are provided, so the description carries the full burden. It discloses that presence persists across calls, that `cherry.claimable` is aligned with the claim-voucher rule so it never names a figure the claim call would refuse, that welcome/promo credit is excluded, and that an engraved SBT name is permanent while the site alias is changeable. The read-only nature is conveyed via 'view' and 'Read'.

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 long but front-loaded: the first sentence gives the overview, then it details balance/claimable semantics, then the SBT window condition. Backticked field names aid parsing. Some redundancy exists (e.g., the welcome/promo credit clarification), but each sentence adds meaningful operational context.

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 or annotations, the description compensates by naming the key response fields (`cherry.balance`, `cherry.claimable`, `cherry.claimable_note`, `cherry.wallet_linked`, `sbt_naming_window`) and giving an actionable rule for the SBT window. It is sufficient to call and interpret the tool, though the exact response envelope and tier thresholds are not spelled out.

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 has zero parameters, so there is nothing beyond the schema to document. The baseline of 4 applies, and the description suitably focuses on interpreting the response instead of parameters.

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

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

The description opens with 'Your continuity view' and enumerates the exact data returned: contributions (total/verified/pending), Cherry balance/claimable, reputation tier, and the SBT naming window. It names the follow-up tool (`sbt_name`) and clearly distinguishes itself from data/market siblings like get_price or get_stats by focusing on the agent's own persistent standing.

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 instructs 'Call this to see your standing' and provides a concrete conditional: read `sbt_naming_window` in the reply, and if it is non-null with state 'open', respond using the sbt_name tool. This gives an explicit trigger and a named alternative, leaving no ambiguity about when to use this tool versus the sibling.

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

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

With no annotations provided, the description carries the full burden, and it delivers extensively: it discloses charging behavior (10🍒/$0.10, free if already paid, free for signals older than 24h), refusal behavior (breach of caps/mandate, mirroring_paused, superseded signals), the fact that a charge still happens on refusal, the NEVER-places-an-order guarantee, session deferral behavior (not auto-retried), and R78 liquidity safety rules. This is far beyond what annotations would have provided.

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 information-dense and front-loaded with the core purpose, but it is extremely long — a single paragraph of roughly 400 words covering charging, refusals, R78 rules, the Torii alternative, and self-reporting. Every sentence carries real information, so it earns its place, but the lack of any structural breaks (bullets, sections) makes it harder for an agent to parse quickly. It is comprehensive but at the edge of being overwhelming.

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

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

For a tool with no output schema and no annotations, the description is remarkably complete: it explains the response fields (charged, historical, grade, provisional, capped_notional_usd, impact_bps, session, disposition/retry_at), the follow-up action (report fills via POST /forge/signals/{id}/fills), the alternative Torii path, and the exact conditions under which the plan is refused or deferred. Nothing an agent needs to call this 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 the baseline is 3. The description adds meaningful context beyond the schema: signal_id is tied to forge_signals, and account_address is only needed to disambiguate when there are multiple active mirrors on the vault. It doesn't add format details for account_address beyond the schema's '0x...' hint, but the disambiguation guidance is genuinely useful.

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 specific verb and resource: 'Turn one Forge signal into a concrete order plan for YOUR OWN mirrored account.' It clearly distinguishes this from related tools like forge_signals (which lists signals) and from the Torii path, and it explicitly states what the tool does NOT do ('This call NEVER places an order'). This is a precise, non-tautological purpose 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?

The description gives explicit when-to-use guidance: requires signal_id and an active mirror, consent first via POST /forge/vaults/{id}/mirrors, pass account_address only if multiple mirrors. It also names the alternative Torii path and explains exactly when that alternative applies (NightWatch's own operator account only) versus the fills endpoint for outside followers. This is exemplary routing guidance.

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

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

With no annotations, the description carries full behavioral burden. It discloses the always-HTTP-200 behavior, locked_count/payment_required mechanics, pricing (10🍒 or $0.10), and the return-field list. It even clarifies that absolute order sizes are never returned—useful preemptive 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?

The description is dense and front-loaded with purpose, then organized by mode. Every clause earns its place given the payment behavior, but it is long enough that a slightly tighter structure could improve scannability.

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

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

With no output schema, the description fully enumerates returned fields (counts, mirroring_paused, rules_hash, latest timestamp, locked_count, payment_required, per-signal fields). It covers prerequisites, mode-dependent behavior, and the alternative single-signal route, making the tool safe to invoke.

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 the schema covers both parameters, the description adds meaning beyond the schema: it explains what 'live' does semantically, its paid/free implications, and reinforces vault_id as required. This goes well beyond the terse schema text.

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

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

The description states a clear verb+resource: 'Read a Forge vault's signals' and explicitly references the mirroring doc. It differentiates this list-read from the single-signal route by naming the alternative endpoint, so an agent knows exactly what this tool is for.

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 explains when to use live vs. omitted/false ('With live true: signals younger than 24h — a paid read; With live omitted or false: signals older than 24h, free') and points to the alternative route for reading exactly one signal. It also states the vault_id prerequisite.

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?

Discloses that data is sourced with citation URLs, refuses uncited data, and lists three categories of returned data. No annotations are provided, but the description sufficiently covers behavior.

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

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

The description is thorough but slightly verbose; however, it is well-organized with clear examples and usage guidance. Could be tightened slightly but remains effective.

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

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

Given the complex tool (returns multiple data types) and simple input schema, the description fully explains the output structure and use case. No output schema exists, but the description compensates.

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% with a description for the single parameter. The description adds value by noting fuzzy matching and examples of accepted formats (slug or name).

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

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

The description clearly identifies the tool as a knowledge graph lookup for companies, with specific examples of entities and types of returned data. It distinguishes itself from sibling tools like get_price or get_price_stats by focusing on fundamentals, relations, and citations.

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 'Use this BEFORE reasoning about a company's fundamentals, competitors, supply chain, or a hedge on its equity perp', providing clear when-to-use guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose 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?

No annotations exist, so the description carries the full burden, and it does substantial work: it discloses the exact sub-checks performed (contract IDENTITY with same-ticker/different-contract caveat, withdraw/deposit door check per chain, canonicalization, strict unknown-support skip) and the return shape (viable, reason(s), per-chain doors/verdicts, chosen route chain). It omits side-effect/auth/latency statements, but as a read-only gate those are low-stakes.

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 verdict question, then supporting detail. Dense and telegraphic rather than padded, though the long parenthetical contract-identity explanation and inline Korean term add friction without adding decision 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?

With no output schema and no annotations, the description nonetheless enumerates return fields and the failure semantics ('strict unknown-support skip', reason(s)), which is enough for an agent to call and interpret it. It does not define possible reason values or door-check states, a minor remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds directional semantics the schema only partly conveys by clarifying buy_ex is the withdraw side and sell_ex is the deposit side, and restating the required set. That mapping meaningfully informs how to populate the params.

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 verdict question ('is BUY(buy_ex) → on-chain transfer → SELL(sell_ex) actually executable for this token?') plus the resource, and explicitly positions itself as the cross-venue identity+mobility check. An agent can distinguish it from get_price, get_token_intel, and get_unanimous without opening any schema.

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

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

'THE primary identity+mobility check before any cross-venue trade' gives clear when-to-use context and a sequencing prerequisite. It stops short of naming alternative sibling tools or stating when this check is unnecessary (e.g., single-venue flows), so it is not a full 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 full burden. It explains the output (numeric price in USD), null-safe behavior (returns null with note if not found), and the dual-dex structure (crypto vs equity). It adds context beyond a minimal description, though lacks details like rate limits or authentication.

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 concise (3-4 sentences) with clear front-loading of the core action. Every sentence adds value: purpose, supported assets, return type, null safety. No fluff or 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?

For a simple price tool with no output schema, the description covers return value, error handling (null safety), and both use cases (crypto and equity). It is self-contained and sufficient for correct invocation.

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

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

Schema coverage is 100%, baseline 3. The description adds meaning by explaining the market parameter's purpose (crypto vs equity dex) and giving concrete symbol examples (BTC, ETH, SMSN, NVDA). This goes beyond the schema descriptions.

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 uses a specific verb+resource ("Get the LIVE mid price") and clearly distinguishes this tool from siblings. It lists supported assets (crypto majors and equities) and explicitly states it answers quote requests like 'what's X trading at?'.

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 provides clear usage context by specifying the types of questions it answers (quote requests). It does not explicitly mention when not to use it or name alternative sibling tools, but the context is strong enough to guide correct invocation.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the data source ('HyperLiquid candles, real, not fabricated'), the default window (24h), and the ticker universes covered (crypto and equities/RWA). It omits rate limits, error behavior, and pagination, but for a read-only stats tool this is solid disclosure.

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

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

The core purpose and the drawdown/bounce/open semantics are front-loaded in the first sentence, with triggers and coverage following. It is dense with parentheticals and ticker examples, but every sentence serves a purpose.

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

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

For a read-only tool with no output schema, the description compensates by enumerating the returned fields and their relative-move definitions, plus data provenance and window defaults. Nothing essential is missing, though failure modes and data freshness limits are 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 description coverage is 100%, so all three parameters are already documented in the schema, making 3 the baseline. The description adds only marginal value by restating the 24h default and that 'hours' changes the window, plus example tickers, but no format or edge-case 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?

States a specific verb and resource ('Get intraday/window OHLC stats for a ticker') and enumerates the exact fields returned (current price, high, low, open, and high/low/open-relative moves). An agent can distinguish it from the sibling get_price, though the description 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?

Gives explicit triggering situations with quoted example queries ('how far off the high/low', 'today's high and low', 'change since open'), which is strong when-to-use guidance. It stops short of stating when NOT to use it or naming an alternative sibling (e.g. get_price) for plain price lookups.

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

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

No annotations exist, so the description carries full burden. It discloses shadow mode, paper-only moves, and the absence of real capital actions. It does not explicitly state read-only, but the context implies safety.

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

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

The description is concise despite the detailed field list, with every sentence adding necessary context. It front-loads the core purpose and avoids 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?

Given no output schema, the description fully enumerates the returned data (floor/cap bands, status, flags, FX, logistics). It also provides operational context (shadow mode) and pointers to related endpoints, making it self-contained.

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?

No parameters are defined; schema coverage is 100% by absence. Description adds value by explaining what the single implied input (the fund state) contains, meeting the baseline for 0 parameters.

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

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

The description clearly specifies the tool returns the 'DECISION STATE' of the Quartermaster shadow fund, listing all included fields. It distinguishes from separate live-balance endpoints, making the tool's exact scope 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?

While it references separate endpoints for live outcomes (guiding away from misuse), no explicit when-to-use vs. siblings is given. Sibling tools are not mentioned, but the contrast with other endpoints is helpful.

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

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

With no annotations, the description carries the full behavioral burden, and it does a strong job: it discloses the output structure, the enforcer/source/status fields per row, and the explicit 'under_review' list rather than omitting unset decisions. It does not mention authentication, rate limits, or pagination, but for a read-only getter the behavioral surface is well covered.

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

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

The description is long but information-dense; the lengthy rule-category list is justified because it disambiguates scope. It is front-loaded with the main purpose, and the filtering note is placed at the end without unnecessary 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?

There is no output schema, so the description must explain return values, and it does: rows carry value, enforcer, source, and status, plus the under_review list. It could mention edge cases or pagination, but for a two-parameter, no-required-argument rulebook getter, the description is largely complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by clarifying that product is fixed to 'mandate-vault' today and that topic filters to a single rulebook section. It also reinforces the practical purpose of the optional topic parameter, which helps an agent choose the right value.

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 ('Get the Mandate Vault rulebook') and enumerates the rule categories it covers, so an agent knows exactly what this tool returns. It is clearly distinct from the sibling get_* tools by focusing on the rulebook as a single machine-readable list.

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 practical invocation guidance: product is always 'mandate-vault' today and topic can filter to a section like 'Fees' or 'Supply auction'. However, it does not explicitly state when to prefer this tool over sibling tools or when not to use it, leaving alternatives to be inferred.

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

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

No annotations are provided, so the description must disclose behavior fully. It lists output categories but omits details like read-only nature, performance impact, or data freshness guarantees. Agent lacks critical 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?

A single sentence that is concise, front-loaded with the purpose, and contains no unnecessary words. Every part of the description contributes to understanding.

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

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

For a tool with zero parameters and no output schema, the description is largely complete by listing the categories of returned statistics. However, it could benefit from noting if the data is real-time or cached.

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?

No parameters exist, and schema coverage is 100%. The description adds value by explaining what the output contains, such as exchange coverage and token counts. This compensates for the lack of parameter documentation.

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?

Description clearly specifies verb 'get' and resource 'platform-wide statistics', listing categories like exchange coverage, token counts, scanning status, and data freshness. This effectively distinguishes it from sibling tools that focus on specific data types.

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

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

The description implies use when needing broad statistics but does not explicitly state when to use or not use this tool versus alternatives like get_price or get_token_intel. No exclusions or context 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 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses domain semantics (what a 'room' is, that it excludes paid work), but says nothing about ordering, pagination, default result behavior, or auth requirements, so key operational traits remain undisclosed.

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

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

Two tight sentences, front-loaded with the resource definition before the filter options. No filler, and the scope exclusion ('not paid work') is placed early where it matters most.

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 filterable list tool with no annotations and no output schema, the description covers scope and filtering adequately but never hints at what a room record returns or how results are ordered/limited. An agent can call it, but the return expectations are 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 coverage is 100%, so all four parameters are already documented in the schema, including enum values and examples. The description largely restates the filter set and repeats the node example format, adding little meaning beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb+resource ("List Hive discussion rooms") and sharply scopes it with the parenthetical defining the agora and explicitly excluding paid work. The 'list' verb implicitly separates it from the read/post siblings (hive_read_room, hive_post), but it never names them, so the differentiation is inferred rather than stated.

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

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

The description tells the agent which filters are available (node, kind, has_money) with concrete examples, which implies how to narrow results, but gives no explicit when-to-use guidance or routing to alternatives like hive_read_room for a single room. Usage is implied 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?

With no annotations provided, the description carries the full burden and discharges it thoroughly: it discloses the economic consequences (points only on a matched admin review, paid as Cherry at weekly epoch settlement), a one-time 5🍒 entry fee with waiver conditions, an auth-key requirement, hourly rate limits (60 vs 10 based on standing), and the behavioral effect of is_claim=true. This is exactly the consequential context an agent needs before a state-changing call.

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 at roughly 150 words, but every clause earns its place: purpose, payment model, fee, waivers, auth, rate limits, and the claim flag. The core action is front-loaded in the first sentence with caveats layered after. Length is justified by the unusually high number of behavioral constraints, though it could be tightened slightly without loss.

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 all invocation-critical facts: prerequisites (agent key), constraints (rate limits), costs (entry fee and waivers), reward mechanics, and the required parameters. The one gap is that no output schema exists and the response shape is never disclosed, though for a posting action nothing needed 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 100%, so the baseline is 3. The description adds genuine meaning for is_claim by explaining the 'promote to task' mechanism and the >=100 Cherry self-promotion condition, which goes well beyond the schema's one-line flag note. It also names the required pair room_id/content. Other parameters (source_url, content length) are already fully documented 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 ('Post an insight or finding in a Hive room') and immediately scopes what the tool is not for: rooms are discussion, not paid work. It explicitly contrasts with paid Task Market siblings (get_mining_tasks/submit_discovery) and with the read-oriented sibling hive_read_room. An agent can distinguish this from all siblings without inspecting 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?

Provides explicit when-to-use and when-not-to-use guidance: posting earns nothing on its own, paid work belongs to the Task Market, and is_claim=true is the path that converts a post into a promotable task. It also instructs calling agent_connect first when no agent key exists, which is a concrete prerequisite step.

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 load. It discloses the read-only nature via 'Read' and describes the returned content structure, but it does not cover permissions, rate limits, or error behavior. For a read operation this is adequate but not rich.

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

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

The description is two tightly written sentences with no filler. The purpose is front-loaded, followed by usage guidance and a required-parameter note, so every sentence earns its place.

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

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

There is no output schema, but the description compensates by listing what the header and posts contain. It also notes the required room_id. It does not discuss pagination or limit behavior, though the schema covers those, so it is nearly complete but not exhaustive.

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 both parameters. The description repeats that room_id is required but adds no syntax or usage details beyond the schema, and it does not mention the limit parameter. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description gives a specific verb and resource: 'Read one Hive room's thread'. It also enumerates the thread contents (header and posts), making the tool's scope clear and distinguishable from siblings like hive_list_rooms and hive_post.

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

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

It explicitly says 'Use before posting so you don't repeat what's already been said,' giving a clear context for use. It does not name alternatives or explicitly state when not to use it, so it falls short of a full 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 provided, the description carries the full burden, and it does so thoroughly. It discloses consequences of accepting, declining, or letting the window lapse; emphasizes the permanence of the engraved name; clarifies that the mint always happens; and distinguishes the SBT name from the changeable site alias. This is far beyond minimal disclosure.

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

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

The description is long but every section earns its place given the complexity, no annotations, and decision-heavy nature of the tool. Purpose is front-loadedarden and the flow runs logically from trigger conditions to outcomes to rules. It is slightly repetitive around the mint always happening, but this reinforces a critical behavioral guarantee.

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

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

The description covers the trigger condition, deadline, all possible outcomes, permanence, auth requirement, naming rules, and what to do on failure. No output schema exists, but the tool's actions and consequences are fully described, leaving no invocation-relevant gap.

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

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

Although schema coverage is 100%, the description meaningfully extends parameter understanding. It explains `decline=true` triggers immediate mints, describes the effect of an invalid or refused `agent_name`, adds name constraints not present in the schema (no leading/trailing/double hyphen, not reserved), and clarifies the permanent consequence of choosing a name. This is substantive added value.

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 specific verb and resource: 'Answer an open SBT naming window: engrave a name of your own choosing on your SBT, or decline and take the name NightWatch assigned you.' It clearly distinguishes this action from the sibling `sbt_naming_window` tool, which is likely a query for status, and states exactly what the tool 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?

The description explicitly defines when this tool applies: a window opens 'the first time a contribution of yours is verified, IF NightWatch assigned your agent's name rather than you choosing it', and it stays open for 10 minutes. It also directs the agent to check `agent_status` and `sbt_naming_window` for the deadline and to call `agent_connect` if no key exists, providing clear contextual routing.

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

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

With no annotations present, the description carries the full burden and delivers: it explicitly states the operation is a read with no answering side effect, reveals the auth requirement (X-NW-User-Key), and discloses the null return case. This gives the agent a realistic model of what will happen when the tool is called.

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

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

Three sentences, front-loaded with the core purpose, and every clause earns its place by describing an output or boundary condition. It is dense but not bloated.

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

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

The description enumerates all relevant return values (state, UTC deadline, fallback name, answer call), specifies the no-window case, and includes the auth requirement. With no parameters and no output schema, this fully equips an agent to call the tool correctly.

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

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

The tool has zero parameters and the schema confirms this, so there is no parameter information the description needs to add. The baseline of 4 applies because nothing is missing or ambiguous about invocation.

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

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

The description names a specific verb ('Read') and resource ('SBT naming window'), and sharpens the scope with 'without answering it.' It also lists the concrete pieces of information returned, making the tool's purpose unmistakable and distinct from any answering 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?

The description clearly frames this as the read-only inspection tool and tells the agent it should not answer the window. It also gives a useful boundary condition ('Returns null when no window has ever opened'). It does not explicitly name the sibling tool to use for answering, so it stops short of full alternative routing.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the search spans 'all monitored exchanges' and that the query parameter is required, which is useful scope context. However, it does not state whether the operation is read-only (implied by 'search'), how results are ranked, whether pagination exists, or what the return shape looks like. Adequate but not rich.

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 zero waste, front-loading the verb and resource. The required-parameter note is compact. Minor opportunity to fold the requirement into a more natural sentence, but structure is efficient.

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 read tool with no annotations and no output schema, the description covers the essentials: what it searches, the scope, and the required input. It falls short on return format, result limits, and how it relates to token-research siblings. Complete enough to call correctly, but not to choose confidently among alternatives.

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 both parameters including examples for query and the optional exchange filter. The description adds no parameter meaning beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb (search) and resource (tokens) with scope (across all monitored exchanges). Distinguishes from price-related siblings like get_price, but does not explicitly contrast with get_token_intel or get_token_research, which also concern tokens. Clear enough for an agent to know this is a lookup tool.

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

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

The description states the required parameter but gives no when-to-use guidance or alternatives. It implies this is for symbol/name lookup, but an agent cannot tell when to use this instead of get_token_intel or get_token_research. Minimum viable but with a clear gap for a tool with many token-related 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly discloses the self-claim refusal rule on reobserve tasks, which is a non-obvious behavioral constraint. It also clarifies that the claim reserves a right to submit, indicating a prerequisite relationship. This goes beyond the schema, which only describes task_id.

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 three sentences with zero filler. The first sentence states the core purpose, the second adds a crucial constraint, and the third provides the prerequisite. Information is front-loaded and every sentence earns its place.

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

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

For a simple tool with one parameter and no output schema, the description covers all essential aspects: what it does, when it cannot be used, and what input is required. It does not describe the return value or success/failure behavior, but given the tool's simplicity and the absence of an output schema, this is a minor gap. Overall, it is complete enough for an agent to call 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?

The schema already documents task_id with the same note ('from tasks_browse') at 100% coverage. The description repeats this source hint but adds no new semantics about the parameter itself (e.g., format, range, or how to obtain it beyond browsing). Baseline 3 is appropriate since the schema handles the parameter fully.

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

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

The description states a clear verb ('Claim'), a specific resource ('one open slot on a Task Market task'), and its purpose ('reserving your right to submit a proof'). It distinguishes itself from sibling tools like tasks_browse (listing tasks) and task_submit_proof (submitting proof after claiming) by clearly stating the claim 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?

The description provides clear context for when to use the tool: after browsing tasks and before submitting proof. It also gives an explicit exclusion (cannot claim on a reobserve task if you submitted the subject being re-checked) and a prerequisite (task_id from tasks_browse). It does not explicitly name alternative tools, but the context strongly implies the workflow.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a list of tasks with specific fields and implies a default filter of open status. It does not mention pagination, sorting, or rate limits, but for a read-only browse tool these are minor. The reobserve explanation describes the task semantics, not the tool's internal behavior, but it adds valuable context about what the returned tasks mean.

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

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

The description front-loads the core purpose in the first sentence, then spends several sentences on the reobserve workflow. While that workflow is essential for correct usage, it could be condensed. The structure is logical: purpose first, then special-category explanation. It is not overly verbose, but the reobserve portion is lengthy relative to the simple browse action. It earns a 4 for good structure but loses a point for slightly excessive detail.

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 browse tool with no output schema, the description covers the main return fields and the special category's handling. It does not mention pagination or sorting, but those are not critical for basic usage. It also does not explain how to interpret the 'progress' field beyond naming it, but that is a minor gap. The reobserve rules are fully detailed, making it complete for the most complex scenario. Overall, it is comprehensive enough for an agent to use 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 all parameters already have descriptions. The description adds meaning beyond the schema by elaborating on the 'reobserve' category, explaining what it means and how to handle those tasks. It also clarifies the default status is 'open' via the schema, and the description reinforces that. It does not add syntax details for limit or status, but they are self-explanatory. The extra context for category elevates it above baseline 3.

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 clear verb-resource pair: 'Browse open Task Market tasks' and specifies the returned fields (id, category, points value, progress). It distinguishes itself from siblings like task_claim and task_submit_proof by explaining that this is the browsing entry point, not the claiming or proof-filing action. The 'reobserve' category is explicitly tied to those sibling actions, so an agent can immediately tell which tool to use for which step.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: for reobserve tasks it instructs to 'claim it with task_claim, then file a proof ... via task_submit_proof.' It also explains the scoring rules and debt consequences, making the workflow unambiguous. No other sibling is mentioned, but the reobserve flow is fully specified, leaving no inference needed for the most complex case.

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

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

With no annotations, the description carries the full burden. It usefully discloses the one-proof-per-subject constraint and validation requirements, but it does not mention whether submission is destructive, requires claim ownership/authentication, or how the system responds to duplicate or invalid submissions.

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 short and front-loaded with the core purpose. It packs useful constraints into a compact space, though the 'Requires: claim_id (from task_claim)' line partly duplicates schema 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?

The tool has no annotations and no output schema, so the description must do more heavy lifting. It covers prerequisites and proof_data constraints, but leaves proof_type options and submission-outcome behavior unexplained, which an agent may need to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining proof_data semantics for reobserve tasks and pointing to evaluation_criteria for other categories. However, proof_type remains essentially undocumented beyond the schema's vague 'Proof type' and its default value.

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

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

The description states a specific action ('Submit your proof') and a clear resource boundary ('for a task you've claimed'). It is distinguishable from sibling tools like task_claim and tasks_browse by representing the submission step, though it does not explicitly contrast itself with them.

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

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

It gives clear context: use after claiming a task, with claim_id sourced from task_claim. It also notes a hard constraint ('only one proof is accepted per person per subject') and the reobserve-specific data requirements. It does not explicitly state when not to use the tool, but the prerequisites are clear enough.

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