n0brains

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

The description goes beyond the annotations (readOnlyHint: false, destructiveHint: true) by disclosing critical behavioral nuances: a stop move only changes the current stop used by the watchdog, while realized R remains tied to the initial stop; correct_entry=true resets the R basis and this is disclosed in the response; and asset/side are immutable. These details are not available from annotations alone.

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

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

The description is information-dense yet well-structured. It starts with the core action, then proceeds to critical caveats (R basis, correct_entry, asset/side restriction) in a logical order. Every sentence adds value, with no filler or repetition.

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

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

For a complex mutation tool with 8 parameters and no output schema, the description covers the most important behavioral aspects: the R calculation semantics, correct_entry behavior, and the immutability of asset/side. However, it omits the 'entry' parameter entirely, leaving its meaning and usage unexplained. Given the tool's complexity and absence of output schema, this is a notable gap, but overall the description is quite comprehensive.

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 carries the burden of explaining parameters. It clearly explains correct_entry and the stop behavior, and lists size_usd/leverage/thesis as amendable. However, the 'entry' parameter is entirely missing from the description, and target/leverage/size_usd receive no semantic detail beyond being listed. This partial coverage leaves gaps for a few parameters.

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

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

The description clearly states the tool's primary action: 'Amend an OPEN journal trade by trade_id' with specific amendable fields (stop, target, size_usd, leverage, thesis). It distinguishes itself from sibling tools like log_trade and void_trade by focusing on modification of existing trades, and explicitly notes the non-amendable asset/side, directing users to void and re-log.

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 guidance on when to use this tool: to amend an open trade's stop/target/size/leverage/thesis. It also gives a clear exclusion and alternative: 'asset/side can't be amended — void and re-log for that.' Additionally, it conditions the use of correct_entry=true for genuine fat-finger corrections, explaining when that flag is appropriate.

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 that grades are 'logged and resolved at horizon' and that 'cross-grade performance stays withheld until the deployed weekly truth gate clears', providing insight into side effects and timing. It also includes a disclaimer 'Analytical, not advice'. This adds significant behavioral context beyond the sparse 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 a single dense paragraph that front-loads the purpose and packs in inputs, outputs, behavior, and pairing guidance. While lengthy, each sentence adds value, so it is appropriately 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?

Given the lack of an output schema, the description thoroughly covers the return value (grade A..F with flags, supporting factors, falsifiers) and provides usage context with siblings. It leaves a few domain terms unexplained (e.g., 'n0brains', 'weekly truth gate'), but overall it is a complete description for a complex tool.

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

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

Schema coverage is 0%, so the description compensates by enumerating the optional parameters ('entry, stop, target, leverage, horizon_hours (default 24)') and clarifying the required 'asset + side (long/short)'. It does not deeply explain each parameter's semantics, but the trading context makes them relatively self-explanatory.

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 a 'graded pre-trade conditions assessment' returning a grade A..F with flags. It uses a specific verb ('vet'/'check') and resource ('proposed trade'), and distinguishes it from sibling tools by positioning it as the entry point ('START HERE') and by naming complementary tools like get_positioning and get_event_outlook.

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

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

It explicitly says to 'Ask n0brains First' and marks this as the starting point for vetting a trade. It also provides the alternative/complementary tools to pair with for a complete assessment, though it doesn't state explicit when-not-to-use 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?

Beyond the destructiveHint annotation, the description discloses what happens after closing: 'n0brains resolves the outcome from real candles over the held window' including return %, R multiple, MAE/MFE, and whether stop/target traded. It also explains the default behavior of exit_price and the requirements for historical backfill, adding meaningful behavioral context.

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

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

The description is compact and front-loaded, with the primary action first. It packs substantial information (modes, metrics, defaults) into a few sentences. The trailing 'Pro.' is somewhat cryptic and adds little, preventing a perfect score.

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

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

Given the lack of an output schema, the description explains what the tool computes and returns (return %, R, MAE/MFE, stop/target trade), covering the essential behavioral outcomes. It does not explicitly describe the response format or error handling, but for a destructive close operation with clear modes, 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?

The description provides meaning for all four parameters: trade_id (source), exit_price (defaults to live price), note (exit reasoning), and closed_at (epoch seconds for historical backfill). Since the schema has no descriptions (0% coverage), the description fully compensates by explaining each parameter's purpose and usage.

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 action ('Close a journal trade by trade_id'), specifies the resource ('journal trade'), and indicates where the trade_id comes from ('from log_trade or get_journal'). This distinguishes it from sibling tools like 'void_trade' or 'amend_trade' by the verb 'close' and the detailed outcome resolution.

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

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

The description gives explicit usage context: normal journal closing with optional exit_price and note, plus a separate historical backfill mode requiring closed_at and explicit exit_price. It does not explicitly name alternative tools or exclusions, but the two-mode breakdown provides clear when-to-use guidance.

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

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

Beyond the readOnlyHint annotation, the description reveals the algorithm (embedding cosine similarity), the ranking behavior, the valid k range (1-20), the requirement to supply at least one of coin/q, and the non-advice disclaimer. It also notes the REST mirror, adding valuable context about how the tool behaves without contradicting the annotations.

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

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

The description is compact and front-loaded, using a single well-structured sentence that combines a memorable label, a clear mechanism, parameter constraints, a practical example, and a disclaimer. Every phrase adds value, and there is no unnecessary filler.

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

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

For a read-only search tool with no output schema, the description covers the purpose, input constraints, algorithm, and use case. It could be more explicit about the return structure (e.g., whether the output includes similarity scores), but the phrase 'get the k most similar past signals ranked by embedding cosine similarity' gives a sufficiently clear picture of the result.

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

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

With 0% schema description coverage, the description compensates by explaining the role of k (number of similar signals, 1-20, default 5), q (free-text query), and coin (a coin). It also adds the constraint that at least one of coin/q must be provided. However, it does not specify the exact format for coin (e.g., symbol vs. name) or the query syntax, leaving some ambiguity.

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 a specific action: 'Semantic similarity search across the signal corpus' and describes the resource (past signals) and the output (k most similar ranked by cosine similarity). The 'DRILL-DOWN — history rhymes' label and the phrase 'have we seen this setup before' help distinguish it from sibling tools that retrieve individual signals or market analogs.

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

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

The description provides clear usage context through the exploratory question 'have we seen this setup before and what did it look like' and states the required input ('Provide at least one of coin / q'). However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of full 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?

Beyond the readOnlyHint annotation, the description reveals key behaviors: skipping anti-predictive cells, the distinction between `signals` and `reads`, the never-empty `reads` array, and the meaning of `has_trade_signal`. This level of detail is transparent and consistent with 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?

Though lengthy, the description is densely packed with operational instructions and uses visual spacing and capitalization for emphasis. Every sentence earns its place, and the critical 'start here' directive is front-loaded.

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 self-sufficiently covers purpose, parameter usage, result structure, fallback behavior, and next-step guidance. It does not rely on the output schema or annotations to be understood, and it addresses edge cases like empty results and the actionable=false tag.

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 explains the semantics of max_age_min, min_score, and min_confidence, but asset and signal_type are left to inference from their names. Given that the schema has no property descriptions, this partial coverage still adds value 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?

The description opens with a clear directive ('find me a trade') and specifies exactly what the tool returns: gate-passed intraday trade signals and swing outlooks. It explicitly names sibling tools (rank_trades, get_trade_plan, check_trade) and contrasts the tool's purpose, making it unmistakable.

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

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

The description gives explicit usage context: when to start here, when the empty result should redirect to rank_trades/get_trade_plan, and that check_trade should be used to grade candidates. It also warns that swing_outlooks are NOT intraday trades, preventing misuse.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds meaningful context about what makes cells anti-predictive (inverse_flagged=true, win-rate below threshold) and downstream effects (calibration inversion, confidence nulling in serialization), going beyond the structured metadata.

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, with three sentences that front-load the key identifier ('Cells from cell_stats.json with inverse_flagged=true') and elaborate logically into definition and consequences. Every sentence earns its place without 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 the tool has no parameters, a read-only annotation, and an output schema, the description fully covers the conceptual meaning and implications of the returned data. It is complete for an agent to understand what is being retrieved and how to interpret it.

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

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

The tool has zero parameters, so the baseline per rubric is 4. The description provides significant semantic detail about the returned data, compensating for the lack of parameter documentation.

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

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

The description clearly states the tool returns cells from cell_stats.json with inverse_flagged=true, defining them as (signal_type × direction × regime) buckets with below-threshold win rates. This specific verb+resource combination distinguishes it from sibling get_* 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?

