Stonkwatch

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

Despite no annotations, the description fully discloses behavioral traits: one-shot call, returns specific data, cost of 5u per call (~$0.05, deducts 5 from daily quota). No contradictions or hidden behaviors.

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 two sentences plus a cost line, no fluff. Front-loaded with the tool's main purpose and output, making it easy for an agent to parse quickly.

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

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

The description explains what the tool returns and when to use it, covering cost and alternative. However, it lacks details on the output structure (e.g., format of coordination breakdown), but given no output schema, this is acceptable.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context by explaining the purpose of use_case (drives recommended_action) and the effect of raw_sentiment (returns adjusted sentiment). This provides more meaning than the schema 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 states the tool returns 'coordination breakdown, use-case-specific interpretation, and (if raw_sentiment is provided) a coordination-adjusted sentiment score in a single call.' It uses specific verbs and resources, and distinguishes itself from chaining other tools like get_coordination_breakdown.

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 advises to prefer this tool over chaining get_coordination_breakdown + manual sentiment dampening, noting the math matches the canonical filter_sentiment endpoint. Also provides cost and quota information, guiding when to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states this is a calculation tool (implying read-only, non-destructive behavior) and specifies the return values (franking credit, grossed-up dividend, tax payable/refund, after-tax dividend). However, it doesn't mention error conditions, rate limits, or authentication requirements that might be relevant.

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, well-structured sentence that efficiently communicates the tool's purpose and outputs. Every element serves a purpose: identifying the calculation type, specifying the jurisdiction, and listing all return values without unnecessary elaboration.

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 calculation tool with 4 parameters, 100% schema coverage, and no output schema, the description is reasonably complete. It explains what the tool calculates and what it returns. However, without annotations or output schema, it could benefit from more detail about calculation methodology or edge cases to fully guide the 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?

The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds context by explaining the calculation uses the shareholder's marginal tax rate, which helps interpret the taxable_income parameter. It also mentions 'most ASX dividends are 100% franked,' providing real-world context for the franking_percentage default.

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 specific action ('Calculate Australian franking (imputation) credits for dividends') and the resource involved (dividends). It distinguishes this tool from sibling tools like get_stock_price or lookup_company by focusing on tax calculations rather than data retrieval or analysis.

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 is provided on when to use this tool versus alternatives. The description mentions the calculation context but doesn't specify prerequisites, limitations, or scenarios where other tools might be more appropriate. It's implied for dividend tax calculations but lacks usage boundaries.

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

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

With no annotations, the description carries the full burden. It discloses cost (1u ~$0.01) and quota deduction, and notes the output is 'frozen in time' (immutable). It does not mention side effects or permissions, but the disclosed cost and immutability are valuable behavioral traits.

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

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

Two concise sentences plus a cost note. Front-loaded with the core purpose. No superfluous words or repetition.

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

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

For a simple export tool with no output schema and no annotations, the description covers purpose, input expectations, output format (short link), and cost. It could explicitly list required parameters, but the overall completeness is adequate.

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

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

Schema coverage is 0%, so the description must compensate. It explains the 'content' parameter conceptually ('any combination of stock snapshot, timeline, narrative'), but does not detail 'mode', 'symbol', or optional 'window'. The schema itself lacks descriptions, so the agent has insufficient guidance for parameter formats/values.

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: persisting a composed stock-page report as a stable, shareable URL. It specifies the input (tool outputs) and output (short link), and distinguishes from sibling tools which are retrieval-oriented.

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 after composing a report from other tools ('Takes the tool outputs the caller already has'). It does not explicitly exclude scenarios or mention alternatives, but the context is clear enough for selecting this tool over get* siblings.

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

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

No annotations provided, so description carries full burden. It explains filtering by caller_id and lists metrics returned. However, it does not disclose any potential side effects, rate limits, or error conditions.

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 no superfluous information. Purpose is front-loaded. Every sentence adds value.

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

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

Given low complexity (2 params, no output schema, no annotations), the description adequately covers key behaviors and metrics. Could benefit from mentioning response format or 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?

Schema coverage is 100%; both parameters have descriptions. The description adds context about 'rationale' and 'window_hours' but does not significantly extend beyond schema explanations.

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 returns the calling agent's own usage footprint over last N hours with specific metrics. Distinguishes from siblings by being agent-specific and referencing a public endpoint.

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

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

