n0brains

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

Despite no annotations, the description discloses that the tool returns a grade (A..F) with flags, supporting factors, and falsifiers, that grades are logged and resolved at horizon, and that it is analytical not advice. This adds useful behavioral context beyond the input schema.

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

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

The description is concise (5 sentences), front-loaded with purpose, then parameter list, output description, and a caveat. No redundant information, every sentence adds 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?

Given the tool's complexity (7 parameters, no output schema, no annotations), the description covers purpose, required and optional inputs, output format (grade and flags), and behavioral notes (logging, calibration, non-advice). It could mention return type or edge cases, but overall it is sufficiently complete for an agent to invoke 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 0%, but the description lists all parameters and hints at their purpose (e.g., 'optionally entry, stop, target, leverage, horizon_hours'). It does not provide detailed constraints or formats, but it minimally compensates for the missing 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 clearly states it performs a 'graded pre-trade conditions assessment' for a proposed trade, specifying required inputs (asset, side) and optional parameters. This distinguishes it from sibling tools like get_trade_plan or rank_trades, which focus on planning or ranking rather than assessment.

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 tells the agent to provide asset and side, optionally entry, stop, target, leverage, and horizon_hours. While it doesn't say when not to use or list alternatives, the context is clear enough for 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?

The description discloses the specific filtering criteria (score, confidence, age) and mentions that signals with calibration_inverted_in_cell=true are skipped. Since no annotations are provided, the description carries the full burden, and it reveals relevant behavioral traits, though it does not cover mutability 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?

Two concise sentences. The first sentence front-loads the core purpose, and the second sentence adds overridability and an exclusion note. No extraneous words.

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

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

Given the tool has 5 parameters, an output schema, and several siblings, the description provides adequate context for a filtered-list query tool. It explains filtering criteria and one exclusion rule. It could mention the output format or pagination, but the output schema might cover that.

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

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

Schema description coverage is 0%, so the description must add meaning. It explains the purpose of min_score, min_confidence, and max_age_min (override filters), but does not describe asset or signal_type. Only 3 of 5 parameters receive explanation, so it partially compensates but leaves gaps.

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 it returns 'active signals that pass the production trade-gate' with specific thresholds (score, confidence, age). It uses a specific verb ('get') and resource ('actionable signals'), and distinguishes from siblings by referencing the trade-gate criteria.

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 default thresholds and indicates that parameters can be overridden for stricter/looser filters. However, it does not explicitly state when to use this tool versus alternatives like get_signal or get_signals_since, nor does it mention when not to use it.

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

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

With no annotations, the description carries full burden. It discloses that cells are those with inverse_flagged=true, that signals in these cells get calibration_inverted_in_cell=true and confidence nulled in customer-facing serialization. This is transparent about behavioral impact.

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 with three sentences that are front-loaded: the first sentence states the core action. No redundant or unnecessary 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 zero parameters, the presence of an output schema, and the description explaining the data source, condition, and implications (inversion and nulling confidence), the description is complete for the tool's purpose.

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?

There are zero parameters, so no parameter info needed. Schema description coverage is 100%. Baseline score of 4 is appropriate as the description adds no parameter details but none are required.

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 cells from cell_stats.json with inverse_flagged=true, explaining the condition and the meaning of these cells (signal_type × direction × regime buckets with low empirical win-rate). It is specific and distinguishes from other get_* tools in the sibling 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?

No guidance is provided on when to use this tool versus alternatives. The description explains what it returns but does not specify scenarios or exclusions.

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

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

Given no annotations, description fully discloses behavioral traits: intel-only, informational tradeable badge, non-crypto not auto-traded, status accruing condition. No contradictions.

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?

Description is front-loaded with main purpose and valuable details. Slightly dense but each sentence adds necessary information. Could be trimmed slightly without losing clarity.

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?

Despite lacking output schema and having low schema coverage, the description fully compensates by explaining the kind of data returned (scoreboard), baseline calculation, and status conditions. Also directs to crypto sibling.

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 0% schema description coverage, the description adds crucial meaning to the single parameter 'asset_class' by listing acceptable values: stock, index, metal, commodity.

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 states it is a per-non-crypto-asset-class forward-return scoreboard, listing specific asset classes (stock, index, metal, commodity) and referencing the REST endpoint. Distinct from sibling tool get_performance which is for crypto.

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 tells when to use alternative (crypto board: use get_performance or REST /proof). Also explains limitations: non-crypto is not auto-traded yet, status=accruing until min sample reached.

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, so description bears full burden. It discloses the time window (7d), data frequency (15m log returns), and the inclusion of peer lists. The caution about causation is valuable. However, it does not explicitly state it is read-only or safe, but the nature implies it.

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

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