No explicit guidance on when to use this tool versus alternatives. It does not mention any exclusion criteria or point to sibling tools for different use cases, such as get_actionable_signals for 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that the tradeable badge is informational, status is 'accruing' until a minimum sample is reached, and baseline measurement differs by asset class. This adds valuable behavioral context that annotations alone do not provide.

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

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

The description is densely packed but well-structured, with each sentence contributing a distinct fact: scope, baseline, intel-only caveat, status accrual, REST equivalence, and crypto alternative. It is front-loaded with the core purpose and contains no redundant filler.

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

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

For a single-parameter read-only tool with no output schema, the description covers what the tool returns, how values are benchmarked, when status becomes reliable, and where to find equivalent or alternative data. This is sufficient context for an agent to select and invoke the tool correctly.

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

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

With 0% schema coverage and only an untyped string parameter, the description supplies the allowed values (stock | index | metal | commodity) and explains how each class is measured. This fully compensates for the schema's lack of detail.

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 defines the tool as a per-non-crypto-asset-class forward-return scoreboard and explicitly enumerates eligible asset classes (stock, index, metal, commodity). It distinguishes itself from siblings by directing crypto-board usage to get_performance or REST /proof, making its scope unmistakable.

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

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

The description explicitly states this is intel-only and non-crypto is not auto-traded yet, telling the agent when informational use is appropriate. It also names alternatives for the crypto board (get_performance or REST /proof) and points to the equivalent REST endpoint, providing clear when-to-use versus 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?

Beyond the readOnlyHint annotation, the description discloses critical behavioral traits: the `degraded: true` flag indicating an incomplete/stale list, the requirement not to cache it, and the contract `count === len(assets)`. It also reveals the shared cache mirror, adding valuable operational context not captured in annotations.

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

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

The description is dense but well-structured: it starts with the purpose, then gives usage guidance, and then details the contract and edge cases. Every sentence earns its place, with no redundant words 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?

For a 0-parameter tool with no output schema, the description fully covers the behavioral contract, usage context, and data quality flags. It leaves no meaningful gaps for an agent to discover by trial and error.

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 no parameters, so the schema carries no burden. The description adds meaning by explaining the response contract and degraded state, effectively covering what the tool returns. Baseline for 0 params is 4, and this is met.

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

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

The description states the tool returns the asset universe that check_trade, get_trade_plan, and get_levels can price, explicitly naming the sibling tools it supports. It uses a specific verb and resource, and clearly differentiates its role as a one-time discovery call rather than a pricing or analysis tool.

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

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

Usage is explicit: 'Call once instead of discovering support by error' directs the agent to invoke this tool before pricing tools. It also provides handling guidance for the degraded flag (do not cache, retry later) and notes the shared cache mirror, offering clear context on when and how to use.

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

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

Annotations only indicate readOnlyHint and openWorldHint, so the description adds valuable behavioral details: resolved outcomes when the horizon passes, stop-touch handling, free_checks_remaining_today, and that it mirrors REST /checks/history limited to the last 50 records. No contradictions with 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 compact but slightly cluttered with multiple parentheticals and asides (e.g., 'RECEIPTS — your own', 'the journal covers trades you actually took'). Still, every sentence adds useful information, and the core message is front-loaded.

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 parameters and no output schema, the description fully covers the tool's function, scope (last 50), personal calibration aspect, free tier behavior, and the distinction from journal. It is self-sufficient and addresses the tool's life cycle and limitations.

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 baseline is 4. The schema coverage is effectively 100% since there are no properties, and the description does not need to elaborate parameter semantics. It correctly omits parameter 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 states the tool returns the user's past check_trade assessments with resolved outcomes, grades, and side-adjusted results. It also explicitly contrasts with get_journal ('the journal covers trades you actually took'), distinguishing it from a closely related sibling tool.

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

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

The description gives clear context: this is for 'CHECKS you asked for' and implies using get_journal for actual trade logs. It does not explicitly name alternative tools or provide a when-not-to-use statement, but the journal distinction serves as a usable comparator.

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 adds that this is a 'Descriptive statistic (correlation is not causation)', warning against causal interpretation, and notes it mirrors REST /correlation/{coin}, which goes beyond the readOnlyHint and openWorldHint annotations. No contradiction with annotations.

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

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

Two sentences, with the main functionality in the first sentence and a caveat/reference in the second. Every element adds value; no filler.

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

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

Given the readOnlyHint, openWorldHint, and an output schema, the description covers the computation window, base assets, peer list, and the REST equivalent. It is sufficiently complete for an agent to understand what to expect.

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

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

The schema lists a single required 'coin' parameter with no description, and the description only says 'of a coin' without specifying expected format (e.g., symbol vs name). With 0% schema coverage, this leaves the parameter semantics largely undefined.

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 a specific verb ('Return') and resource ('correlation + beta of a coin to BTC and ETH'), along with the window and peers, which distinguishes it from sibling tools like get_prices 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 '[DRILL-DOWN]' prefix signals this tool is for detailed correlation analysis of a single coin, giving clear context. It does not explicitly mention alternatives or when to avoid it, but the unique purpose makes usage context clear.

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

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

Annotations already declare readOnlyHint, and the description adds valuable behavioral context: it is 'descriptive', the ETF flow is 'proven non-predictive', and the tool provides 'not advice'. These disclosures go beyond the read-only flag, informing the agent about the nature and limitations of the 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?

The description is a single, information-dense sentence that covers context, content, purpose, and limitations. It is front-loaded with the topic and uses the [CONTEXT] marker effectively. Every word contributes value, making it an excellent example of concise writing.

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 parameters and no output schema, the description adequately explains what data the tool returns (crypto rotation, OI split, institutional posture via ETF flow/COT/13F). It does not describe the exact return format, but for a no-param tool with this level of substance, 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?

This tool has zero parameters, so the schema is trivially complete. The description does not need to explain parameters, and with 0 params the baseline is 4. No additional parameter information is 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's purpose with a specific verb and resource: it provides cross-asset flows data, covering crypto rotation, crypto-vs-tradfi OI split, and institutional posture. It also distinguishes itself by framing the question it answers ('where are funds going and is the market buying something other than crypto?') and referencing REST /flows, which differentiates it from sibling tools like get_rotation 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 provides clear context for when to use the tool, namely when analyzing cross-asset flows and institutional positioning. However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions but still offers a clear use case.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral context: it reveals the tool is experimental, with a status that accrues over 60-90 days, and that outputs are candidates, not advice. Terms like 'honesty-gated, both-halves' suggest internal validation mechanisms. This provides transparency about data maturity and result reliability that annotations do not cover.

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 relatively concise at about four sentences, with the core purpose front-loaded after a label. However, it is dense with unexplained jargon like 'corroboration class-combinations,' 'shadow ledger,' and 'honesty-gated, both-halves,' which may hinder quick comprehension. It earns its place but could be clearer.

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

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

Given no output schema, the description only hints at return values by stating it surfaces ranked patterns, but does not specify the format or structure. It also leaves key concepts like 'shadow ledger' undefined. The experimental status and accrual period are useful, but for a complex discovery tool, the description is not fully 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?

The tool has zero parameters, so the input schema is empty (100% schema description coverage). Per the baseline for zero parameters, a score of 4 is appropriate. The description does not need to explain parameter semantics, and it does not introduce confusion about 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?

The description clearly identifies the tool as an 'emergent edge discovery' mechanism that mines corroboration class-combinations from a shadow ledger and ranks them by measured edge. This is a specific verb+resource statement that distinguishes it from sibling tools like get_signal or get_prices, which focus on particular data retrieval. The phrase 'Surfaces patterns nobody hand-coded' reinforces its unique purpose, though some jargon makes it less immediately clear.

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

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

The description implies usage for discovering emergent patterns rather than standard data retrieval, noting it is experimental and that status is accruing until the ledger fills. It also cautions 'Candidate, not advice.' However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, leaving the usage context somewhat implicit.

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

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

With readOnlyHint=true already signaling a safe read operation, the description adds valuable behavioral context: it notes that actual data and surprise are included 'once printed', implying intra-period updates. It also states 'Same data as REST /calendar', providing external consistency. No contradiction with 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 dense but efficiently structured: it front-loads the purpose with '[TIMING]' and a clear label, then concisely lists content, arguments, and a usage caveat. Every sentence adds value, and the inline arg documentation is compact.

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 is simple (3 optional params, no output schema). The description covers the data returned (macro releases, earnings with consensus/previous, actual/surprise) and states its non-directional nature. It lacks explicit return format details, but for a calendar feed the content is sufficiently specified. Given the absence of an output schema, this is a minor gap.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining each argument: days_back range (0-90, default 7), days_ahead range (0-60, default 14), and event_class allowed values ('macro'|'earnings', optional). This adds meaning beyond the bare schema properties.

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 scheduled macro and earnings calendar, listing specific event types (CPI, NFP, FOMC, PPI, GDP) and tickers (NVDA, TSLA, MSFT). It distinguishes itself from siblings with the '[TIMING]' tag and 'not a direction call', making its scope unique and 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?