Explicitly says 'Use this to introspect what your own agent has been doing', giving clear context. Mentions similarity to public endpoint filtered to caller_id. Lacks explicit when-not-to-use or alternatives, but siblings are unrelated so not critical.

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

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: returns an SVG of specific dimensions, plots close price around created_at, includes a marker and inline citation text, and clarifies it's a snapshot (not live) and that marker placement is based on created_at (not first spike observation). These details go beyond basic functionality.

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 efficiently structured: it starts by stating the return type and content, then adds intended use, followed by behavioral clarifications, and ends with cost implications. Each sentence adds value without redundancy, though it could be slightly more 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?

Given the tool's simplicity (1 parameter, no output schema), the description covers the core purpose, intended embedding use, and behavioral nuances. However, it lacks guidance on the parameter's origin, error scenarios, or whether the chart is time-sensitive. The cost mention adds useful context but does not fully compensate for these gaps.

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

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

The input schema has 0% description coverage for the only parameter (attribution_id), and the description does not explain what attribution_id is, its format, or how to obtain it. The context of 'single attribution' and references to attribution fields (created_at, headline_citation) imply the parameter's role but do not add sufficient 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 clearly states that the tool returns an inline 1200x630 SVG price chart for a single attribution, detailing the chart's content (line chart with vertical marker and citation label). This specific verb+resource distinguishes it from siblings like get_attribution_graph or get_attribution_timeline, which likely serve different purposes.

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 it is 'Designed to be embedded by another agent in its own answer', providing a clear use case. It also notes the chart is a snapshot, not live, which informs appropriate usage. However, it does not explicitly mention when not to use or compare to alternative tools.

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

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

With no annotations, the description carries full burden. It discloses that attribution is probabilistic, that rumour/speculative classes are not confirmed, and notes cost/quota. This covers key behavioral traits beyond a simple read operation, though it lacks details like pagination or response limits.

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

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

The description is efficient, using two short paragraphs plus a cost line. It front-loads the key output. The probabilistic disclaimer and cost are relevant but could be combined slightly more concisely.

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 complexity (graph output, probabilistic, cost) and no output schema, the description covers the main points but lacks detail on the output structure (fields in nodes/edges) and parameter semantics. It is adequate but has clear gaps.

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

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

Schema coverage is only 25% (only since_ts has a description). The description adds no parameter details beyond mentioning 'ticker' (symbol). It does not elaborate on market, since_ts, or min_evidence_tier, so minimal added meaning over the schema.

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

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

The description clearly states the tool returns an 'attribution graph nodes and edges for a ticker' listing specific node and edge types ('spikes, authors, announcements, predicted edges, contributed_to edges'). This is a specific verb+resource, distinguishes it from siblings like 'get_attribution_timeline' or 'get_spike_detail' by mentioning graph 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 usage by describing what it returns and notes cost, but does not explicitly state when to use this tool vs alternatives (e.g., get_attribution_timeline). No when-not guidance or exclusions are provided.

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

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

Discloses cost (1u per call) and data content (revisions, signals). No annotations provided, so description bears full burden. Does not mention idempotency, authentication, or side effects.

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?

Relatively concise with three short paragraphs. Core functionality in first sentence; cost and warnings separate. No redundant sentences.

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, output content, usage context, and cost. Missing parameter details and output format (no output schema). Adequate but not thorough.

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

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

Single parameter attribution_id has no description in schema (0% coverage). Description does not provide format, example, or additional meaning for the 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?

Clearly states 'Score-evolution history for a single attribution' with details on content (score before/after, market signals). Implicitly differentiated from siblings like get_timeline by focusing on attribution revisions and signals, but no explicit comparison.

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 a use case ('narrating why the score moved') and warnings about probabilistic signals. Lacks explicit when-not-to-use or alternative tools.

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

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

With no annotations, the description carries full burden. It discloses the probabilistic attribution, evidence tiers, and non-causal nature of rumour/speculative signals. It also notes cost units, but does not explicitly state read-only behavior or authentication needs.

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

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

The description is relatively concise and front-loaded with the purpose. The technical details about reputation calculation are necessary but could be slightly more compact. No redundant sentences.

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

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

The description covers the output concept (scorecard, backlinks, reputation metric, evidence tiers) and probabilistic nature, but lacks response format details, error handling, or prerequisite conditions. For a tool with no output schema, more completeness is desirable.

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 low (33%), with only 'symbol' having a description. The tool description does not explain 'handle' or 'platform' beyond their names, nor their expected formats or constraints. It adds no parameter-level meaning for the two required 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 it retrieves a reputation scorecard and backlinks for a social author, explaining the probabilistic reputation calculation and evidence tiers. This distinguishes it from sibling tools like get_attribution_graph or get_spike_detail.

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

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

