Stonkwatch

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

Annotations indicate readOnlyHint=true and destructiveHint=false, consistent with description. Description adds context: one-shot decision tool, no side effects, and cost/resource usage. No contradictions.

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

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

Two sentences: first states purpose and returns, second gives usage guidance and cost. Front-loaded, no filler, 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?

No output schema, but description explains the three return components. Lacks precise structure details, but sufficient for agent to understand what to expect. Could mention that it returns a single object.

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 4 parameters with 0% description coverage. Description explains optional raw_sentiment and its effect, but does not elaborate on symbol, use_case, or rationale. Acceptable, but could provide more parameter 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?

Clearly states it is a one-shot decision tool that returns coordination breakdown, use-case-specific interpretation, and optionally a coordination-adjusted sentiment score. Distinct from siblings like get_coordination_breakdown and get_sentiment.

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 recommends using this tool over chaining get_coordination_breakdown + manual sentiment dampening, and mentions it matches the canonical filter_sentiment endpoint. Also states the cost per call and quota impact.

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 value beyond annotations by disclosing cost (1u per call, ~$0.01 via x402) and daily quota deduction. Annotations already indicate readOnlyHint=true and destructiveHint=false, so no contradiction. The description does not detail any side effects or access requirements, but the cost info is useful.

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

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

The description is two sentences, front-loaded with the core purpose and output, followed by a brief cost note. No unnecessary words 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 tool has 5 parameters and no output schema, the description partially compensates by listing return values. However, it does not explain input parameters (e.g., taxable_income scope, franking_percentage optionality), leaving gaps. The cost and quota info are helpful but insufficient for full contextual completeness.

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

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

Only one of five parameters (rationale) has a description in the schema, and the tool description does not add semantic meaning for the remaining parameters (e.g., what units for cash_dividend? meaning of taxable_income?). With 20% schema coverage, the description fails to compensate, leaving agents to guess parameter semantics.

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

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

The description clearly states the tool calculates Australian franking credits for dividends and lists specific outputs (franking credit amount, grossed-up dividend, etc.). It is distinct from sibling tools, none of which perform financial calculations.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description only states what the tool does, not when or why to choose 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?

The description adds cost details (1u per call, quota deduction) beyond the destructiveHint annotation, making behavioral impact clear. It also mentions the output is a short link, but does not cover error conditions 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?

Three sentences, front-loaded with purpose, then process, then cost. No wasted words, 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?

For a tool with 5 parameters and no output schema, the description is brief. It covers the primary purpose and cost, but does not fully compensate for the lack of schema descriptions or explain return value expectations beyond 'short link'.

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 20% (only rationale has a description) and the description does not explain the purpose or format of key parameters like mode, symbol, window, or content. It vaguely hints that content may be composed of tool outputs, but lacks specificity.

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 persists a stock-page report as a stable shareable URL, with a specific verb (persist) and resource. It distinguishes from other tools by being the only export/persist tool among the 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?

The description implies use when wanting to save a report but does not explicitly state when to use or avoid this tool versus alternatives. No comparison with sibling tools 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds cost information (1u per call, daily quota deduction) and mentions caller_id filtering, which are not captured in 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?

Two compact sentences plus cost note. Front-loaded with purpose, method, and output. 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 no output schema and 0% parameter coverage, the description covers key aspects: return shape, filtering, cost, and comparison to public endpoint. Missing param details for rationale and no mention of pagination, but adequate for a simple introspection tool.

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

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

Schema description coverage is 0%, so description must compensate. It hints at window_hours via 'last N hours' and mentions caller_id as a filter, but does not explain the 'rationale' parameter at all. Two out of three parameters are partially covered, but rationale is left 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 specifies what the tool returns: 'calling agent's own usage footprint over the last N hours' with explicit metrics (total calls, error rate, top tools, p50/p95 latency). It distinguishes itself from sibling tools by focusing on self-introspection, not general data retrieval.

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?