Two sentences deliver all key information without redundancy. No wasted words.

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

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

The description covers inputs, computation details, and output highlights. Since an output schema exists, return value details are not needed. It sufficiently defines the tool's behavior for an agent.

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

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

Schema coverage is 0%, meaning the parameter 'coin' lacks description in the schema. The description implies coin is a cryptocurrency identifier, but does not provide format, examples, or enumeration. Partial compensation via context.

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 correlation and beta of a coin to BTC and ETH over a specific window, plus peers. The verb 'return' and specific resources (correlation, beta, peers) make it unambiguous. The addition of 'correlation is not causation' adds nuance.

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

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

No explicit guidance on when to use this tool versus alternatives. The mention of 'Same data as REST /correlation/{coin}' hints at equivalence but does not provide when-to-use or when-not-to-use 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?

Since no annotations are provided, the description carries full burden. It states the tool is descriptive and not advice, and mentions ETF flow is non-predictive. But it omits typical behavioral traits like auth requirements, rate limits, or whether it modifies data.

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 with some redundancy (e.g., 'crypto rotation, crypto-vs-tradfi OI split'). Front-loaded but could be more concise.

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 and no parameters, the description provides a good overview of what the tool returns and its non-predictiveness. It covers the essential aspects for an agent to invoke 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?

With 0 parameters, the schema coverage is 100%. The description does not need to add parameter info, and it doesn't miss anything. Baseline for 0 params is 4.

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

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

Description clearly states it covers crypto rotation, crypto-vs-tradfi OI split, and institutional posture via ETF flow, COT, 13F. It differentiates from siblings like get_rotation or get_positioning by specifying the scope (cross-asset flows).

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 wanting to know fund flows ('where are funds going'), and warns against reliance on ETF flow for predictions. However, it lacks explicit when-not to use and does not mention alternatives among the many sibling tools.

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

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

With no annotations, the description carries the full burden. It discloses the accruing status (~60-90 days) and that results are candidates, not advice. However, it doesn't address data freshness, mutability, or other behavioral aspects beyond the time horizon.

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?

At two sentences, it is relatively concise but packed with niche terminology (e.g., 'shadow ledger', 'both-halves') which harms readability. The structure front-loads the purpose but could be more streamlined.

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 absence of parameters and output schema, the description should fully explain the output. It mentions ranking by measured edge and surfacing patterns, but doesn't elaborate on the output format, data types, or how it relates to sibling tools. It's adequate but not complete.

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

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

No parameters exist, so the schema is fully covered (100%). The description adds value by explaining what the tool does without needing parameter details. Baseline 4 is appropriate as the description is informative for a parameterless tool.

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 discovers emergent edge patterns by mining shadow ledger data against returns. It uses specific terms like 'corroboration class-combinations' and 'honesty-gated' which distinguish it from sibling tools, though the jargon may reduce clarity for some agents.

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

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

No explicit guidance on when to use this tool versus alternatives. The disclaimer 'Candidate, not advice' provides some context but no usage conditions, prerequisites, or comparative guidance with 32 sibling tools.

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

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

No annotations are provided, so the description bears full burden. It discloses that the tool returns historical and upcoming data with consensus, previous, actual, and surprise values. It implies a read-only data retrieval operation. It could explicitly state it's read-only and mention any rate limits, but given the context, this is adequate.

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

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

The description is concise and well-structured. The first sentence defines the purpose ('Scheduled macro + earnings calendar'), the second provides details and examples, the third lists the parameters, and the fourth gives usage context. Every sentence adds value, and there is no redundancy or 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?

Given the tool's complexity (3 parameters, no output schema, no nested objects), the description covers the key aspects: what data is returned, parameter constraints, and how it relates to other tools. It lacks explicit details on output format or pagination, but the mention of 'consensus/previous, and actual + surprise once printed' gives a reasonable idea. A lower score would require more significant 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?

The input schema has 0% description coverage. The description compensates by listing the three parameters with ranges: days_back (0-90, default 7), days_ahead (0-60, default 14), and event_class ('macro'|'earnings', optional). This adds meaning not captured in the schema, which only defines types and defaults. The schema doesn't restrict event_class to specific values, so the description provides helpful constraints.

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 name and description clearly state it's an economic calendar for macro releases and earnings. It uses specific examples (CPI, NFP, NVDA) and positions itself as the 'knows WHEN' feed, distinguishing it from other tools in the sibling list that focus on signals, sentiment, or trading decisions.

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 says 'Context for timing/regime, not a direction call,' which tells the agent when to use it (for timing context) and hints at what not to use it for (direction calls). It also mentions 'Same data as REST /calendar,' providing an alternative endpoint. However, it doesn't explicitly exclude other siblings or provide when-not-to-use scenarios.

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

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