The description provides clear context for when to use the tool ('Context for timing/regime') and explicitly states what it is not for ('not a direction call'). However, it does not name alternative sibling tools for direction or other related queries, so it lacks explicit alternative 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses key behavioral traits: history is null until a cell accrues, the library 'never manufactures' conditionals, and the data is identical to REST /event-outlook. This adds significant context about data reliability and consistency.

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 well-structured: it front-loads the purpose, provides an illustrative example, and adds behavioral caveats. The parenthetical and example add some length, but every sentence contributes unique 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?

No output schema exists, so the description should clarify the return format. It provides a sample snippet and mentions null history, but it does not describe the full result structure or the effect of days_ahead, leaving moderate gaps for a tool of this 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?

The only parameter, days_ahead (optional, default 14), is not mentioned in the description. With schema description coverage at 0%, the description fails to compensate, leaving the agent without any guidance on how this parameter affects the 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 provides upcoming macro releases and earnings joined with measured historical reaction distributions, with a concrete example ('CPI prints Thursday — the last N hot prints moved SPX/BTC X%'). It distinguishes itself from siblings by explicitly saying 'Not a direction call' and referencing the same data via REST /event-outlook.

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

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

The description implies when to use this tool (for historical reaction context, not direction calls) and provides an exclusion ('Not a direction call'). However, it does not explicitly name alternative tools such as get_economic_calendar or get_signal, leaving the comparison implicit.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to repeat safety. It adds valuable behavioral details beyond the annotation: it returns both daily and weekly timeframes, includes a plain-language read, and notes it provides the same data as the REST /indicators/{coin} endpoint. This helps the agent understand the output structure and scope without contradicting 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 a single, information-dense sentence that front-loads the category '[DRILL-DOWN]' and then enumerates indicators and outputs. Every phrase adds value, but it is somewhat long and could be slightly more structured (e.g., separating the 'use for' guidance). Overall, it is concise and well-organized.

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, the description is sufficiently complete for an agent to understand the tool's scope. It covers the input semantics, the type of data returned (daily/weekly timeframes, plain-language read), and cross-references the REST endpoint. No critical information is missing for this low-complexity 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?

The input schema has only one parameter (coin) with no description or enum, so the description must compensate. It does so by giving concrete examples ('BTC', 'ETH', 'SOL', 'XRP') and defining the parameter as a coin. While it doesn't explicitly state format requirements (e.g., uppercase symbols), the examples make the semantics clear enough 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 the tool's function: it returns technical indicators for a specific coin, listing the exact indicators (RSI, MACD, SMA/EMA, Stochastic, Fibonacci) and timeframes (daily/weekly). It also distinguishes itself from sibling tools by mentioning 'Use for momentum + Fib confluence with get_levels', making it specific to momentum and Fib analysis rather than generic market data.

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

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

The description gives explicit context for when to use the tool: 'Use for momentum + Fib confluence with get_levels.' It names a complementary tool (get_levels) and explains the analytical purpose. However, it does not explicitly state when not to use this tool or contrast it with other indicator-related siblings like get_sentiment or get_positioning, so it stops short of a full 5.

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

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

Beyond the readOnlyHint annotation, the description provides substantial behavioral detail: default status 'all' shows open+closed, void is hidden unless explicitly asked, open trades include live unrealized PnL and stop-level warnings, closed trades show resolved outcomes, and a stats block gives personal calibration. These details go far beyond the annotation and help the agent predict tool 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 front-loaded with the main action and logically organized. It is somewhat long but mostly information-dense; however, the '[JOURNAL]' tag and trailing 'Pro.' are unnecessary and slightly detract from conciseness. Overall, it earns its length with useful 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?

With no output schema, the description adequately explains what the tool returns: open trade details (PnL, R, stop warning), closed trade details (ret %, R, MAE/MFE), and a stats block. It also covers parameter effects and default behavior, making it complete for a read-only journal tool with simple parameters.

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 no descriptions and 0% coverage, so the description fully carries the burden. It explains the 'status' values (open, closed, void, all) including the default behavior and hidden void, and explains 'limit' as history length with default 20. This is complete for the two parameters.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Read your private trade journal.' It distinguishes itself from sibling tools by focusing on the journal and explaining its contents (open/closed trades, stats). This makes it unambiguous among many get_* 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 implies clear usage context: use this to read your journal, with status and limit controlling scope. It doesn't explicitly mention when to avoid this tool or alternatives, but the context is sufficiently clear given the unique journal focus. A brief 'use for personal trade history' would strengthen it, but the default behavior and statuses are well explained.

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 data sources (levels_engine + Hyperliquid mids), the three timeframes and their lookback periods, and the structural distinction between nearest intraday levels and swing levels. This far exceeds the readOnlyHint annotation and gives the agent a precise behavioral model.

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 every clause adds unique information: detection timeframes, percentage thresholds, field names, and REST endpoint equivalence. It is front-loaded with the core purpose and uses clear notation to separate concepts.

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

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

For a single-parameter tool, the description thoroughly covers how levels are computed, what fields are returned, and how to interpret nearest vs. structure levels. The output schema handles return values, and the REST endpoint reference ensures data parity.

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 schema description coverage at 0%, the description compensates by showing example coin values and explaining that the coin parameter selects the asset. It also defines output fields like timeframe, distance_pct, and confirmed_by that depend on this parameter, adding meaning beyond the schema.

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

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

The description opens with 'Support/resistance levels for a coin' and specifies example coins (BTC, ETH, SOL). It clearly identifies the resource (levels) and the action (get), and distinguishes itself from sibling market-data tools by focusing on price level structure.

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 its niche via '[DRILL-DOWN]' and explains the coin parameter requirement, but it does not explicitly name alternatives or exclusions. It provides clear context for when an agent would retrieve level-based structure versus other market data 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?

Annotations only declare readOnlyHint and openWorldHint, but the description reveals critical behavioral traits: some coins return modeled estimates with symmetric long/short totals, provenance differs by coin, and the field structure is disclosed. It also notes it mirrors REST /liqmap/{coin}, adding transparency beyond annotations. No contradiction.

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

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

The description is information-dense but efficiently front-loaded with the core purpose and [DRILL-DOWN] tag. Every sentence contributes value, though the provenance explanation is lengthy and could be tightened. Still, it's well-structured and not verbose.

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

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

For a single-parameter read-only tool with no output schema, the description is remarkably complete. It explains the output semantics (bins, imbalance, top zones), the two data modes (observed vs modeled), how to interpret the results, and the source equivalence to a REST endpoint. Nothing essential is missing.

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

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

The schema only defines 'coin' as a string, but the description adds meaning by giving examples ('BTC', 'ETH') and clarifying it's a coin symbol rather than a name. It also provides context that the same coin may return different data (observed vs modeled) based on whether it has a DEX book, which helps interpret the parameter's effect.

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

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

The description precisely states the tool produces a liquidation map for a coin, binned into price clusters, and details exactly what it shows (long/short imbalance, nearest clusters, top zones). It distinguishes itself from sibling tools like get_liquidity_map by focusing specifically on liquidations and referencing its role as the feed for other tools.

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

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

It provides strong contextual guidance: labels it a 'DRILL-DOWN' tool, explains it targets one coin, and warns that provenance varies by coin with explicit instruction to read observed/modeled fields. However, it does not explicitly name alternative tools or state when NOT to use it, so it falls short of the top score.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable context: it is descriptive, not advice, and it enumerates the exact components returned. This goes beyond the annotations and helps the agent understand what to expect from the tool without contradicting any annotation.

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: a single sentence with a list and a clear tag. Every phrase earns its place, and the 'Answers "where is liquidity?"' line is a effective summary that helps the agent quickly grasp the tool's purpose.

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

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

For a zero-parameter, read-only tool with no output schema, the description is quite complete. It names the key content areas and clarifies the descriptive nature. It doesn't detail the exact format or units, but that is less critical given the simplicity and the annotations.

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 schema is trivially complete. The description adds no parameter-specific information because none is needed, but it does enrich the understanding of the output semantics by listing the liquidity components, which is useful 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's function: it provides a net cross-asset liquidity map with specific components (Fed net liquidity, stablecoin dry-powder, total perp OI, liquidation pressure, net taker flow). It explicitly answers the question 'where is liquidity?' and distinguishes itself from siblings like get_liquidation_map by focusing on liquidity rather than liquidations.

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 on when to use the tool (to understand overall liquidity) and even notes that it is 'descriptive, not advice', setting expectations. However, it does not explicitly mention alternatives or exclusion criteria, though its singular purpose strongly implies usage.

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

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