States when to use: 'to introspect what your own agent has been doing'. References the public /agent-stats endpoint as an alternative (same shape but filtered). Provides usage context but does not explicitly exclude scenarios.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds cost and quota information, which is useful for understanding usage limits. However, it does not disclose other behavioral aspects like latency, caching, or error scenarios. 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: the first states the tool's purpose and the second adds cost and quota details. No extraneous information, front-loaded with essential 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 simple tool with 2 parameters, read-only annotations, and no output schema, the description covers purpose, cost, and quota. It mentions what the summary includes (content, key points, sentiment, financial impact), which provides sufficient context. Could add more on output format or error conditions, but overall 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 has 2 required parameters: announcement_id and rationale. Schema coverage is 50% (rationale has a description in schema). The description mentions that the tool is keyed by announcement_id, adding minimal context, but does not explain the expected format or source for announcement_id. The rationale parameter is sufficiently described 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 returns an AI-generated summary of an ASX announcement, including content, key points, sentiment, and financial impact. It specifies the resource (ASX announcement) and verb (get summary), and distinguishes itself by noting it is a standalone tool keyed by announcement_id, helping differentiate 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?

The description mentions cost and daily quota, implying constrained usage, but provides no explicit guidance on when to use this tool versus alternatives (e.g., getting the raw announcement, other summary tools). No exclusions or alternative tool references 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds significant context: cost (1u per call, ~$0.01, deducts from daily quota), confirmation that it is not a live trading view, and clarification that marker placement reflects created_at, not the spike's first observation. This exceeds the annotation baseline.

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: three sentences, no filler, front-loaded with the core purpose and key characteristics. Every sentence contributes necessary context (chart details, embedding use case, cost, non-live nature).

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 parameters, no output schema, annotations present), the description covers purpose, behavior, cost, and use case. It does not address potential errors or edge cases, but such details are not commonly expected for a straightforward chart retrieval tool. Slightly missing a note on what happens if the attribution_id is invalid, but overall 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 description coverage is 50% (only rationale has a description in the schema). The tool description does not add new information about the parameters beyond what is already in the schema; it mentions attribution_id and rationale but provides no additional semantic detail. Baseline 3 applies due to moderate coverage and minimal added value.

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

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

The description uses specific verbs and resource: 'Returns an inline 1200x630 SVG price chart for a single attribution', with detailed chart characteristics (line chart, close price, window around created_at, vertical marker, headline_citation). This clearly distinguishes it from sibling tools like get_attribution_graph or get_attribution_timeline.

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

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

The description states it is 'designed to be embedded by another agent in its own answer' and clarifies it is 'a price snapshot generated at request time, not a live trading view'. However, it does not explicitly state when not to use it or compare to alternative tools 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 readOnlyHint=true and destructiveHint=false. The description adds critical behavioral context: attribution is probabilistic, evidence tiers indicate confidence, and rumour/speculative signals are not ground truth. This goes beyond annotations, though it doesn't cover rate limits or auth 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 but includes some fragmented phrasing. The probabilistic caveat is important but could be integrated more smoothly. It earns its place but could be more structured.

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

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

With 5 parameters and no output schema, the description provides reasonable high-level output info and important disclaimers, but lacks details on parameter meaning and return structure. It is adequate but not 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?

Schema coverage is only 20% (only rationale described). The description does not elaborate on any parameter, not even the key 'symbol'. It misses opportunity to explain since_ts, market, min_evidence_tier given 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 it returns 'attribution graph nodes and edges for a ticker' and lists specific elements (spikes, authors, etc.). This distinguishes it from siblings like get_attribution_chart which returns a chart, not a 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?

No explicit guidance on when to use this tool versus siblings. It does not mention when not to use it or provide context for selecting this tool over alternatives like get_attribution_chart or get_attribution_timeline.

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 readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds valuable behavioral context: cost (1u per call, ~$0.01, deducts from daily quota) and the probabilistic nature of evidence tiers (rumour-class and speculative-class signals are not confirmed causal signals). This goes beyond annotations to inform an agent about cost and data 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 two sentences long, front-loaded with the core purpose, and includes necessary caveats (probabilistic, cost) without extraneous text. Every sentence adds value, making it highly efficient.

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

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