The description discloses important behavioral traits: history is null until data accrues (the library never manufactures data), and it is not a direction call. Since no annotations are provided, this description carries the full burden and adequately informs the agent about the tool's data fidelity and non-predictive nature.

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 fairly concise (2-3 sentences) but contains cryptic phrasing like 'the library earns its conditionals'. The structure is acceptable but could be more streamlined and front-loaded with the core functionality.

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 complexity of the tool (event-study library with historical distributions), the description covers important behavioral aspects but omits details about the return structure. The reference to the REST endpoint provides some consistency, but more explicit output guidance would improve completeness.

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 0% schema description coverage and only one parameter (days_ahead, default 14), the description fails to explicitly explain the parameter's role. While 'upcoming' implies a time horizon, the description does not connect the parameter to controlling the look-ahead period, leaving the agent to infer from the 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 states the tool provides upcoming macro releases and earnings with historical reaction distributions. It distinguishes itself by mentioning 'Not a direction call' and referencing the REST endpoint, but does not explicitly differentiate from siblings like get_macro or get_economic_calendar.

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 lacks guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or situations where another sibling tool would be more appropriate. The only usage-related note is that history is null until data accrues, which is more about behavior.

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 fully convey behavioral traits. It explains it returns daily and weekly timeframes plus a plain-language read, and states it's equivalent to a REST endpoint, implying idempotency. However, it does not disclose error handling (e.g., invalid coin format) or any side effects, leaving some gaps for an agent.

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 efficient, listing indicators, timeframes, and usage guidance in a few sentences. It front-loads the purpose and includes practical details without unnecessary fluff.

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 tool's complexity (multiple indicators, multiple timeframes, and a natural language read) and the presence of an output schema, the description is complete. It covers what the tool does, what data it returns (daily+weekly, plain-language), and how it relates to other endpoints and tools.

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

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

Schema coverage is 0%, but the description compensates by giving example coin values ('BTC', 'ETH', 'SOL', 'XRP') and clarifying that these are examples. This adds meaning beyond the schema's bare 'string' type, though it doesn't specify case sensitivity or validation rules.

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 it provides technical indicators for a coin, listing specific indicators (RSI, MACD, SMA/EMA, Stochastic, Fibonacci) and timeframes (daily, weekly). It also distinguishes from sibling tools by mentioning 'same data as REST /indicators/{coin}' and explicitly suggests using it with get_levels.

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 explicit usage guidance: 'Use for momentum + Fib confluence with get_levels.' This tells the agent when to use this tool and identifies a complementary tool (get_levels). It lacks an explicit when-not clause, but the context is clear enough.

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 full burden. It only states it 'reads from' sources, implying a read-only operation, but does not disclose behavioral traits like side effects, data freshness, rate limits, or required permissions. The output structure is mentioned, but the transparency is limited.

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

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

The description is two sentences long, front-loaded with the core purpose, and adds details in the second sentence. Every part is necessary and no words are wasted. It is optimally concise for an AI agent to parse quickly.

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

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

Given the tool has only one parameter and an output schema exists (though not shown), the description covers key aspects: what the tool does, what it returns, and its data source. It could optionally mention data freshness or that the output schema defines exact fields, but overall it is sufficiently complete.

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

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

Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description gives examples of coin values ('BTC', 'ETH', 'SOL') but does not add meaning about formatting, constraints, or valid values beyond the example list. It is a minimal addition.

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 states it provides support/resistance levels for a coin, lists specific output fields (nearest_resistance, nearest_support, top-5 lists), and mentions data sources (levels_engine + Hyperliquid mids). It distinguishes from siblings by focusing on levels, which is unique among the sibling tools like get_sentiment or get_macro.

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 for technical analysis of a coin's price levels but does not explicitly state when to use vs. alternatives, nor does it provide when-not-to-use guidance. It mentions the tool returns the same data as a REST endpoint, which gives some context, but lacks explicit usage conditions.

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, so description carries full burden. It clearly states the data is an estimate, not actual per-account data, uses aggregate open interest and standard leverage tiers, is uncalibrated, and lists specific outputs (nearest zones, top zones). Also references disclaimer/assumptions fields.

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

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

Description is moderately long but each sentence adds value. Front-loaded with core purpose and key limitations. Could be slightly more concise, but no fluff.

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 single parameter and existing output schema, the description covers return values (nearest dense long-liq below price, nearest short-liq above, top zones by estimated notional) and mentions the disclaimer. Complete and informative for the tool's complexity.

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

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

Only parameter 'coin' has 0% schema description coverage. Description adds meaning by giving examples ('BTC', 'ETH') and explaining it expects a coin symbol, which goes beyond the schema type 'string'.

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?