Annotations already provide readOnlyHint=true, so the description doesn't need to restate safety. It adds valuable context: the mode is 'picked by the asset's primary source', indicating behavior varies by asset class. It also details what is returned (buckets, totals, long_pct, ls_ratio, funding, OI-by-venue) and that the accumulated trend over `days` is included, going beyond the schema. It could mention pagination or error cases but is otherwise solid, so a 4 is appropriate.

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, information-dense paragraph with a clear prefix, return value enumeration, and relationship to a sibling tool. It is front-loaded with the key purpose and is moderately concise for the amount of context it provides. It could be split into bullets or shorter sentences, but it 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 2 simple parameters, readOnlyHint annotation, no output schema, and a rich description covering sources, return fields, day range, and sibling relationship, the description is largely complete. It omits an explicit return type shape but enumerates return contents. It is not a full 5 because it could briefly mention what happens for coins without a primary source or any error conditions, but for an analysis tool this is minor.

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

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

Schema description coverage is 0%, so the description must compensate. It explains `days` explicitly: 'the accumulated trend over `days` (1-90, default 7)', and clarifies `coin` as 'one coin' with primary-source mode selection. While it doesn't enumerate all enum values, it covers both parameters' meaning and constraints, adding value 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?

The description starts with '[DRILL-DOWN] Long/short positioning for one coin from REAL data' which clearly identifies the verb (get/retrieve), resource (long/short positioning for a single coin), and distinguishes it from the sibling get_positioning tool by calling itself a drill-down complement to the 8-leg synthesis. It also specifies the data sources (Hyperliquid+GMX, CFTC COT, exchange ratios) and return artifacts.

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 says 'Complements get_positioning (the 8-leg synthesis) with the raw who-is-long-where view', giving a clear alternative and relationship. The '[DRILL-DOWN]' prefix signals when to use it, and the 'Analytical, not advice' disclaimer plus 'Mirrors REST /charts/long-short/{coin}' further clarify its scope and context.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the read-only nature is covered. The description adds valuable behavioral context by mentioning the 'honesty overlay' that flags uncalibrated fields and insufficient data, and the mirroring of a REST endpoint. This goes beyond the annotations without contradicting them.

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

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

The description is three short sentences, each earning its place: what the tool returns, the source (REST mirror), and the data-quality overlay. It is front-loaded with the most important context and contains no filler.

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

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

This is a zero-parameter read-only snapshot tool with an output schema present. The description sufficiently conveys the informational content (macro bias, regime, conviction, calendar risks) and behavioral traits (honesty overlay). No critical information is missing for an agent to select 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 takes zero parameters, so there is nothing for the description to add about parameter semantics. The schema coverage is trivially 100%, and the baseline for 0 params is 4, as per the rubric.

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 providing 'current macro bias' with specific components (regime, BTC/ETH bias + conviction, calendar risks), and notes it mirrors the REST /macro current snapshot. This is a specific verb+resource+scope that distinguishes it from the many other get_* 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 implies usage when macro bias/context is needed, and the [CONTEXT] prefix signals its role as a context provider. However, it does not explicitly state when to use this over alternatives like get_market_regime or get_economic_calendar, nor does it mention any exclusions or trade-offs.

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

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

Annotations already declare this a read-only operation (readOnlyHint=true). The description adds behavioral context by specifying the conviction threshold (≥0.6), the confidence multiplier alignment rule, and the exclusion of macro/macro_pulse types. No contradictions with annotations are present.

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 front-loaded, with the core purpose in the first phrase. Additional context (confidence rule and exclusions) is provided in three brief sentences without 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 the output schema exists and the tool is a simple read-only list operation, the description adequately covers the selection logic, exclusions, and optional filtering. It does not need to describe return values due to the output schema, and the overall behavior is clear 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?

The description explicitly mentions the optional asset filter, adding meaning to the 'asset' parameter beyond the schema. However, the 'limit' parameter is not described, and with schema description coverage at 0%, the description only partially compensates for the lack of parameter documentation.

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

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

The description clearly states the tool returns 'Active signals whose direction AGREES with the current macro bias (conviction ≥ 0.6)', which is a specific filtering criterion distinguishing it from other signal retrieval tools like get_actionable_signals or list_signals. It also names excluded signal types, further clarifying 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 provides usage context by explaining the confidence boost rule (x1.12 vs x0.88 for CONFLICTS) and explicitly excludes macro and macro_pulse signal types, helping users understand what they will and won't find. However, it does not name an alternative sibling tool for conflicting signals, so guidance is implicit rather than explicit.

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

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

Annotations declare readOnlyHint=true, so the read-only nature is already conveyed. The description adds behavioral context by stating 'Analytical, not advice' and 'Mirrors REST /manipulation/{coin}', which inform expectations about output nature and API alignment. It does not introduce any contradiction with the annotations.

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

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

The description is three sentences, each carrying meaningful information: a forensics tag and component list, a differentiation from per-signal data, and an API mirror plus a 'not advice' caveat. It is front-loaded with the core purpose and wastes no 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 single-parameter tool with no output schema, the description is robust: it lists the analysis components, clarifies the scope ('one asset'), notes the REST mirror, and includes a disclaimer. It does not describe the output structure or error conditions, but given the relative simplicity and existing annotations, it is sufficiently complete for an agent to 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 schema has one required 'coin' parameter with no description (0% coverage). The description compensates somewhat by stating 'for one asset,' indicating that 'coin' identifies the asset, but it lacks explicit format details (e.g., symbol vs. name) and does not explain the parameter further. Given the low schema coverage, more detail would be helpful, placing this at a baseline 3.

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

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

The description clearly states the tool performs 'manipulation-risk analysis for one asset' and enumerates the specific outputs (composite score, coordinated-pump probability, fake-engagement risk, liquidation-cascade detection). It explicitly differentiates from the per-signal manipulation_score field, positioning this as the full standalone read, which distinguishes it from sibling tools like 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 says 'Richer than the per-signal manipulation_score field — this is the full standalone read,' which provides guidance on when to use this tool versus relying on the per-signal field. It also notes the single-asset scope and the REST mirror, giving context for API users. However, it doesn't explicitly mention alternative tools or when not to use it, so it falls slightly short of a 5.

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

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

Annotations already mark readOnlyHint=true, and the description adds meaningful context: it uses k-NN over specific market-state inputs, returns median/quartiles/hit-rate per analog and in aggregate, and explicitly says it is not a prediction. It also notes the k range and default, plus episode-separation and REST equivalence, going well beyond annotation-only disclosure.

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

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

The description is well-structured with a [CONTEXT] prefix, followed by concise but complete details on methodology, input space, output statistics, k range, and caveats. Every sentence contributes value, and it is appropriately front-loaded.

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

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

There is no output schema, so the description carries the full burden of explaining return values. It enumerates the input state variables, forecast horizons, statistical summaries, aggregation method, and the non-predictive caveat, making it fully informative for a k-NN analog 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?

The schema only provides a default of 12 with no description. The tool description adds crucial semantics: k is the number of nearest neighbors, valid range 3-25, and default 12, making the parameter's purpose and acceptable inputs fully clear.

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

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

The description states the tool retrieves nearest historical market-state analogs via k-NN and summarizes actual subsequent SPX/NDX/BTC returns over 1d/5d. It specifies the resource (cross-asset state) and output aggregates, distinguishing it from sibling tools focused on signals or indicators. The 'Conditioning context, NOT a prediction' phrase further clarifies its role.

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

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

It clearly indicates this is for conditioning context rather than prediction, and is explicitly tied to 'right now.' However, it does not explicitly name alternative tools or state when not to use it, though the distinction from signal-based siblings is implied.

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

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

Annotations declare readOnlyHint and openWorldHint, and the description goes beyond them by adding behavioral context: it is a read-only composite assembled server-side, uncalibrated blocks are labeled, ranking is setup_score-sorted, and it includes a 'not financial advice' disclaimer. This enriches the agent's understanding of output reliability.

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

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

The description is long but well-structured, starting with a clear hook and then enumerating the included blocks. Every sentence carries meaningful detail, but the density of information and the inline list of underlying tools could be slightly more scannable to aid quick parsing.

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

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