The description mentions cost and quota but provides no guidance on when to use this tool versus alternatives like get_attribution_timeline or get_market_signals. No explicit when-to-use or when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a penalty and breakdown, mentions cost and quota impact, and warns about common misinterpretation. It does not cover potential errors or response size, but overall it adequately informs about behavioral traits.

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

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

The description is concise, with 7 sentences front-loaded with purpose and key warnings. It efficiently uses each sentence: purpose, pre-requisite spec fetch, warning against threshold guessing, cost disclosure. No fluff or repetition.

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

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

Given the tool's complexity (10 signal classes) and no output schema, the description provides critical context like the need to fetch a spec and the cost model. It lacks details on output format or pagination, but the spec fetch guidance compensates. Overall, it feels sufficient for an informed 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 100%, so baseline is 3. The description adds value by explaining that 'rationale' is used to improve the tool and should be specific, and that 'use_case' returns a tailored summary. This enhances understanding beyond the schema's built-in descriptions.

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

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

The description clearly states it returns a coordination penalty (0..1) and per-signal breakdown for a ticker, distinguishing social-spike coordination from organic discussion. It mentions specific coordinated patterns (pump-and-dump rings, etc.), making the tool's purpose highly specific and distinct from siblings like get_signals or get_spike_detail.

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 advises fetching the coordination spec before using the breakdown and warns against guessing thresholds. It also notes the cost (5u) and daily quota deduction. However, it does not explicitly recommend when to use alternatives among the sibling tools.

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

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

No annotations exist, so the description carries full burden. It discloses cost, that it's correlation/approximation, and that it's not financial advice. However, it omits details about error behavior, data availability conditions, or response truncation.

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 moderately concise but front-loads a very long first sentence that attempts to enumerate all data components. A more structured bullet or list format could improve readability.

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 (2 params, no output schema, no annotations), the description adequately covers the return value's components and cost. However, it lacks parameter details and behavioral traits like pagination or rate limits, leaving gaps.

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

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

With 0% schema description coverage, the description fails to explain the 'lookback_days' parameter and only loosely references 'symbol' via 'ticker'. The input schema has two parameters, but the description adds no semantic value beyond their 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 the tool's specific purpose: returning a 'full cross-source story for a ticker' with enumerated components (announcement, insider trades, sentiment, etc.). This distinguishes it from sibling tools like get_lead_signals or get_timeline, which focus on narrower slices.

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

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

The description notes it's a single-call synthesis and includes cost and disclaimer. However, it doesn't explicitly specify when to use this tool versus alternatives like get_attribution_chart or search, leaving some ambiguity for the AI agent.

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

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

No annotations are provided, so the description bears full burden. It mentions surfacing retail chatter and lead time but does not disclose whether the tool is read-only, whether data is historical or real-time, rate limits, or any side effects. The term 'attributed to platform' hints at source attribution but lacks detail.

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

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

The description is two sentences and gets to the point quickly. However, the phrase 'inbound-beats-outbound signal' might be jargon that could confuse some agents. Could be more straightforward.

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

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

With no output schema and two parameters, the description covers the core concept but omits details like return structure, data freshness, and how to interpret lead times. It's minimally adequate but leaves gaps for the 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 50% (only 'limit' has a description). The description does not mention 'limit' or 'symbol' parameters, nor their format or semantics. The symbol is implied by 'ticker' but not explicitly tied to the parameter. The baseline is 3 due to moderate coverage, but the description adds no parameter-specific value.

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

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

The description clearly states the tool detects pre-announcement social chatter for a ticker, attributed to platform with lead time. It gives a concrete example (HotCopper preceding official announcements) and coins a memorable phrase ('inbound-beats-outbound signal'), which distinguishes it from siblings like get_signals and search.

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 (when wanting lead-time signals from retail chatter) but does not explicitly state when not to use or provide alternatives among siblings. The agent must infer based on tool names.

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

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

No annotations provided, but description fully discloses data sources (Polymarket Gamma, Kalshi, Manifold), derivation logic (direction from market price, confidence from distance from 50-50), volume interpretation, and cost (5u per call). No contradiction with missing 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?