Despite lacking an output schema, the description fully explains the return structure: each revision carries score before/after and triggering market signals. It also covers evidence tier interpretation and cost. With annotations covering safety, the description provides complete context for an agent to understand what the tool returns 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?

Schema coverage is only 33% (only rationale has a description). The tool description does not explain the parameters attribution_id or adapter, nor does it clarify that attribution_id is the identifier for the single attribution. The description fails to add meaning beyond the schema, leaving the agent without guidance on how to specify the tool's input.

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 provides 'score-evolution history for a single attribution' with before/after scores and triggering market signals. It distinguishes from siblings like get_attribution_chart or get_recent_attributions by specifying the focus on revision history for a single attribution and narrating why the score moved.

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 it is 'useful for narrating *why* the score moved as new evidence arrived,' giving clear usage context. However, it does not explicitly mention when not to use it or provide alternatives among siblings, though the focus on a single attribution implies 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?

Annotations already indicate readOnly=true and non-destructive. The description adds valuable context: reputation is time-decayed, attribution is probabilistic, evidence tiers indicate confidence, and rumour/speculative signals are not confirmed. 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 two well-structured sentences plus a cost line, front-loading the main purpose. Every sentence adds value, and it avoids redundancy.

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

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

The description explains the concept and return content vaguely but lacks input guidance (e.g., valid platforms), error behavior, or return field details. With no output schema, more contextual completeness 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?

Schema description coverage is only 25% (just 'rationale' has a description). The description does not elaborate on 'handle', 'platform', or 'symbol' parameters. It only mentions cost, which is not parameter-specific. Minimal added value beyond the schema.

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

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

The description clearly states it provides a 'reputation scorecard and backlinks for a social author,' with specific verb 'Get' and resource 'author reputation.' It somewhat distinguishes from siblings like 'get_reputation_consensus' by mentioning backlinks and time-decayed metric, but could be more explicit.

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 cost note but no guidance on when to use this tool vs alternatives such as 'get_reputation_consensus'. No explicit when/when-not or prerequisites are stated.

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

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

Discloses cost (5u per call, ~$0.05, deducts from daily quota), output format (penalty 0..1, per-signal breakdown), and references external spec for thresholds. Annotations already indicate readOnlyHint=true, and description adds significant behavioral context beyond that.

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, each serving a purpose: purpose, prerequisite, explicit warning, cost. No fluff, well-structured and 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?

No output schema, but description gives a good overview of return values and directs to spec for full detail. For a complex tool, this is adequate but could briefly mention that the breakdown includes 10 signal classes.

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 description only mentions 'ticker' (mapping to symbol) but does not explain the 'use_case' or 'rationale' parameters. This is a significant gap given the required params.

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

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

Clearly states it returns coordination penalty and per-signal breakdown for a ticker, distinguishing from sibling tools like get_spike_detail by explicitly mentioning coordinated vs organic discussion and signal classes.

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

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

Explicitly instructs to fetch the spec resource before using, and warns against guessing thresholds. Provides clear context for when to use this tool versus alternatives.

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

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

Annotations provide readOnlyHint and destructiveHint. The description adds behavioral details: cost of 1u, approximation disclaimer, and that it synthesizes multiple sources. 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 dense paragraph that front-loads the main purpose, lists components, and includes cost and disclaimer. 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 no output schema, the description explains the return values (announcement, trades, sentiment, author reputations, signal trace). It covers key aspects for a composite tool, though minor details like format could be added.

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 rationale described. The description implies symbol is a ticker and mentions a window for trades, but does not explicitly map to parameter names or explain lookback_days. Partial compensation for schema gaps.

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

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

The description clearly states the tool returns 'Stonkwatch's full cross-source story for a ticker' and enumerates the specific components (announcement, trades, sentiment, etc.), distinguishing it from sibling tools like get_narrative or get_signals that focus on individual aspects.

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

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