Given the tool's complexity (aggregating five other tools) and the lack of an output schema, the description provides a thorough picture: it names each projected block, explains the optional coin argument, notes labeling of uncalibrated blocks, and includes a risk disclaimer. The agent gets enough to decide invocation and interpret results.

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 only parameter, 'coin', is optional and has a default of null. The description fully explains its effect: it scopes actionable reads to that coin and adds it to the ranked set while preserving setup_score-sorted ranking. This is far more informative than the bare schema definition.

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 a 'one-call morning brief' with specific components: market regime, liquidity read, high-impact events, actionable reads, and trade-plan ranking. It explicitly names the underlying tools it aggregates, distinguishing it from siblings like get_market_regime or rank_trades.

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 a morning brief, a single call for a market overview) and explicitly directs users to 'drill into any block with the underlying tool' when more detail is needed. It also clarifies the optional coin argument's scoping behavior, giving practical usage guidance.

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

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

Annotations already declare readOnlyHint=true, and the description confirms the read-only nature by describing retrieval of prices. It adds useful context about the data source and equivalence to a REST endpoint, but doesn't disclose additional behavioral traits such as freshness guarantees or pagination.

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

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

The description is a single sentence that efficiently conveys the data type, scope, source, and equivalence to an existing endpoint. Every piece of information earns its place with no repetition or 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?

With no parameters, a read-only annotation, and an output schema present, the description provides sufficient information for an agent to select and invoke the tool. It covers what data is returned, the source, and the equivalence to a known REST endpoint.

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

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

The tool has zero parameters, and the schema reflects this with 100% coverage. The description correctly omits parameter details, matching the baseline expected for parameterless tools.

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 the latest TradFi market open prices for BTC/ETH/SOL across sessions. The 'DRILL-DOWN' tag and reference to REST endpoint distinguish it from broader market data 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?

No explicit guidance on when to use this tool versus its siblings. The 'DRILL-DOWN' label implies a focused use case, but no alternatives are named or contrasted, leaving the agent to infer appropriateness.

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

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

Beyond the readOnlyHint annotation, the description discloses that the output is 'Descriptive, uncalibrated, not financial advice,' which sets expectations about the tool's nature. It also explains the blend of inputs (macro composite, cross-sectional breadth, funding regime, vol), adding useful context beyond the structured annotation.

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 compact and front-loaded with a context label. Every sentence adds value: it explains the purpose, the inputs, the output, the alternative, and the disclaimers. No filler or redundancy.

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

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

For a zero-parameter, read-only tool with no output schema, the description provides sufficient detail: possible output values, underlying inputs, and a point of comparison (get_market_brief). It could be more explicit about the exact output format, but it is complete enough for an agent to select and 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, but it does clarify what the tool evaluates (macro composite, breadth, funding, vol), which indirectly gives context for how the result is derived.

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 a market-wide risk-appetite read with specific outcomes (risk-on/risk-off/squeeze) and answers a concrete question ('do conditions favor risk right now?'). It distinguishes itself from the sibling get_market_brief by noting the brief includes this block, and it references the REST endpoint for further clarity.

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

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

The description implies when to use it (when you need a market-wide risk appetite check) and provides a clear alternative ('One-call morning brief incl. this block: get_market_brief'). It does not explicitly state when not to use it, but the context is sufficiently clear for an AI agent to decide.

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

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

Beyond the readOnlyHint annotation, the description adds meaningful behavioral context: the data source (n0brains), the directional/scoped nature (not market-wide), and the velocity categories (rising/falling/emerging). It also explains the intended edge (attention accelerating before price moves), which is not derivable from 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 three tight sentences, front-loaded with '[DRILL-DOWN]' and 'Mindshare leaderboard'. Each sentence earns its place: defining the output, explaining the signal value, and clarifying scope/data source. No filler or redundancy.

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

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

For a zero-parameter tool with an output schema, the description is complete: it states what it returns, the underlying data source, the limitations, and how to interpret velocity. It gives an agent enough to decide whether to invoke it and what the response will represent.

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

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

The tool has zero parameters, so there is nothing for the description to explain about arguments. Per the baseline for no-parameter tools, a score of 4 is appropriate because the schema is effectively complete and the description implicitly confirms no inputs are needed.

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 Mindshare leaderboard that ranks each asset's share of crypto attention with velocity. The verb 'leaderboard' plus the explicit scope (over n0brains' sources) distinguishes it from sibling get_mindshare_coin, which likely targets a single coin.

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

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

The description provides clear usage context: it is a directional proxy over n0brains sources, not a market-wide absolute, and it mentions the data is same as REST /mindshare. However, it does not explicitly name alternative tools such as get_mindshare_coin, so it stops short of a full when-to-use/when-not-to-use guide.

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

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

Annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds behavioral context by specifying the exact metrics (attention share %, rank, velocity) and the categorical outcome (rising/falling/stable/emerging), which is useful for setting expectations. No contradiction with 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 a single, efficient sentence that front-loads the drill-down nature and lists the core data points. Every word adds value; 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 simplicity (one parameter, output schema exists, annotations cover safety), the description covers the essential behavior and return content well. The only gap is the lack of parameter format guidance, but the overall picture is reasonably complete for an agent to select and invoke the 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?

The sole parameter 'coin' has 0% schema description coverage. The description says 'One coin's mindshare' but doesn't specify whether 'coin' is a symbol, name, or ID, nor what format is expected. The REST endpoint reference hints at the parameter but doesn't define it. This is insufficient for a low-coverage 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's purpose: retrieving a single coin's mindshare data including attention share %, rank, and velocity vs prior window. The '[DRILL-DOWN]' tag and 'One coin's mindshare' distinguish it from the sibling tool 'get_mindshare', making the scope unambiguous.

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

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

The '[DRILL-DOWN]' label and focus on a single coin imply this is the tool for per-coin mindshare details, while 'get_mindshare' likely handles broader overviews. However, it doesn't explicitly state when to use this versus alternatives or provide exclusions, so it's clear but not fully prescriptive.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral context: it outputs a heatmap, focuses on time-structure (1h/4h/24h windows), and includes 'Analytical, not advice'. It also mentions it mirrors REST /narrative/{coin}, which is an extra detail beyond the annotations.

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

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

The description is compact with four purposeful sentences: purpose and metrics, sibling relationship, API mapping, and an advisory note. Each sentence earns its place, though it is slightly longer than the high benchmark example.

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

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

For a read-only tool with a single parameter and no output schema, the description covers what it does, the metrics it provides, the time windows, and its relationship to another tool. It does not explicitly describe the return format, but the listed metrics give the agent a reasonable expectation of the output.

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 only provides a 'coin' string with no description. The description compensates by saying 'for one asset' and 'Mirrors REST /narrative/{coin}', making it clear that the coin parameter is the asset identifier. This adds meaning despite 0% schema coverage.

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 'Narrative heatmap for one asset' with specific metrics (signal momentum, velocity, decay, manipulation probability, directional conviction) across time windows. It distinguishes itself from get_mindshare_coin by focusing on time-structure, making its purpose unambiguous.

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

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

The description explicitly says 'Complements get_mindshare_coin (attention share) with time-structure', guiding the agent on when to use this tool versus its sibling. It also adds 'Analytical, not advice' as an interpretive caveat. However, it does not explicitly state exclusions or conditions 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?

Beyond the readOnlyHint annotation, the description adds interpretive guidance (positive skew = fear, contango slope) and explicitly disclaims predictive use. It also discloses the data source and notes the same data is available via REST. No contradictions with 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 one dense sentence that front-loads the core purpose ('Options analytics...'), then adds brief interpretive notes. Every clause contributes value without unnecessary verbosity.

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 that an output schema exists, the description sufficiently explains the tool's scope by listing the metrics, the data source, and the only parameter's valid values. It gives an agent enough context to use the tool effectively.

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, but the description compensates by specifying valid values ('BTC or ETH') and clarifying that the coin is the subject of the analytics. This is adequate for a single parameter, though it doesn't specify exact string formatting (e.g., case sensitivity).

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 begins with 'Options analytics for a coin (BTC or ETH)' and enumerates specific metrics (ATM implied vol, skew, term structure, put/call OI ratio, max-pain). It clearly distinguishes itself from sibling tools by focusing on options-specific data and naming the source (Deribit).

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

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

The description provides clear usage context: 'Descriptive positioning, not prediction' and labels itself as a 'DRILL-DOWN' tool. However, it does not explicitly name alternative tools or state when not to use it, relying instead on the uniqueness of options analytics among siblings.

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

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

Annotations already declare read-only and open-world hints, so the safety profile is covered. The description adds valuable behavioral context: it clarifies the data source ('Same data as REST /performance'), the nature of the metric ('live forward-return record'), and the aggregation behavior ('no asset filter'). No contradiction with 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 concise, with four sentences front-loaded by the [RECEIPTS] tag and the core action. Each sentence earns its place, though the 'Same data as REST /performance' and the final definitional sentence could be seen as slightly redundant but still informative.

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

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