Explicitly states it returns 'estimated liquidation-cluster zones for a coin', with specific verb 'get' and resource 'liquidation map'. Distinguishes from siblings by clarifying it's an estimate based on aggregate data, not actual per-account data, and mentions it's the same data as a REST endpoint.

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?

Implies usage for estimating liquidation zones, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or direct comparisons to sibling tools 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 burden. It states 'Descriptive, not advice' (non-actionable), 'Mirrors REST /liquidity' (source transparency), and lists data components. However, it does not explicitly confirm read-only or discuss side effects, though zero parameters imply a safe query.

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 (two sentences) and front-loaded with key items. However, the first sentence is dense with jargon (e.g., 'stablecoin dry-powder'), which may reduce clarity for some agents. Still, every word 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?

Given zero parameters and no output schema, the description sufficiently explains the tool's purpose and content (list of components). It adds REST mirroring context. While it could mention return format or limitations, the simplicity of the tool makes this adequate.

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, so schema coverage is 100% (trivially). The description does not need to add parameter details. Baseline 4 applies as the description provides context about what data is returned (components) beyond the empty 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 defines the tool as a net cross-asset liquidity map with specific components (Fed net liquidity, stablecoin dry-powder, total perp OI, etc.). It answers 'where is liquidity?' and differentiates from sibling 'get_liquidation_map' by focusing on broad liquidity rather than liquidation specifics.

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 the tool is used to find liquidity positions but does not provide explicit when-to-use or when-not-to-use guidance. It lacks comparison with siblings like 'get_liquidation_map' or 'get_cross_asset_flows', leaving the agent to 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 burden. It discloses that the tool applies an honesty overlay marking uncalibrated fields and insufficient-data flags. However, it does not explicitly state whether the operation is read-only, nor does it mention rate limits or authentication requirements. While helpful, it leaves some behavioral gaps.

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

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

The description is extremely concise with two sentences that front-load the key purpose and output characteristics. Every sentence adds value with no wasted words.

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

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

Given the tool has zero parameters and an output schema exists, the description adequately explains the return content (bias, conviction, risks, flags). It is complete for a snapshot tool without needing to document return format.

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 in the input schema, so the baseline is 4. The description does not need to add parameter information. It effectively conveys what the tool returns without needing to explain inputs.

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 states it provides current macro bias, including regime, BTC/ETH bias with conviction, and calendar risks. It also mentions honesty overlay with uncalibrated fields and insufficient-data flags, distinguishing it from related sibling tools like get_macro_aligned_signals or get_market_regime.

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 notes it mirrors a REST snapshot, giving implied context for use, but does not explicitly state when to use this tool versus alternatives such as get_macro_aligned_signals or get_market_regime. No when-not or exclusion criteria 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?

No annotations provided, so description carries full burden. It discloses active status, exclusion of macro types, and confidence boost factor (x1.12 vs x0.88). However, lacks details on pagination, rate limits, or authorization.

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 substantive sentences plus a clarifying phrase about exclusions. Front-loaded with key details, no wasted words.

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

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

Given an output schema exists, the description adequately covers input behavior and filtering logic. Missing details on output structure, errors, or edge cases, but overall sufficient for a well-scoped 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?

With 0% schema description coverage, the description must compensate. It mentions 'Optional asset filter' and implicitly limit (default 50), but does not explain asset format, acceptable values, or limit behavior. Adds some value but incomplete.

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 it returns active signals aligned with macro bias, specifies the conviction threshold (≥0.6), and excludes macro/macro_pulse types. This specificity distinguishes it from siblings like list_signals or get_signals_since.

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 context by contrasting with CONFLICTS (dampening) and mentioning internal pipeline usage, but lacks explicit when-to-use or when-not-to-use guidance. The sibling set includes many signal tools, so alternative guidance would help.

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 fully discloses behavior: it runs k-NN over cross-asset state, outputs historical performance statistics, parameter k range (3-25, default 12), and emphasizes it is non-predictive. It also mentions 'episode-separated' and the cross-asset inputs, covering all relevant aspects.

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

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

The description is a single, dense sentence that packs method, inputs, outputs, and constraints without redundancy. It is front-loaded with the core purpose, making it immediately actionable.

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?