Description is well-structured with main purpose first, then details. At 6 sentences it is reasonably concise, though some details (e.g., cost) could be placed elsewhere. No wasted words.

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

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

Despite no output schema and no annotations, the description covers return fields, data source, direction interpretation, volume caveats, and cost. For a tool with only 2 params, this is thorough.

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

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

Schema has 2 params (ticker required, limit optional) with 0% description coverage. Description mentions 'single ticker' but does not explain ticker format or the limit parameter. Description does not compensate for schema's lack of explanations.

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 retrieves recent prediction-market signals for a single ticker, sorted by most-recent first. It lists the fields (provider, direction, confidence, volume, evidence URL, timestamp) and distinguishes it from siblings like get_lead_signals and get_signals by focusing on prediction markets.

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

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

Provides explicit use case ('what are prediction markets pricing for this ticker right now?') and warns about treating as input not ground truth. Lacks explicit when-not-to-use or alternatives, but context is clear.

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

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

The description discloses key behavioral traits: the need for citation markers ([sN]) mapping to a sources array, with failure if orphaned. It also includes cost information (1u per call, ~$0.01, daily quota deduction). Since annotations are absent, this provides essential transparency.

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

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

The description is extremely concise: two sentences that front-load the purpose and follow with key constraints (citation and cost). Every sentence adds value 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 6 parameters, no output schema, and no annotations, the description is insufficient. It does not cover parameter meanings, return structure, or how to use the citation feature effectively. Essential context for correct invocation 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?

With 0% schema description coverage and no mention of any parameters (symbol, mode, format, window, max_length, custom_prompt) in the description, the tool fails to explain what each parameter does. The description only covers high-level functionality, leaving the agent without necessary detail to correctly set 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 function: generating persona-shaped LLM synthesis for a ticker, specifying three output types (trader card, journalist report, investor thesis). It distinguishes this tool from siblings by its specialized purpose and mentions citation markers, which is unique.

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 narrative generation but does not explicitly state when to use this tool over alternatives like get_stock, search, or get_timeline. No direct guidance on prerequisites or exclusions is provided.

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

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

With no annotations, the description carries full burden. It discloses probabilistic attribution, evidence tier confidence levels, and that certain signals are not confirmed causal. It also notes cost and daily quota deduction. This provides strong behavioral context beyond the schema.

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

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

The description is concise with no unnecessary words. It leads with purpose, then adds behavioral notes and cost. However, it mixes data format and behavior, which could be better separated for clarity.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers purpose, output fields, probabilistic nature, and cost. Missing parameter explanation and pagination details limit completeness. Without output schema, describing all fields would be beneficial.

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, and the description does not explain the limit or offset parameters. It does not add meaning beyond the schema's defaults and constraints. Mentioning pagination control would improve usability.

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

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

Clearly states the tool provides recent spike attributions across all tickers with evidence references. The description details the content of each row. However, it does not differentiate from sibling tools like get_attribution_graph or get_spike_detail, missing an explicit distinction.

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

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

No guidance on when to use this tool versus alternatives. It mentions cost and quota but does not describe scenarios for use, exclusions, or prerequisites. For a firehose tool, it could direct users to other tools for detailed analysis.

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

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

No annotations are provided, so the description must cover behavioral traits. It mentions cost and quota deduction, and manipulator exclusion, but omits authorization needs, rate limits, or read-only status. The cost disclosure adds value, but many behavioral aspects are absent.

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, front-loading the purpose and return values, then parameter details. A single paragraph plus cost line is efficient, though bullet points could improve scannability.

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

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

Given the tool has 3 parameters (one required), no output schema, and no nested objects, the description covers the key aspects: purpose, return fields, parameter options, and cost. It lacks error handling details but is sufficient for basic use.

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

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

Schema coverage is 0%, so description should compensate. It documents the window parameter with valid values and default, but market and ticker are not further explained. Partially adequate, but ticker is 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 it computes per-ticker directional consensus weighted by author reputation, excludes manipulators, and returns specific fields. This distinguishes it from sibling tools like get_signals or get_attribution_chart.

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 reputation-weighted consensus but lacks explicit guidance on when to use versus alternatives like get_author_reputation or get_market_signals. No when-not scenarios are given.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool is for 'raw attributed social posts' and a 'breadcrumb endpoint,' hinting at data retrieval, but lacks details on permissions, rate limits, pagination (cursor usage), or response format. For an 11-parameter tool with no annotations, this is a significant gap in transparency.

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

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