For a read-only tool with a single parameter and an output schema, the description covers the essential context: what is returned, the time range, the lack of asset filtering, and the data source. It doesn't discuss permissions or rate limits, but annotations handle the read-only aspect, making this adequately 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?

The schema only shows a single optional 'days' parameter with a default, but the description explains its meaning, range (1-365), and default (30), fully compensating for the 0% schema coverage. The parameter semantics are clear and actionable.

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 action ('Backtest performance'), the resource ('performance over last N days'), and the scope ('aggregated across all assets'). It distinguishes itself from sibling tools by specifying it returns signal-type breakdowns and lacks an asset filter, making its purpose unambiguous.

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

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

The description implies when to use the tool (for aggregate performance over a date range) and notes a key limitation ('no asset filter'). However, it does not explicitly name alternatives or state when not to use it, relying on the user to infer context from the 'no asset filter' note.

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

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

Annotations already declare readOnlyHint=true, and the description adds 'Static text, no market data, free tier' and explains that it teaches interpretation of honesty fields. This provides useful behavioral context beyond the annotation, though it doesn't detail the exact return format.

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 focused sentences, front-loaded with 'READ FIRST' and 'routing guide', covering purpose, content, usage, and limitations with no filler. Every sentence earns its place.

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

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

For a zero-parameter, static-text tool, the description covers its role, contents (intents and honesty fields), when to use it, and its static/free nature. No output schema exists, and none is needed for this simple read-only guide.

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

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

The input schema is empty with 0 parameters, and schema description coverage is 100% (vacuously). The description appropriately focuses on purpose rather than parameters, and the baseline for 0 params is 4, so no additional parameter information is needed.

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 is a 'routing guide for every n0brains tool', specifying the intent categories it covers and the honesty fields it explains. It distinguishes itself from the 40+ sibling data tools by being a meta-resource, with a clear verb+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?

Explicitly says 'Call this once if you are unsure which tool to use' and frames it as replacing trial-and-error over the catalog. This gives a direct when-to-use instruction and rationale, with no ambiguity.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds transparency about output behavior: per-line data freshness, coverage grade ('thin-coverage score cannot read like a full one'), and that it mirrors a REST endpoint. This goes beyond basic read-only context.

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

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

The description is front-loaded with a clear headline ('[DRILL-DOWN — who is crowded] Positioning thesis for one coin'), followed by a compact list of components and features. It's long but every clause serves a purpose (e.g., coverage grade warning). The final disclaimer is brief but relevant for a non-advice tool. Slightly dense but not wasteful.

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

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

Given the tool's complexity (multiple data sources, bias calculation, output characteristics), the description is remarkably complete. It explains what data feeds in, what the output looks like (bias, reasoning, freshness, coverage grade), and how to use it (instead of manual combination). No output schema exists, so the description carries the full burden, and it meets that demand.

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

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

The schema has zero description coverage for the only parameter 'coin'. The description implies coin is a symbol ('for one coin', default BTC) but doesn't provide examples, constraints, or format guidance. It partially compensates by mentioning 'one coin' and default BTC, but the meaning is largely inferred from context rather than explicit.

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: who is crowded and which way.' It specifies a distinct resource (positioning) and a specific analysis output (net bias in [-1,1]), differentiating it from sibling tools by naming the alternative approach. The 'DRILL-DOWN' header and component list further clarify 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?

Explicit guidance is provided: 'Use INSTEAD of manually combining get_liquidation_map + get_options + funding.' This directly tells the agent when to choose this tool over alternatives. The description also frames it as a conditioning context, setting expectations for usage.

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

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

Beyond the readOnlyHint annotation, the description adds substantial behavioral context: it returns specific fields, is the truth anchor for price consistency, indicates it is free tier and public data, and includes a disclaimer. It does not cover error cases or rate limits, but for a simple read-only getter, it is quite 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?

The description is two sentences but packed with value: purpose, output shape, usage, source, and disclaimers. It is front-loaded with the truth-anchor framing and has no unnecessary words. Every sentence earns its place.

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

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

Given the tool has one parameter, no output schema, and minimal annotations, the description is quite complete. It covers the return value shape, its authoritative nature, usage context, and data source. Slight gaps include error handling and specific coin format, but overall it is sufficient for a simple getter.

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 only one parameter, 'coin'. The description merely says 'for a coin', which almost repeats the parameter name without adding format, example values, or accepted conventions. It does not compensate for the lack of schema information.

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

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

The description clearly states what the tool does: it returns the canonical current price (live exchange mid) for a coin. It distinguishes itself from siblings by claiming to be the single source of truth that all other tools should agree with, and it specifies the output format.

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 this tool to sanity-check any analytic payload and discount prices from tools that disagree materially. It does not name alternative tools explicitly, but it makes the appropriate context clear without needing exclusions.

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

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

With readOnlyHint=true in annotations, the description adds valuable behavioral context beyond that: it specifies the input format (comma-separated symbols, max 50), the output structure (prices, missing, source, age_secs), and the 'canonical' nature of the prices. It does not contradict any annotations and enriches the agent's understanding of what to expect.

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 compact and front-loaded: it states the primary purpose in the first clause, then provides param and return details in just two more sentences. Every piece adds value, and the return structure is especially useful given the absence of an output schema. The '[TRUTH ANCHOR]' prefix is minor noise but does not detract from conciseness.

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

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

For a simple tool with one parameter and no output schema, the description provides all necessary context: it explains the input format, the maximum batch size, and the exact JSON return shape including a 'missing' array for coin resolution. This makes the tool self-contained without requiring the agent to infer behavior.

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 for the only parameter 'coins' is 0%, but the description fully compensates by explaining the format: 'comma-separated symbols, e.g. 'BTC,ETH,SOL' (max 50).' This gives the agent explicit syntax, an example, and a constraint that the schema alone lacks. This is exactly the compensation needed for low coverage.

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 function: 'Batch canonical prices for several coins in one call.' This specifies a distinct resource (prices) and the batching behavior, distinguishing it from the sibling tool get_price. The mention of 'several coins' reinforces the batch scope, making the purpose unambiguous.

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

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

The description implies usage for multi-coin queries via 'Batch ... in one call,' which clearly indicates the tool is for when you need several prices. However, it does not explicitly name get_price as an alternative for single-coin requests, so the guidance is clear context without explicit exclusions. This earns a 4 rather than a 5.

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

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

With readOnlyHint already provided, the description adds value by disclosing behavioral traits: swing-horizon boards are 'measurement-only, never badged tradeable' while proven-gate tradeable badges appear on per-signal-type performance. It also adds 'Measured, not advice,' clarifying the nature of the data. This enriches the annotation context without contradicting 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?

The description is dense but well-structured, starting with a clear label and then presenting arguments in a pipe-separated format. It is slightly long, but every sentence conveys necessary context (defaults, behavioral caveats, data source). It earns its length and remains scannable.

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 (2 optional parameters, no output schema), the description fully covers what is returned (proof board, per-signal-type performance, badges, swing boards), how to invoke it (parameter combinations and defaults), and important caveats (measurement-only, not advice). Nothing essential is missing for an agent to use 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?

Schema description coverage is 0%, so the description must fully explain the parameters. It does so by enumerating allowed values for asset_class (stock|index|metal|commodity) and horizon ('7d'|'14d'|'30d'), explaining their meaning (e.g., same as get_asset_class_proof, swing-horizon boards), and specifying the default when both are omitted. This goes well beyond the schema's bare property names.

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 tool provides the full public forward-return proof board, with a specific verb-resource pairing ('get' the proof board). It distinguishes itself from siblings by mentioning 'richer than get_performance' and describing the per-signal-type performance and tradeable badges, making its unique purpose evident.

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 frames when to use this tool versus get_performance ('richer than...'), and explains the parameter choices (asset_class or horizon) and the default behavior when both are omitted. However, it does not explicitly mention when NOT to use it or name alternative tools like get_asset_class_proof except for parameter compatibility, so it stops short of full exclusion 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?

Beyond the readOnlyHint annotation, the description discloses that the score is an uncalibrated heuristic, breadth is a proxy not true BTC dominance, and the calculation inputs (relative-strength breadth + correlation trend). This adds valuable interpretive context and aligns with the read-only hint.

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 compact, consisting of four sentences that each carry meaning: purpose, score range, calculation, caveats, and a REST reference. It is front-loaded with context and does not waste 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 zero-parameter tool with an output schema and clear annotations, the description is comprehensive. It explains the concept, the heuristic's limitations, and references the REST endpoint, covering all essential contextual aspects.

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 zero parameters, the schema fully covers inputs. Baseline 4 is appropriate, and the description adds no parameter details because there are none to describe.

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 an altseason/rotation read, specifying a verb ('read') and resource (capital rotation), and introduces a distinctive metric (rotation_score). It differentiates from siblings like get_correlation or get_market_regime by narrowing focus to rotation.

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

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