The description implies the tool is for a comprehensive multi-source synthesis with 'ONE call' and notes it is an approximation, but does not explicitly state when not to use it or compare to alternatives. The cost and disclaimer provide additional usage 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=true and destructiveHint=false. The description adds valuable behavioral context: cost of 1u per call, approximate cost of $0.01, and daily quota deduction. It also mentions attribution to platform and lead time, clarifying output structure.

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 define the core purpose and a third adds cost information. Front-loaded with the key verb and resource, no fluff. 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?

The description explains the main use case and cost, but lacks details on return format or pagination behavior, which is notable given no output schema. Adequate but leaves gaps for an AI agent to fully understand what data is returned.

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

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

Schema description coverage is only 33% (only 'rationale' has a description). The tool description does not elaborate on 'symbol' or 'limit' meaning. With low coverage, the description should compensate but fails to add parameter semantics beyond what the schema provides.

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

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

The description clearly states the tool surfaces pre-announcement social chatter for a ticker, attributed to platform with lead time. It distinguishes from siblings like 'get_signals' by emphasizing 'inbound-beats-outbound signal' and retail chatter examples like HotCopper.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for pre-announcement signals via examples, but lacks alternatives or exclusions among the 24 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?

The description adds behavioral context beyond annotations: it explains that signals are derived from public order books, how direction and confidence are determined, and warns that volume indicates market depth not certainty. 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 well-structured with the purpose front-loaded, but it is slightly verbose. Every sentence adds value, though some details about parameter semantics are missing.

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 comprehensively explains return fields, cost, source, and interpretation. It is sufficient for an agent to understand what the tool returns and its 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 only 25%, yet the description does not explain the 'adapter' or 'limit' parameters, and only implicitly references 'ticker'. The description fails to 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 it returns recent prediction-market signals for a single ticker, sorted by most-recent first, and lists the fields in each row. It is specific but does not explicitly distinguish from the sibling tool 'get_signals', which may also return prediction-market signals.

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

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

The description provides a clear usage context: 'Use to answer what are prediction markets pricing for this ticker right now?'. It also mentions cost and daily quota, but does not explain when not to use the tool or suggest alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it explains the citation marker system, indicates that orphan citations fail, and mentions the cost and daily quota deduction. 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 extremely concise, using two sentences to convey the core purpose and citation behavior, plus a brief cost note. Every sentence adds value, and the main function 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?

Given 7 parameters, low schema coverage, and no output schema, the description is incomplete. It lacks details on parameter formats, return structure beyond citations, and limitations. For a complex synthesis tool, more contextual information is needed for correct invocation.

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

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

Schema description coverage is only 14%, but the description only adds meaning for the mode parameter by describing the three persona types. It does not explain format, window, max_length, custom_prompt, or the required rationale beyond its own in-schema description. This insufficiently compensates 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 that the tool generates a persona-shaped LLM synthesis for a ticker, specifying three distinct mode options (trader card, journalist report, investor thesis). This differentiates it from sibling tools like get_sentiment or get_quote, which offer different analytical outputs.

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

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

The description implies the tool should be used when a persona-shaped narrative is needed for a ticker, but it does not explicitly state when to use it versus alternatives like get_sentiment or get_lead_signals. No exclusions or specific contexts 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?