Despite no output schema, the description adequately explains what the tool returns: per-analog and aggregate statistics (median, quartiles, hit-rate) for SPX/NDX/BTC over 1d/5d. Given one parameter and predictable output nature, it provides sufficient context for correct invocation and interpretation.

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 sole parameter k is enriched beyond the schema: description provides valid range (3-25), default (12), and meaning (number of analogs). Schema only declares integer|null and default=12. The description adds critical usage context for the agent.

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 a unique purpose: finding nearest historical market-state analogs using k-NN over cross-asset state. It names specific assets and metrics (SPX/NDX momentum, VIX level+term structure, DXY, yield curve), and details output (median, quartiles, hit-rate for SPX/NDX/BTC over 1d/5d). This differentiates it from sibling tools like get_market_regime or get_signal.

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 it should be used as 'conditioning context, NOT a prediction', which is explicit guidance on interpretation. It also notes it provides the same data as REST /analogs, aiding familiarity. However, it lacks explicit when-not-to-use or comparison to specific sibling tools, which would improve clarity.

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, so description must cover behavior. It reveals the data source (internal function) and notes it is identical to a REST endpoint, implying a read-only operation. However, it does not disclose authorization needs, rate limits, or other 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?

Two sentences, front-loaded with the core purpose. Every sentence adds value (data content, source, and relationship to REST API). No wasted words.

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

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

Given zero parameters and presence of an output schema, the description adequately explains what the tool returns and the data source. Could mention frequency or session types, but overall 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?

Input schema has no parameters (100% coverage), so description adds meaning by specifying the returned assets (BTC/ETH/SOL) and data type (prices from TradFi sessions). Baseline for zero parameters is 4; the description meets this.

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?

Explicitly states it provides 'Latest TradFi market open prices for BTC/ETH/SOL across sessions', clearly distinguishing from sibling tools like get_market_analogs which cover different data. The verb 'get' is implicit but the resource and scope are specific.

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?

Implies usage for retrieving market open prices but provides no explicit when-to-use or when-not-to-use guidance compared to the many sibling tools. No alternatives mentioned.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is descriptive, not predictive ('uncalibrated'), and explicitly states it is not financial advice. This adds context about the tool's limitations and non-actionable nature.

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 extremely concise: three sentences that front-load the key output (risk-on/off/squeeze) and efficiently convey the tool's purpose, methodology, and limitations. No extraneous words.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description provides a complete picture: what it does (risk appetite read), how it works (blend of multiple factors), and its limitations (descriptive, not advice). This is sufficient for the agent to understand and invoke it correctly.

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

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

The tool has zero parameters, so the description need not add parameter information. The baseline score for 0 params is 4, and the description adequately describes the tool's purpose without needing param 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?

The description clearly identifies the tool as a 'Market-wide risk-appetite read' that outputs risk-on/off/squeeze, derived from a blend of macro, breadth, funding, and vol. It answers a specific question ('do conditions favor risk right now?') and distinguishes itself from siblings by detailing its composite nature.

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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions that it mirrors the REST /regime endpoint and is 'descriptive, uncalibrated, not financial advice,' implying a simple read, but lacks direct comparisons to the 30+ sibling tools.

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

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

No annotations provided, so description must cover behavioral aspects. It explains the data scope (n0brains sources, not market-wide) and output format (leaderboard with velocity). However, it does not disclose data freshness, rate limits, or behavior under no-data conditions. Adequate but could be more transparent.

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?

Description is relatively concise at about four sentences. It front-loads 'Mindshare leaderboard' and then explains key features. Some redundancy ('Same data as REST /mindshare') could be omitted, but overall 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?

Given no parameters and an output schema existing, description covers the main output concepts: ranked assets, velocity, and the edge. It lacks specifics on the time window and computation method, but provides sufficient context for understanding what the tool 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?

Tool has zero parameters, so schema coverage is 100% trivially. The description adds meaning by explaining what the output contains (ranked assets, velocity categories) and the concept of attention acceleration, enriching understanding beyond the empty 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?