The description implies usage for assessing capital rotation ('[CONTEXT] Altseason/rotation read') and includes limitations, but it does not explicitly name alternatives or exclusions. There is no 'use this instead of X' guidance, making it implied rather than explicit.

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

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

Annotations declare readOnlyHint=true, and the description adds substantial behavioral context beyond that: confidence-weighting, recency decay, 24h window, and curated author coverage. This meaningfully enriches the agent's understanding without contradicting 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?

Three sentences, front-loaded with [DRILL-DOWN]. Each sentence adds distinct information—metrics, coverage, and REST equivalence—with no filler or redundancy.

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

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

Given the output schema exists, the description covers purpose, scope, methodology, and exclusions sufficiently. The only minor gap (param format) is already addressed in parameter semantics; overall the tool is well-contextualized.

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 one 'coin' string parameter with 0% description coverage. The description only says 'for a coin' without specifying the expected format (ticker, slug, ID), leaving the agent to guess the parameter value format.

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 'Aggregate sentiment for a coin' and details the exact outputs (net directional lean, chatter volume/velocity, contributing sources). The emphasis on curated high-edge authors versus mass social volume distinguishes it from sibling sentiment 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?

Provides context that this is a 24h drill-down and explicitly excludes mass social volume, implying use for smart-money sentiment. However, it does not name alternative tools for other sentiment types, so it lacks fully explicit when/when-not 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?

Adds behavioral detail beyond the readOnlyHint annotation by disclosing that a not-found signal returns 404 semantics via tool error. Also clarifies the enrichment fields included, which is useful but not extensive.

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 a front-loaded label '[RAW FEED — detail]' and no unnecessary verbiage. Every word 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?

For a single-parameter retrieval tool, the description covers input (by ID), behavior (404 error), and output enrichment fields. Output schema exists, so return format details are not required in the description.

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 only parameter 'id' is referenced as 'by ID', making its purpose clear. However, schema coverage is 0% and the description doesn't provide format, range, or example, though for an integer ID this is minimally sufficient.

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?

Clearly states it fetches a single signal by ID, with an explicit list of enrichment fields (historical_edge, paired_inverse, latency, priced_in). Distinguishes from siblings like list_signals (list vs single) and get_signal_with_context (raw vs contextual).

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 a specific signal with full raw detail when you have the ID. Does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it over list_signals or get_signals_since.

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

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

The annotations already mark it read-only; the description adds valuable behavioral details such as the hard limit of 100 per call and the server_timestamp walk-forward mechanism to avoid gaps. This goes beyond what annotations provide.

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

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

The description is concise: four short sentences, each serving a distinct purpose—identifying as a polling tool, describing the core behavior, giving iteration guidance, and stating the limit. No redundant or vague wording.

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 polling endpoint, the description covers the essential behavior, iteration, and limit. It could mention that asset and signal_type are filters, but the presence of an output schema covers return value details, so this is a minor gap.

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

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

The schema has 0% description coverage, so the description must compensate. It thoroughly explains the required since_timestamp parameter (unix epoch seconds, walk forward), but does not clarify that asset and signal_type are optional filters, leaving their semantics to the schema titles alone.

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 polling alternative to the /stream WebSocket, returning active signals with timestamp greater than a provided since_timestamp. This specific verb+resource+scope distinguishes it from other signal-fetching siblings.

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

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