Beyond the annotations (readOnlyHint=true), the description adds key behavioral details: data sources (Stonkwatch vs Yahoo Finance), cost (1 unit per call), quota deduction, and the limitation of no social coverage for US. This fully discloses operational and data provenance characteristics.

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 for purpose and behavior, one for cost. Every sentence adds unique value, and the most important information (what it does) 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 covers tool purpose, market options, data sources, and cost. However, without an output schema, it does not explain the return format (e.g., price as number, quote object), which would be helpful for an agent to parse 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 only 33% schema coverage, the description compensates by explaining the 'market' parameter with valid options and aliases (asx, us, nasdaq, nyse). However, the 'symbol' parameter lacks any description beyond being a string, and 'rationale' is already 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 it provides a 'market-aware price quote for a single symbol,' and distinguishes between ASX and US markets with specific data sources. It effectively separates this tool from siblings like 'get_signals' or 'get_sentiment' by focusing solely on price quotes.

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 context on when to use each market ('market='asx'' vs 'market='us'') and explicitly notes that US quotes lack social intelligence coverage, guiding agents away from using it for US social data. However, it does not explicitly compare to alternative quote tools or state when not to use the tool entirely.

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 valuable behavioral context beyond annotations by stating that attributions are probabilistic and that certain evidence tiers are not confirmed causal signals. It also notes the cost and quota impact, enhancing 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 relatively concise, with about five sentences. It front-loads the main purpose but includes some details like cost that are useful. Could be slightly tighter, but overall efficient.

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

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

The description explains return fields and probabilistic nature but omits details on pagination parameters (limit, offset) and adapter usage. For a read-only firehose tool, more completeness about defaults and constraints 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?

With only 25% schema description coverage, the description fails to elaborate on parameters beyond the rationale. It does not explain limit, offset, or adapter, leaving their semantics unclear.

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 (get), resource (recent spike attributions), and scope (across all tickers). It distinguishes from sibling tools like get_attribution_chart and get_attribution_graph by emphasizing the 'firehose' nature.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions probabilistic signals and cost but lacks context for when not to use it or comparisons with 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 indicate readOnly and non-destructive nature. The description adds cost per call and daily quota deduction, which is valuable behavioral context beyond the 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?

The description is relatively short (two paragraphs) with purpose upfront. It efficiently covers core functionality and cost. However, it could be more structured (e.g., separating parameter details). No superfluous 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 no output schema, the description adequately lists return fields (score, confidence, counts, comments with backlinks). However, missing explanation for the 'market' parameter and no guidance on parameter interdependencies leaves some 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 only 25% schema description coverage and no description for 'market' and 'ticker', the description fails to compensate. It only explains the 'window' default and 'rationale' requirement. Parameter meaning is largely left to the schema, which is sparse.

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, excluding manipulators. It distinguishes from siblings like get_sentiment or get_signals by specifying the reputation mechanism and return details.

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 a window parameter default but does not explicitly state when to use this tool versus alternatives (e.g., get_sentiment for raw sentiment, get_signals for lead signals). Usage context is implied but not explicitly guided.

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 readOnlyHint=true and destructiveHint=false. The description adds the cost of 1 unit per call and mentions it deducts from daily quota, which is helpful behavioral context. 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 concise with two short paragraphs: one for output summary, one for cost. No redundant sentences, though it could be better 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?

Lacks output schema, but description lists key return fields (score, label, post counts, volatility, trend). However, it does not specify data types or possible label values. With 4 parameters and no output schema, completeness is 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?

Schema coverage is low (only rationale has a description). The description adds minimal parameter insight beyond mentioning 'over a timeframe' for timeframe, but no format or constraints. It does not sufficiently compensate for the lack of schema descriptions.

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

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

The description clearly states it returns aggregated social sentiment (weighted average score, label, post counts, volatility, trend) for a ticker over a timeframe. It distinguishes itself as 'the synthesised SENTIMENT facet humans see, as a standalone tool', implying it is distinct from more granular or other facet tools. However, it could more explicitly differentiate from siblings like get_market_signals or get_signals.

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

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

The description mentions cost and quota but provides no guidance on when to use this tool versus alternatives (e.g., get_market_signals, get_signals). It does not specify prerequisites or scenarios where this tool is preferred.

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 destructiveHint=false. Description adds cost per call, quota deduction, and x402 payment method, which are behavioral traits not in 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?

Two concise paragraphs, front-loaded with purpose. Every sentence adds distinct value (purpose, filters, audience, cost). No unnecessary words.

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

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