The description is two concise sentences with zero waste: the first states the purpose and key filters, and the second provides usage context. It's front-loaded with essential information and efficiently structured, earning 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 complexity (11 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits like authentication, rate limits, or response structure, and doesn't fully document parameters. For a data retrieval tool with rich filtering options, more context is needed to ensure effective use by 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 description coverage is low at 18%, with only 'since' and 'until' having descriptions. The description adds value by listing key filters ('platform, verified, engagement, sentiment confidence') that map to parameters like 'platform', 'verified_only', 'min_engagement', and 'sentiment', but doesn't fully compensate for the coverage gap or explain all 11 parameters. Baseline 3 is appropriate as it provides some semantic context beyond the 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 the tool retrieves 'raw attributed social posts for a ticker with filters' and distinguishes it from 'the synthesised view,' indicating it provides unfiltered data. However, it doesn't explicitly differentiate from sibling tools like 'get_timeline' or 'search,' which might offer similar social data, leaving some ambiguity about unique 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 specifies this is a 'breadcrumb endpoint for journalists and traders' and contrasts it with 'not the synthesised view,' providing clear context for when to use it (for raw data analysis) and implicitly when not to (for processed insights). It doesn't name alternatives or provide explicit exclusions, but the context is sufficient for informed 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?

With no annotations, the description fully carries the burden: it warns that attribution is probabilistic, explains evidence tier confidence classes, and explicitly states that rumour/speculative signals are not confirmed causal signals. It also transparently states cost (1u per call, dollar equivalent, and daily quota deduction).

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 plus a cost line, all front-loaded with key information. No filler; every sentence adds value (content overview, probabilistic caveat, cost transparency).

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

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

Despite no output schema, the description succinctly covers what the tool returns (contributing posts, attribution rows) and critical behavioral notes (probabilistic attribution, cost). This is sufficient for a simple single-parameter retrieval 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% but only one parameter (spike_id) exists. The description does not elaborate on spike_id format or constraints beyond the tool name's implication. However, for a single obvious parameter, minimal guidance is acceptable.

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 explicitly states the tool retrieves full detail for a single social spike, listing specific elements (contributing posts with author/platform/sentiment, attribution rows with lead time and evidence tier). This clearly distinguishes it from sibling tools that focus on broader attribution graphs or timelines.

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 retrieving details of a specific spike (by spike_id), but provides no explicit guidance on when to prefer this tool over siblings like get_attribution_graph or get_timeline. No mention of alternatives or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that 'one call returns only the slices you request' and that 'mode changes defaults only', which provides some context about the tool's behavior. However, it doesn't address important aspects like rate limits, authentication requirements, error conditions, or what happens when invalid parameters are provided.

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

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

The description is appropriately sized and front-loaded with the core purpose. The two sentences are dense with information, though the second sentence could be slightly clearer. There's no wasted text, and every element serves a purpose.

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

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

Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description provides a reasonable foundation but has gaps. It explains the composite nature and parameter purposes well, but doesn't describe the return format, error handling, or performance characteristics. For a tool with multiple parameters and no output schema, more complete behavioral context would be helpful.

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

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

The description adds significant value beyond the input schema's 20% coverage. It explains the purpose of the 'include[]' parameter (to request specific data slices), clarifies that 'mode' only affects defaults, and lists all available slice options. This compensates well for the low schema description coverage, though it doesn't explain 'window' or 'signals_limit' 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 provides a 'composite stock snapshot' and lists the specific data slices available (price, sentiment, announcements, etc.), which gives a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_signals' or 'get_timeline' beyond mentioning 'composite' nature.

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

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

The description implies usage context by mentioning that 'mode changes defaults only' and that users can request specific slices via include[], but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_signals' or 'search'. The usage is implied rather than clearly stated.

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

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

With no annotations provided, the description carries full burden of behavioral disclosure. It describes what the tool does (merges events, computes lead/lag) but lacks critical behavioral details: whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (cursor parameter), or what format the merged stream returns. The description mentions computational aspects but misses operational transparency.

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

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

The description is perfectly concise with two sentences that each earn their place. The first sentence establishes core functionality, the second explains the analytical value. No wasted words, front-loaded with the main 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 complex tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It explains the analytical purpose well but lacks operational details about authentication, rate limits, return format, and parameter usage. The description covers the 'why' but misses the 'how' and operational constraints.

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

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