Description clearly defines tool as a 'Mindshare leaderboard' showing ranked attention shares with velocity categories. It specifies the data source (n0brains' sources) and differentiates from a market-wide social-firehose. The name and sibling get_mindshare_coin imply per-coin vs aggregated leaderboard, so purpose is distinct and unambiguous.

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

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

Description mentions the 'edge' of attention accelerating before price moves, implying usage for detecting momentum. It explicitly states it's not a market-wide absolute, providing a context for when not to use. However, no direct comparison to siblings or explicit when-not-to-use is given, missing some 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 adequately discloses the output contents (attention share %, rank, velocity, and stability classification) and the comparative nature. It does not discuss side effects, authentication, or rate limits, but for a read-only data retrieval tool this is acceptable.

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

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

The description is a two-sentence, efficient summary with no filler. It front-loads the key output fields and provides a reference to the REST endpoint.

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 tool's simplicity (one parameter, no nesting, and presence of an output schema), the description is mostly complete. It explains what data is returned and the comparative aspect, though it could briefly note that the output schema details the fields.

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 single required parameter 'coin' is not described in the schema (0% coverage), and the description only implies it identifies a coin without specifying accepted formats (e.g., ticker symbol, name, or ID). This leaves ambiguity for the agent.

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 retrieves a single coin's mindshare, including attention share %, rank, velocity, and status relative to the prior window. It also references the equivalent REST endpoint, making the resource clear and distinct from sibling tools like 'get_mindshare'.

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 for a specific coin, but does not explicitly state when to choose this over siblings like 'get_mindshare' or other tools. No alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries full burden. It explains the output meaning (e.g., skew interpretation, contango) but does not disclose side effects, authentication needs, rate limits, or error handling. The 'public Deribit data' hint is useful but insufficient.

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?

Four sentences, front-loaded with purpose. The REST endpoint reference adds some noise but is brief. Overall efficient and well-structured for the complexity.

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

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

Given an output schema exists (not shown), the description doesn't need full return details. It covers key derived metrics and their interpretation. Missing some explanation of max-pain and OI ratio, but overall adequate for a simple parameter tool.

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

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

Single parameter 'coin' has 0% schema description coverage, but the description compensates fully by specifying allowed values (BTC or ETH) and implying the parameter selects the coin for analytics. This adds critical meaning beyond the raw 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?

Description clearly specifies the tool provides options analytics for BTC or ETH, listing specific metrics and data source. It distinguishes from siblings by being unique among the listed tools, which are mostly about signals, indicators, or macro.

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

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

No explicit when-to-use or when-not-to-use guidance. It does note the tool is 'descriptive, not prediction', which hints at a use case limitation, but fails to differentiate from sibling tools like get_signal or get_actionable_signals.

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 is a backtest and returns live forward-return records by signal type, and that no asset filter is applied. However, the phrase 'live forward-return' may cause confusion with real-time data, and the description does not clarify any potential side effects or safety profile.

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 extremely concise: two sentences plus a note. It front-loads the core purpose and key constraints (no asset filter) without any extraneous text.

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

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

The tool has only one parameter and an output schema exists (not shown but referenced). The description adequately summarizes the return fields and notes that the data matches the REST endpoint, providing sufficient context for a simple tool.

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

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

Schema description coverage is 0%, so the description must compensate. It adds the valid range (1-365) and the default value (30) for the 'days' parameter, which are not present in the schema. This significantly improves usability.

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 it backtests performance over a customizable period and lists return fields (win_rate, avg_pnl, by-type breakdown). It distinguishes itself from siblings by explicitly noting the lack of asset filter and aggregation across all assets.

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: it is for aggregated performance without asset filter, and notes it returns the same data as the REST endpoint. However, it does not explicitly state when not to use it or mention alternative tools for filtered performance.

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, so the description carries full burden. It details the computation and output format (net bias in [-1,1] with reasoning per component and data freshness). It implies read-only analysis but doesn't explicitly state non-destructive 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 dense with necessary information but could be more structured. It front-loads the main purpose and lists components efficiently.

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 one parameter and no output schema, the description provides sufficient context about inputs, outputs, and algorithmic components. It mentions data freshness and reasoning, making it complete for the tool's complexity.

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

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

Only one parameter 'coin' with default 'BTC'. Schema has 0% description coverage. The description mentions 'for one coin' but does not add detailed semantics like allowed values or format 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's purpose: 'Positioning thesis for one coin' with specific components listed. It also distinguishes from sibling tools by saying 'Use INSTEAD of manually combining get_liquidation_map + get_options + funding.'

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 tells when to use this tool as an alternative to combining other tools. It mentions 'Conditioning context, not financial advice' but does not provide explicit when-not scenarios.

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 discloses that the score is a 'proxy' and 'uncalibrated heuristic', and notes the data source. This adds transparency about the tool's reliability and nature, though it does not explicitly mention side effects or authorization needs.

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

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

The description is two sentences, highly concise, and front-loaded with the core purpose. Every sentence adds value, with no wasted words.

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

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

Given no parameters and an output schema that likely explains return values, the description provides sufficient context: score range, derivation, and caveats. It is complete for the tool's scope.

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?

There are zero parameters, so baseline is 4. The description adds context about the score meaning but does not need to elaborate on parameters since none exist.

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 purpose: assessing capital rotation between altcoins and BTC, with a specific score range and derivation method. It distinguishes from sibling tools by focusing on 'altseason/rotation' specifically, contrasting with other tools like get_correlation or get_market_regime.

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 context for when to use the tool (to assess altseason vs risk-off) and mentions limitations (proxy, uncalibrated heuristic). However, it does not explicitly state when not to use it or name alternatives, leaving room for improvement.

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 provides good transparency: it discloses curated sources (smart-money voices), recency decay, confidence weighting, 24h window, and explicitly states what it is NOT (mass social volume). It omits rate limits or auth but is otherwise thorough.

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

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

The description is two sentences, front-loaded with the main purpose, uses bold for emphasis, and contains zero wasted words.

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

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

Given the simple parameter and presence of an output schema, the description fully covers the tool's behavior, data source, and time window. No additional details needed.

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 single parameter 'coin' is implicitly described in the tool description. Although schema description coverage is 0%, the parameter is self-explanatory and the description adds context by specifying the coin's sentiment is aggregated.

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 it aggregates sentiment for a coin, detailing components like net directional lean, chatter volume/velocity, and contributing sources over 24h. It also specifies data source as curated high-edge authors, distinguishing it from mass social volume.

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 does not explicitly state when to use this tool vs alternatives, but it mentions 'Same data as REST /sentiment/{coin}.' It clarifies what it does not cover (mass social volume), but lacks explicit when-to-use or when-not-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?

Describes enrichment fields and 404 error semantics beyond the basic fetch, adding value despite lack of annotations. Does not explicitly state read-only but inferred.

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 with zero waste, front-loading the core action and key behavioral details.

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?

Adequate for a simple get tool with output schema; error behavior is covered. Missing mention of idempotency or authentication, but low complexity reduces need.

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

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

Schema coverage is 0%, and the description only says 'by ID' without adding details on the ID parameter's format, range, or source. Single parameter makes it clear but lacks depth.

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 'Fetch a single signal by ID' with specific enrichment fields, distinguishing it from siblings like 'get_signal_with_context' and 'list_signals'.

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 for fetching a single signal, but no explicit guidance on when to use this tool vs alternatives such as 'get_signal_with_context' or 'get_actionable_signals'.

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, but the description discloses a hard limit of 100 per call and the walk-forward pattern. It implies a read-only operation, though authentication or other behavioral traits are not mentioned.

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 concise sentences with front-loaded purpose. No wasted words.

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

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

Essential polling behavior is covered, and output schema is present. However, missing description of the 'asset' parameter reduces completeness for a 2-parameter tool.

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

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

Schema description coverage is 0%. The description explains the use of 'since_timestamp' but does not mention the optional 'asset' parameter or its significance, leaving a gap in understanding for the agent.

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 active signals after a given timestamp and explicitly positions it as a polling alternative to WebSocket. This distinguishes it from many sibling tools.

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

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

The description explains when to use this tool (as polling alternative to WebSocket) and provides a usage pattern with the returned server_timestamp, but does not explicitly exclude cases where other tools would be better.

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. The description discloses that the return type is a dict with varying shape, which is useful, but it does not cover other behavioral aspects like idempotency, error handling, or authorization requirements.

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

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

Three sentences that are front-loaded with purpose, benefit, and an important note about the return type, with no unnecessary words.

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

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

For a simple one-parameter tool with an output schema (though not provided), the description covers the key aspects: composite nature, round-trip savings, and return shape variation. It could add a sentence about typical use cases or prerequisites.

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 0% description coverage, and the description does not explain what the 'id' parameter represents or its expected format, which is insufficient for a single-parameter tool.

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 it is a composite call combining signal, same-asset S/R levels, and active macro bias, which distinguishes it from sibling tools like get_signal, get_levels, and get_macro.

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 mentions it saves 2-3 round trips, implying it should be used when all three pieces of data are needed, but does not explicitly state when not to use it or list alternatives.

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

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

With no annotations provided, the description carries full burden for behavioral transparency. It mentions 'Pro tier' and 'Measured + AI data, not advice,' but does not disclose potential side effects, update frequency, error behavior, or any other important operational details. The term 'snapshot' implies static data but no clarity on freshness or limitations.

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 primary purpose and includes a detailed list of included data. It is slightly verbose with jargon like 'proven-voter directional read' and 'deterministic FRED composite anchor,' but every sentence provides value. Could be more concise 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?

Given the tool has one optional parameter, no output schema, and no annotations, the description provides a comprehensive overview of what the tool returns (price, support/resistance, liquidation map, macro regime). It also notes the pricing tier and disclaimer. This is sufficient for an AI agent to understand the tool's capabilities and constraints.

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

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

The single parameter 'coin' is described in the schema with a default value. Schema description coverage is 0%, meaning the description does not restate the parameter. However, the parameter is self-explanatory from the schema, and the description's mention of 'one coin' adds sufficient context. The parameter semantics are adequate for a simple parameter.

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

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

The description clearly states that it returns a unified whole-system snapshot for one coin, listing specific data types (price, market-state consensus, support/resistance, liquidation map, macro regime). It explicitly differentiates from siblings by stating 'One call instead of stitching get_macro + get_market_state + get_levels,' showing a specific verb and resource scope.

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 clear context for when to use this tool (when a combined snapshot for one coin is needed) and implicitly suggests alternatives (use individual tools for specific data). However, it does not explicitly state when not to use it or provide exclusions.

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

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

No annotations are provided, so the description carries full burden. It discloses that the output is analytical (not advice) and mentions warnings, but lacks details on authentication, rate limits, error behavior, or what happens for invalid coins. Provides moderate transparency.

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 extremely concise: two sentences, no wasted words. The first sentence lists output components, the second provides source and disclaimer. Information is front-loaded and well-structured.

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 detailing the plan components. It covers the key items the agent would need to know (direction, entry, target, etc.). However, it does not mention pagination, limits, or error handling. Sibling tools are many but this tool's niche is clear.

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

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

Schema coverage is 0%, so description must compensate. It adds meaning by explaining that the parameter 'coin' is a cryptocurrency symbol and describes the contents of the returned plan. Though it doesn't specify format or examples, it provides substantial context for a single simple parameter.

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

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

The description clearly states the tool assembles a trade plan for one coin, listing specific components (direction, entry, strongest target, stop, risk/reward, sizing hint, options context, warnings). It differentiates from sibling tools like 'check_trade' or 'rank_trades' by its specific output and per-coin scope.

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 for retrieving a trade plan for a single coin, but does not explicitly state when to use it vs. alternatives, nor does it provide prerequisites or exclusions. No guidance on when not to use this tool.

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

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

While no annotations are provided, the description implies a read-only operation by calling it 'liveness' and 'stats'. It does not explicitly state that it has no side effects, but the context makes it clear. A minor improvement would be to explicitly mention read-only.

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

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

The description is two sentences, each providing essential information: first sentence defines the tool's output, second sentence adds usage context. No wasted words.

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

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

Given the simplicity (no parameters, output schema exists), the description fully covers purpose, output summary, and usage alternatives. It is complete and leaves no ambiguity.

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

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

There are no parameters, and the schema coverage is 100% (vacuous). The description adds value by listing the output fields, which aids understanding even though input semantics are not applicable. Baseline for 0 params is 4.

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

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

The description clearly states this is a liveness check with pipeline stats including uptime, signals in last 1h, macro regime, and classifier backlog. It distinguishes from sibling tools which are data retrieval tools by being a health endpoint.

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 it is pro-gated and advises using REST /health for unauthenticated liveness checks. This provides clear guidance on when to use this tool versus the alternative.

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, but description notes that each signal includes fields like historical_edge, paired_inverse, signal_latency_secs, etc., and that confidence is null when calibration_inverted_in_cell is true. This adds behavioral context beyond a simple list call, but does not explicitly state it is read-only or safe.

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?

Description is three sentences: first states purpose, second lists filters, third describes output fields. Efficient and front-loaded with key action. No 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 annotations, 8 parameters, and output schema exists, the description covers parameters and output fields well. It lacks details on pagination metadata, error handling, or permissions, but is sufficient for a list 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 0% description coverage, but description enumerates all 8 parameters with examples and allowed values (e.g., signal_type enums, direction, urgency, limit range). Adds significant meaning beyond the schema's type-only definitions.

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 states 'List active n0brains signals with optional filters.' The verb 'list' and resource 'signals' are specific. Differentiates from sibling get_signal and get_signals_since by noting it lists active signals with filters, though does not explicitly exclude other list tools like get_actionable_signals.

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

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

No explicit guidance on when to use this tool versus alternatives such as get_actionable_signals or get_signals_since. Context is implied but not stated.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It mentions the tool mirrors a GET endpoint and is analytical, not advice, but does not disclose whether it is read-only, authentication requirements, rate limits, or side effects. This is minimal for a tool with no 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 two sentences, front-loaded with the core purpose, and every part adds value. No redundant or verbose text.

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

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

Given the simple input schema and no output schema or annotations, the description adequately covers the purpose and input format. However, it omits details about the output structure (e.g., what setup_score means) and error conditions, leaving some gaps for an agent to infer.

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 description adds clear meaning to the single `coins` parameter: it is a comma-separated list with a default value (BTC,ETH,SOL). This goes beyond the raw schema, which lacks descriptions. It also explains how the parameter relates to the ranking output.

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 performs cross-asset ranking of trade plans for given coins, sorted by setup_score, and answers which coin is a better trade. It specifies the input format and default. However, it does not explicitly differentiate from sibling tools like check_trade or get_trade_plan, which could be similar.

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 suggests using the tool to compare trade candidates, and notes it is analytical and not advice. However, it does not specify when to avoid using it or provide alternatives among the many sibling tools, leaving the agent without clear usage boundaries.

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