Covers purpose, usage context, and cost, but omits return format, pagination details, and typical response structure. For a tool with 12 parameters and no output schema, more completeness is warranted.

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 8% (only 'rationale' described). Description lists filter categories (platform, verified, engagement, sentiment confidence) but does not detail parameters like sort, limit, since, until, cursor, sentiment, min_confidence, min_engagement. Adds some semantics but insufficient for 12 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?

Description explicitly states 'Raw attributed social posts for a ticker with filters', specifying verb (get) and resource (signals). It distinguishes from siblings like 'get_lead_signals' and 'get_market_signals' by emphasizing raw, unsynthesized 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?

Clearly describes as 'Breadcrumb endpoint for journalists and traders — not the synthesised view', providing context on appropriate users and contrasting with synthesised alternatives.

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

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

Adds behavioral context beyond annotations: probabilistic attribution, evidence tier meaning, and cost implications. Annotations already declare read-only, non-destructive nature, but description enhances with nuance about confidence classes.

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 covering key return content and cost. No redundant information. Front-loaded with 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?

No output schema, so description should detail return structure. Mentions types of data (posts, attribution rows) but lacks field-level specifics. Adequate for basic understanding but incomplete for complex usage.

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% (spike_id lacks description). Tool description does not clarify spike_id format or provide additional parameter meaning. Rationale description is already in schema. Description fails to compensate for missing schema 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?

Description clearly states it returns full detail for a single social spike, including contributing posts and attribution rows. Distinguishes from sibling tools like get_attribution_chart by being the comprehensive view.

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. Does not specify prerequisites or scenarios where siblings might be preferred. Cost note is useful but not usage 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=true, so the description adds value beyond that by disclosing the cost (1 unit per call) and the behavior of mode changing defaults only. 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 exceptionally concise: two sentences plus a cost line, with the key concept 'Composite stock snapshot' front-loaded. Every sentence adds value with 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 and no output schema, the description covers include and mode but omits details on window and signals_limit. It explains the core concept but leaves the agent to infer or guess other parameter behaviors, making it marginally 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 description coverage is only 17%, and the description only explains include[] and mode. Parameters like window and signals_limit lack any documentation in both schema and description. The description does not compensate fully for the 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 'Composite stock snapshot' and lists the specific data slices (price, sentiment, etc.) it can return. This distinguishes it from sibling tools like get_quote or get_sentiment, which focus on individual 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 explains that only requested slices via include[] are returned, implying when to use the composite tool. However, it does not explicitly state when to prefer this over individual slice tools or provide exclusion criteria, leaving some ambiguity for the 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral details: cost of 1u (~$0.01, deducts from daily quota) and that it computes lead/lag. No contradictions. Description adds value beyond annotations.

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

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

The description is extremely concise: two short sentences plus a cost note. Every sentence adds value—purpose, key output, and cost. 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 tool has 9 parameters, no output schema, and low parameter documentation, the description should provide more context on return structure, pagination, filtering, and event types. It lacks completeness for effective use without additional investigation.

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 (11%), with only the 'rationale' parameter having a description. The tool description does not explain any parameter meanings or provide formatting guidance, such as for 'symbol', 'mode', 'limit', 'since', 'types', 'until', 'cursor', or 'min_importance'. This leaves the agent with limited understanding of parameter 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 tool's purpose: merging time-ordered events for a ticker and computing lead/lag between social chatter and official filings. It uses specific verbs (merges, computes) and distinguishes from siblings like get_announcement_summary, get_sentiment, and get_signals by focusing on the 'did retail know first' question.

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 indicates the tool is for answering whether retail knew first via lead/lag analysis, which guides when to use it. However, it does not provide explicit exclusions or comparisons to siblings, missing an opportunity to clarify 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds useful behavioral context: cost (1u per call, ~$0.01 via x402) and daily quota deduction. 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?

Two sentences plus a cost line, front-loaded with purpose. Every word earns its place; no fluff.

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

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