Schema description coverage is only 25% (2 of 8 parameters have descriptions), so the description must compensate. The description mentions 'ticker' (maps to symbol parameter) and temporal aspects (implied by since/until), but doesn't explain other parameters like mode, types, min_importance, or cursor. It adds some meaning about the tool's purpose but doesn't fully compensate for the low 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's purpose with specific verbs ('Merged time-ordered events', 'computes lead/lag') and resources ('announcements, social signals, and sentiment shifts', 'social chatter and official filings'). It distinguishes from siblings by focusing on timeline merging and lead/lag analysis rather than signals, stocks, or trending 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 provides clear context about when to use this tool ('Answers "did retail know first"') and implies usage for analyzing temporal relationships between social chatter and official filings. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.

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

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

With no annotations provided, the description carries full burden but only states it's a ranking tool without disclosing behavioral traits like whether it's read-only, requires authentication, has rate limits, or what the output format looks like. The 'discovery entry point' phrasing adds some context but lacks operational details.

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 key information ('discovery entry point' and ranking function) with zero wasted words. Every part of the sentence contributes to understanding 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 ranking tool with 3 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It states what the tool does but lacks details about output format, ranking methodology, or error conditions that would be helpful given the absence of 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 100%, so the schema fully documents all parameters. The description doesn't add any parameter-specific meaning beyond what's in the schema (e.g., it doesn't explain what 'membrane-potential activity score' means or how ranking works). Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('rank'), resource ('ASX stocks'), and metric ('membrane-potential activity score'), distinguishing it from siblings like get_stock (individual stock data) or search (general search). It also frames it as a 'discovery entry point' which helps contextualize 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?

The description implies usage for discovery/ranking scenarios but doesn't explicitly state when to use this tool versus alternatives like get_signals or search. It mentions 'persona-agnostic' ranking in the schema, but this isn't a clear usage guideline in the description itself.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool resolves queries to ticker entities, but doesn't describe how it behaves—e.g., whether it performs fuzzy matching, returns multiple results, handles errors, or requires authentication. This is inadequate for a tool with 3 parameters and no output schema.

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

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

The description is concise with two sentences that are front-loaded: the first states the purpose, and the second adds contextual role. There's no wasted text, but it could be more structured by explicitly separating purpose from usage guidance.

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

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

Given the complexity (3 parameters, 0% schema coverage, no output schema, no annotations), the description is incomplete. It doesn't explain return values, error handling, or how parameters interact, leaving significant gaps for an agent to use the tool correctly in a session workflow context.

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

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

The schema description coverage is 0%, meaning none of the 3 parameters (query, type, limit) are documented in the schema. The description doesn't add any meaning beyond the schema—it doesn't explain what 'query' should contain, what 'type' enum values mean, or how 'limit' affects results. This fails to compensate for the lack of 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 states the tool 'Resolve a query to a canonical stonkwatch ticker entity', which provides a clear verb ('Resolve') and resource ('ticker entity'), but it's vague about what 'resolve' entails (e.g., search, lookup, match) and doesn't distinguish from siblings like 'get_stock' or 'get_signals'. The phrase 'Entry point for all session workflows' adds context but doesn't clarify the specific action.

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

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

The description mentions this is an 'Entry point for all session workflows', implying it's used to start sessions, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_stock' or 'get_trending'. There's no mention of prerequisites, exclusions, or specific scenarios, leaving usage unclear.

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

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

No annotations provided, so description carries full burden. It clearly states the tool is for feedback submission and explains that reports are mined to improve tools. Could mention response nature (e.g., confirmation) but not critical for a feedback tool.

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

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

Four sentences, efficient and front-loaded with purpose. Could be slightly more concise but each 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?

Given 6 parameters with full schema coverage and no output schema, the description is complete. It explains the tool's purpose, when to use, and what to include. Not missing critical context for an agent to invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. Description adds no additional parameter-level information beyond the schema's own descriptions. For example, 'attempted_action' and 'blocker' are already well-documented in the schema.

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

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

The description clearly states the tool's purpose: reporting when a tool didn't work. It uses specific verbs ('Tell Stonkwatch') and resource ('agent feedback') and distinguishes from sibling tools which are all data-retrieval or calculation 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?

Explicitly lists when to call ('whenever you were blocked, the response shape was wrong, you needed a parameter that doesn't exist, or the docs were ambiguous') and what to include ('Always include what you were trying to do'). No alternatives exist, so no need for when-not.

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