It explicitly frames the tool as a polling alternative to the WebSocket, giving a clear context for use. It also provides a precise iteration pattern ('Use the returned server_timestamp as the next call's since_timestamp') and notes the hard limit per call, covering both when and how 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?

Annotations already declare readOnlyHint=true, and the description adds valuable context beyond that: it returns a dict rather than a typed model and notes that the composite shape varies. This warns the agent about an unstable return structure, which is a meaningful behavioral disclosure beyond the structured 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 extremely concise—two sentences—and every clause carries meaning: the composite nature, the included context elements, the efficiency benefit, and the return type caveat. No filler or repetition, and the front-loaded label adds useful categorization.

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 an output schema present, the description need not detail return values, but it still discloses the dynamic shape. The composite scope is clearly explained, and the single required parameter is a minor ambiguity. Overall, the tool description is nearly complete for a read-only tool with annotations and output schema.

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%, and the description does not explain the 'id' parameter at all. With no compensatory detail about what id refers to (e.g., signal ID, asset ID, trade ID), the agent is left to guess, making this a significant gap in a low-coverage scenario.

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 is a composite call combining signal, same-asset S/R levels, and active macro bias. It distinguishes itself from simpler siblings like get_signal, get_levels, and get_macro by highlighting the composite nature and saved round trips, though it does not explicitly name those alternatives.

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

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

The phrase 'Saves 2-3 round trips' implies the tool is intended when you need signal plus context and want efficiency, but it does not explicitly state when to use it versus calling separate tools. No exclusions or alternative naming are provided, leaving usage guidance only implicit.

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

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

Annotations already indicate read-only (readOnlyHint=true) and non-open-world (openWorldHint=false). The description adds context about the data being 'Measured + AI data, not advice' and describes the macro regime construction, adding value beyond annotations without contradicting them.

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 longer than typical but well-structured, starting with a 'START HERE' cue and listing contents, alternatives, and a caveat. While not minimal, most sentences add useful context for a comprehensive snapshot tool.

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 adequately enumerates the returned data: current price, market-state consensus, support/resistance, liq-map targets, and macro regime. It also notes the Pro tier restriction and data nature, making it complete for an agent to decide invocation.

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

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

The schema has one param 'coin' with a default and 0% description coverage. The description references 'one coin' and the parameter name is self-explanatory, making the purpose clear. It does not specify valid value formats, but that is a minor gap for a single obvious 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 this is a 'Unified whole-system snapshot for one coin' and enumerates the specific data categories it returns. It also distinguishes itself from sibling tools by noting 'One call instead of stitching get_macro + get_market_state + get_levels' and listing drill-down alternatives.

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: 'One call instead of stitching... Drill down only if needed: get_positioning...' This provides clear guidance on using it as the primary snapshot and points to alternatives for deeper detail.

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

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

Annotations already mark it read-only; the description adds valuable context: 15-minute server-side caching, Pro access requirement, and that the output includes both prose and a structured `data` payload. This goes beyond what annotations provide.

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

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

The description is concise yet information-dense. Every sentence earns its place: purpose, output format, caching, REST mirror, access level, and disclaimer. 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?

For a tool with one optional parameter, read-only annotation, and no output schema, the description covers all essentials: return format (markdown plus data), freshness (caching), access restriction (Pro), and limitation (AI-generated, not advice). It is fully adequate for correct invocation.

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

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

With zero schema description coverage, the description compensates by implicitly defining 'coin' via 'state of <coin>' and the REST path. It doesn't enumerate possible values or mention the default BTC, but the schema already provides the default, and the parameter's intent is clear.

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 a tool that generates a markdown prose brief for a specific coin, synthesizing multiple data sources into a quotable analysis. It explicitly distinguishes itself as the narrative layer over get_state, making it distinct from sibling tools.

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

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

It states the tool produces a quote-ready narrative and mirrors REST /state/{coin}/brief, implying use for human-facing summaries. It mentions the Pro requirement and 'not advice' caveat, but stops short of explicitly saying when not to use it or naming alternatives beyond get_state.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral context: it lists warnings (max-pain timing, liquidation clusters), clarifies the output scope (options context, sizing hint), and includes the important disclaimer 'Analytical, not advice.' This is a rich disclosure of what the tool does and its 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 concise and front-loaded. It uses a compact list format to convey the plan components, a brief API mirror reference, and a one-line disclaimer. Every part contributes to understanding the tool 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 simple one-parameter schema and no output schema, the description does an excellent job of explaining what the plan contains and what to expect. It also ties the tool to a specific API endpoint and a step in a workflow, making it functionally complete for an AI 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% and the only parameter 'coin' has no schema description. The description says 'plan one coin' which implies the parameter is the coin identifier, but it does not specify format, allowed values, or case sensitivity. This is minimal compensation for the missing schema documentation.

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

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

The description clearly identifies the tool's purpose: assembling a trade plan for a single coin. It lists concrete output components (direction, entry, target, stop, risk/reward, etc.) and explicitly mirrors GET /plan/{coin}, distinguishing it from sibling tools like get_signal or get_playbook.

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 '[STEP 2 — plan one coin]' prefix provides workflow context, implying this tool is used after a signal selection step. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough for an agent to pick it when a per-coin plan is needed.

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

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

Annotations already mark it read-only, and the description adds that the tool depends on external services (DexScreener, GoPlus Security) and inspects specific token properties. It omits rate limits or failure behaviors, but provides substantial operational context beyond the annotation.

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 four tight sentences: purpose, usage trigger, REST mirror, and disclaimer. It is front-loaded with the primary function and has no redundant 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?

With one parameter and no output schema, the description covers the input, the procedure, and the practical context. The return format is not explicitly described, but the evaluative checks make it predictable enough 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?

The schema only names the parameter 'Coin' with no description, but the description clarifies it is a ticker that gets resolved to a contract, giving the agent the exact input format. This fully compensates for the zero schema coverage.

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

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

The description uses a specific verb ('screen') and resource ('token'), lists exact checks (honeypot, mint, taxes, insider concentration), and distinguishes itself from sibling market-analysis tools by framing itself as a pre-trade forensics step. The phrase 'Run this BEFORE taking any alt-coin signal seriously' makes its unique role unmistakable.

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

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

It explicitly states when to use the tool: before acting on any alt-coin signal, labeling it a forensics/scam-risk gate. It does not name alternatives or state when not to use it, so it earns a 4 rather than a 5, but the trigger is decisive.

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

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

Annotations already declare readOnlyHint=true, and the description adds useful context: the data is private to the account, mirrors REST /usage, and covers specific metrics. It doesn't describe return format or pagination, but for a simple stats tool with read-only annotation, the added context is sufficient; no contradiction.

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

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

The description is three sentences with a clear [META] tag. It front-loads the core information, then adds usage guidance and a developer reference. Every sentence contributes value without padding, making it both concise 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?

For a simple single-parameter tool with no output schema, this description covers all necessary context: what is returned, the period options, the budgeting use case, privacy, and an API reference. It is complete enough for an agent to select and invoke the tool correctly without further information.

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 only provides the parameter name 'period' with a default, but no description. The description compensates by explicitly listing the allowed values ('7d' or '30d'), which is essential for correct invocation. This fully fills the gap left by the 0% schema coverage.

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 the user's own API usage data (total calls, per-day series, top endpoints) for a given period, with the [META] tag distinguishing it from the many market-data siblings. It specifies the resource ('your own API usage') and the action ('get usage'), making the purpose 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?

Explicitly tells when to use it: 'Use it to budget calls' and references the free tier limit of check_trade (3/day) with get_check_history for remaining count. This provides a clear use case and points to related tools, going beyond what the schema or annotations alone would convey.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful behavioral context: what stats are included (uptime, signals, macro regime, backlog) and that it mirrors REST GET /health with extra context. It doesn't describe return format or error handling, but for a simple health read 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 two sentences, front-loaded with the core purpose, then the REST mirror, then the gating note. Every sentence earns its place, and the [META] prefix signals it's a meta/health endpoint. No waste.

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

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

Given the tool has no input parameters and an output schema is present, the description covers the tool's purpose, contents, and access policy. It's complete for an agent to decide when to invoke it, and the alternative for unauthenticated liveness is spelled out.

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

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

There are zero parameters, so the schema has full coverage by default. The description adds context about what the tool returns, which is sufficient for a no-argument tool. The baseline for zero params is 4, and the description meets that bar.

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

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

The description states a specific verb+resource: it provides 'Liveness + lightweight pipeline stats' with a concrete list (uptime, signals, macro regime, classifier backlog) and explicitly says it 'Mirrors REST GET /health'. This clearly distinguishes it from sibling tools like get_* which are data-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?

The description explicitly notes it is 'Pro-gated (per tools/call rule)' and directs to 'use REST /health for unauthenticated liveness', giving a clear when-to-use and when-not-to-use alternative. This is exactly the kind of explicit guidance needed.

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?

Even with readOnlyHint=true, the description adds substantial context: the raw nature of the feed, the confidence contract (calibrated probability, suppression reasons, status values), transform emitters preserving raw observations, and the action_hint field. This goes far beyond the annotation and fully clarifies behavioral nuances.

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

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

The description is long but every sentence carries essential information. It is front-loaded with the critical caveat, then systematically covers filters, output fields, confidence contract, and alternatives. None of the content is fluff or repetition of structured data.

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 (8 params, 0% schema coverage, no enums in schema) and the presence of an output schema, the description is remarkably complete. It explains the meaning of output fields, confidence semantics, and edge cases, leaving no significant gaps for an agent to misuse the 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%, and the description compensates thoroughly. It lists all 8 parameters, provides example values for asset, enumerates signal_type options, direction and urgency values, and specifies limit range/default. This is a textbook example of compensating for a bare schema.

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

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

The description clearly states it lists active signals with optional filters, and immediately frames itself as a raw feed for engine inputs, not trade calls. It distinguishes from sibling tool get_actionable_signals, making its purpose 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?

Explicitly states 'For tradeable output use get_actionable_signals' and warns that most rows carry action_hint=ignore, setting clear expectations for when to use. It also advises reading historical_edge before echoing direction, providing concrete usage guidance.

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

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

The description discloses behavior beyond annotations: it auto-snapshots full entry conditions (grade, flags, positioning, regime) via an internal check_trade, explains historical grading logic (nearest check_trade within ±6h, same asset+side), never re-grades on today's tape, and notes ungraded trades when no match. It also mentions the journal is private and returns trade_id + entry assessment. Annotations only say readOnly=false, which the description aligns with.

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 well-structured with clear sections for live logging, historical backfill, related tools, return value, and privacy. Every sentence adds value, and the length is appropriate given the tool's complexity (9 parameters, no output schema). No redundant or filler content.

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

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

Given the high parameter count and lack of output schema, the description is remarkably complete. It covers the primary use case, backfill scenario, auto-grading behavior, related tools, return value, and privacy. It even notes the Pro status. There is sufficient information for an AI agent to correctly invoke the 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 fully compensates by explaining each parameter: entry defaults to live price, opened_at is for historical backfill and requires explicit entry, and optional params are listed (stop, target, size_usd, leverage, thesis). It also clarifies the semantic nuance of opened_at and the grading interaction, which goes 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 verb and resource: 'Log a REAL trade entry into your private n0brains journal the moment it fills.' It distinguishes from sibling tools like close_trade and get_journal by focusing on entry logging, and it specifies real trades vs backfill.

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

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

The description provides clear context for when to use the tool: immediately after a fill, and for historical backfill with opened_at. It explicitly mentions alternatives: 'Close with close_trade; read back with get_journal.' However, it doesn't explicitly state when not to use the tool, though the context is sufficient.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this by stating it is analytical. It adds useful behavioral context: sorting by setup_score (best first), the comma-separated input format, and the 'not advice' disclaimer.

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, information-dense sentence. It front-loads the purpose, includes essential parameter details, and avoids filler. Every clause 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?

For a read-only ranking tool with one optional parameter and no output schema, the description covers the main aspects: purpose, input format, default, sorting order, and the non-advice caveat. It stops short of detailing the exact return structure, but the tool's simplicity keeps this from being a critical gap.

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

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

The schema provides only a default value with no description. The description compensates by explaining that 'coins' is comma-separated and defaults to BTC,ETH,SOL, giving the agent complete understanding of the sole 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's function: cross-asset ranking of trade plans sorted by setup_score. It directly answers the question 'which coin is the better trade right now?' and distinguishes itself from siblings by emphasizing the cross-asset comparative aspect.

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 includes a workflow hint ('STEP 2 — pick the coin') and clarifies it is analytical, not advice. It implies when to use the tool (when comparing coins), but does not explicitly name alternatives or exclusion criteria.

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

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

Discloses soft-delete behavior: 'removed from your stats and the default journal view but retained and recoverable (get_journal status='void')'. Also reveals that voiding a CLOSED trade removes its outcome from calibration. These details go beyond the destructiveHint/idempotentHint annotations, explaining the actual consequences.

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 the core action, then behavioral notes and usage guidance. Every sentence adds value; 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?

Covers purpose, usage criteria, side effects, recovery path, and response disclosure ('disclosed in the response'). For a 2-parameter tool with no output schema, this is comprehensive.

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 compensates by explaining trade_id identifies the mis-logged journal trade and that reason is optional. However, it doesn't elaborate on reason semantics beyond 'optional reason', which is adequate for this simple 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 states a specific action: 'Void a mis-logged journal trade by trade_id' with examples like 'wrong asset, duplicate, fat-finger'. It clearly distinguishes from sibling tools by contrasting with close_trade.

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

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

Explicit guidance: 'Use this for entries that never should have existed; use close_trade for real trades that ended.' This tells the agent exactly when to choose this tool over the close_trade alternative.

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