Despite clear purpose and cost info, the description lacks parameter explanations and return value expectations. With no output schema, the agent needs more detail on what the tool returns (e.g., a ranked list). Missing parameter behavioral context (e.g., allowed values for mode/window).

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% (rationale has description). The tool description does not explain parameters mode, limit, or window, which are critical for correct invocation. The rationale parameter is described, but the others are left to 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 ranks ASX stocks by membrane-potential activity score, distinguishing it from siblings like get_quote or get_signals. However, 'membrane-potential activity score' is jargon that may require domain knowledge.

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

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

No explicit guidance on when to use this tool versus alternatives. The phrase 'Discovery entry point' implies a starting point but does not provide when-not 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?

Annotations declare destructiveHint=true, which aligns with the description's mention of cost and quota deduction. The description adds behavioral context beyond annotations by detailing the cost structure and the follow-up fetch endpoint, though it doesn't elaborate on error handling or the exact number of pulls granted.

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

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

The description is extremely concise—two sentences plus a cost note—with the main action and key detail front-loaded. 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?

The description covers the core action, cost, and next steps (fetch endpoint). For a simple two-parameter purchase tool with no output schema, it is fairly complete. However, it lacks information on error scenarios, refunds, or what exactly the 'batch of pulls' entails, which would improve completeness.

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

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

The input schema already describes both parameters well ('product' with example slug, 'rationale' as reason). The description adds no further semantic value beyond what the schema provides, so the baseline score of 3 is appropriate given 100% 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 purchases access to a dataset and specifies the exact resource (ASX social-intelligence dataset). It distinguishes from sibling tools like 'get_sentiment' or 'search' by focusing on the purchase action and subsequent data fetch 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?

The description includes cost and quota impact, signaling when to use (when dataset access is needed). It does not explicitly state when not to use, but the context of sibling tools strongly implies this is the only purchasing tool. Some may want clearer prerequisites (e.g., API key requirement) but overall adequate.

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 destructiveHint=false. The description adds cost information (1 unit per call, ~$0.01, deducts from daily quota), which provides useful behavioral context beyond annotations.

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

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

The description is two sentences plus a cost line, about 30 words, front-loaded with the primary purpose. Every sentence adds information without redundancy, achieving high 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 search tool with no output schema and four parameters (two undocumented), the description provides the core purpose and cost. It is mostly complete given its role as an entry point, but could mention return behavior or optional parameter defaults.

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

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

With only 25% schema description coverage (only rationale has a description), the tool description explains the query parameter as the search string to resolve to a ticker. However, it does not describe the 'type' or 'limit' parameters, leaving their semantics to inference.

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 resolves a query to a canonical ticker entity, using the specific verb 'resolve' and resource 'canonical stonkwatch ticker entity'. It further positions itself as the entry point for all session workflows, clearly distinguishing it from sibling tools that retrieve specific 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 explicitly calls it the 'entry point for all session workflows', implying it should be used first before other tools. However, it does not provide explicit when-not-to-use guidance or mention alternative tools like get_quote or get_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?

Annotations indicate destructiveHint=true (modifying state) and readOnlyHint=false. The description adds cost details (1u per call, deducts from daily quota) and mentions that feedback is mined to improve tools, implying persistence. 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 brief and front-loaded with purpose. Each sentence adds value. However, it could be slightly more structured (e.g., separating usage guidelines from cost info).

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 tool's high-level purpose and when to use it, and mentions cost. However, it does not explain return values (no output schema) or parameter semantics (6 parameters, 0% coverage). For a feedback tool with required parameters, more detail is needed for agents 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?

Schema description coverage is 0%, meaning the description does not explain any parameter individually. While the description advises to 'include what you were trying to do', it does not map this to specific parameters like attempted_action or blocker. The agent lacks guidance on how to populate each field correctly.

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: to submit feedback when a tool fails, with specific use cases (blocked, wrong shape, missing parameter, ambiguous docs). It distinguishes itself from sibling tools, which are mostly data retrieval tools (get_*).

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 call it (blocked, wrong response shape, missing parameter, ambiguous docs) and what to include (what was attempted). Provides clear context for usage, though it does not explicitly state 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.