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

Annotations already declare readOnlyHint=true, and the description adds behavioral context by specifying the time scope (current/most recent session) and the metrics returned, which enhances transparency without 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?

Description is concise (two sentences), front-loaded with purpose, and includes all necessary information without extraneous text.

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

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

Given the single parameter and the presence of an output schema, the description sufficiently explains the return metrics. It is complete for a simple data 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 100% with a single parameter 'ticker' well-described. Description does not add additional semantics beyond the schema, so baseline score applies.

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

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

Description clearly states it retrieves intraday accumulation/distribution metrics for the current or most recent trading session, listing specific metrics like VWAP, volume above/below VWAP, etc. It is distinct from sibling tools which focus on other data types.

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

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

Provides a usage context ('Use for assessing real-time buying/selling pressure') but lacks explicit when-not-to-use or alternative tools. Implied usage is reasonable but no exclusions or comparisons.

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?

Description matches readOnlyHint annotation (no contradiction). It adds value by specifying the data fields returned, 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?

Two sentences: first states purpose and data, second gives usage guidance. No waste, front-loaded with essential information.

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

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

Given the tool's simplicity (one required parameter, has output schema), the description covers purpose, returned data, and usage guidance completely.

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 description does not need to add parameter details. The schema already describes 'ticker' well. Description does not provide extra parameter-level information.

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

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

The description clearly states it gets analyst consensus for a company, listing specific data points (average target price, number of analysts, buy/hold/sell breakdown, consensus recommendation). It distinguishes itself from sibling tools like get_price_target and get_analyst_estimates.

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 when evaluating Wall Street sentiment or price targets.' Provides clear context, though no explicit exclusions or alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint=true, so the description's role is limited. It adds that the tool provides grades, targets, and coverage breadth, but lacks details on data recency, pagination, or number of firms. It does not contradict annotations.

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

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

The description is a single, well-structured sentence that front-loads the action ('Get aggregated analyst coverage') and concisely explains the output. No superfluous words.

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

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

Given the tool's low complexity (one required parameter, annotations provided, output schema exists), the description sufficiently explains the tool's purpose and output. It does not need to detail return values since the output schema covers that.

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

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

There is only one parameter (ticker) with schema description coverage at 100% (it describes the ticker symbol format). The description does not add additional semantic meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Get aggregated analyst coverage for a ticker — consolidated view of grades, targets, and coverage breadth across covering firms.' It uses a specific verb and resource, and distinguishes itself from siblings like get_analyst_consensus, get_analyst_estimates, and get_analyst_grades by highlighting aggregation and breadth.

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 description implies an aggregated view but does not specify situations where this is preferred over individual analyst tools. No 'when not to use' or mention of prerequisites.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to cover safety. It adds the behavioral context of returning forward estimates with specific metrics. No contradictory or missing behavioral details, but doesn't discuss rate limits or performance.

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

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

Two sentences, front-loaded with purpose and key details, immediately followed by usage guidance. No wasted words or redundant information. Perfectly concise for an AI agent.

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

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

Given the output schema exists (not shown but implied), the description adequately covers the return content and period options. It doesn't mention pagination or error handling, but for a straightforward financial data tool, it is sufficiently complete.

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

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

The description adds meaning beyond the schema by explaining that estimates include low/high/avg and analyst counts. Schema coverage is 100%, so baseline is 3; the description enriches it further with context about the returned data fields.

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 'Get forward analyst estimates for a company' and lists specific metrics (EPS, revenue, EBITDA, net income) with low/high/avg and analyst counts. It distinguishes from sibling tools like get_analyst_consensus by implying it provides detailed estimates rather than a single consensus figure, though not 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 direct usage suggestion: 'Use when analyzing forward earnings expectations or revenue forecasts.' This gives clear context. However, it does not mention when not to use it or provide alternatives, which would be helpful given many sibling tools.

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

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

Annotations already declare readOnlyHint=true, indicating a safe read. The description adds that it returns 'recent' actions, providing temporal context. No contradictions, and the added context is valuable but could specify ordering or depth of recency.

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

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

The description is a single sentence of 14 words that efficiently conveys purpose and output scope with no unnecessary details.

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

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

For a simple retrieval tool with an output schema (context indicates present), the description covers the key aspects: what actions, for which ticker, and what fields are returned. It is sufficiently complete without needing to explain return values in prose.

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 parameters are adequately described in the schema. The description adds minimal parameter-specific meaning beyond mentioning 'for a ticker' and the types of grades in the output.

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

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

The description clearly states the tool gets recent analyst grade actions (upgrades, downgrades, initiations) for a ticker and lists included fields (firm, previous/new grade). It distinguishes from siblings like get_analyst_consensus and get_analyst_estimates by specifying actions.

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

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

The description implies use for retrieving ticker-specific analyst grade changes but does not explicitly state when to use this tool vs alternatives (e.g., get_price_target, get_analyst_consensus) or provide exclusions.

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

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

The description goes far beyond the readOnlyHint annotation. It discloses critical behavioral traits: always returns 200 regardless of success, must read internal fields not HTTP status, partial coverage and what not_covered means, null/absent meaning not measured, 0 being measured, as-of date semantics, share rebasing, and the 403 feature-tier behavior. This is exactly the kind of side-effect/interpretive info an agent needs, and it is consistent with annotations.

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

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

The description is very long and contains some redundancy, e.g., 'NULL, absent or withheld means NOT MEASURED' is repeated several times with slightly different phrasings. It is front-loaded with the purpose, but the many caveats, while valuable, could be tightened. It is not minimal, though every major sentence adds unique 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?

For a complex regulatory calculation tool with many edge cases, the description is exceptionally complete. It covers interpretation of every non-obvious response state (constraintApplies false, suppressed, not_covered, null, 0, stale as-of, rebasing, 403) and explicitly warns against common misreporting. The output schema exists, so return-structure details are not needed here.

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

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

The schema already fully documents the single 'ticker' parameter (100% coverage). The description does not add any additional meaning about the parameter itself, so the baseline of 3 applies. It doesn't hurt or help beyond the schema.

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

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

The description states a specific verb ('Get') and resource ('SEC Form S-3 General Instruction I.B.6 baby shelf capacity') and explains exactly what the tool computes (raisable amount under the one-third cap, given public float and takedowns). It also lists the returned fields. This clearly distinguishes it from the many sibling get_* tools by naming a unique regulatory concept.

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 on when the cap applies or not (float below/above $75M), how to interpret suppressed/null/not_covered outcomes, and when the tool returns 403. It does not explicitly mention alternative tools or say 'use this instead of X', but the subject matter is so specific that implicit usage is strong. Since there is no explicit exclusion of siblings, it stays at 4 rather than 5.

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

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

Beyond the readOnlyHint annotation, the description discloses deduplication logic (annual preferred over quarterly) and chronological sorting. It also mentions the return structure, providing rich behavioral context.

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

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

Three concise sentences deliver core functionality, return format, dedup logic, and feature-gating. No fluff or redundancy.

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

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

Given the output schema exists, the description appropriately provides a high-level overview of the output structure. It covers source, range, dedup, and access constraints, making it complete for a simple one-parameter tool.

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

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

Schema coverage is 100%, but the description adds value by stating the ticker must correspond to a company with SEC filings, which conditions the parameter's validity. This goes beyond the schema's generic ticker description.

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 up to 10 years of quarterly cash position history from SEC XBRL filings, specifying data source, time range, frequency, and output format. It uniquely identifies the tool's purpose among siblings like get_cash_position and get_cash_runway_calendar.

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

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

The description explicitly states it's not feature-gated and works for any company with SEC filings, providing clear context for when to use it. While it doesn't name exclusions or alternatives, the unique purpose differentiates it from 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 goes far beyond the readOnlyHint annotation by disclosing that the endpoint always returns HTTP 200, that `available:false` with reason `snapshot_not_generated` means 'not analysed yet' rather than no cash data or outage, and that only `scenarios.closed` is populated. It also calls out the 403 FEATURE_NOT_AVAILABLE tier behavior. This is rich, non-obvious behavioral context that an agent needs to interpret responses correctly. No contradiction with readOnlyHint=true.

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 opening sentence front-loads the core purpose, and every subsequent sentence carries a distinct operational warning or model-scope caveat. It is longer than average, but the length is justified by the unusual always-200 and partial-coverage semantics.

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 a single parameter and an output schema, the description still covers the non-obvious pieces the schema cannot convey: response meaning, failure modes, scenario-envelope limitations, and licensing behavior. Nothing an agent needs to invoke or interpret this tool correctly is missing.

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

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

The schema already fully documents the only parameter (`ticker`, 100% coverage), so the baseline of 3 applies; the description does not need to add parameter semantics and adds none that are material.

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

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

States a specific verb ('Get'), a specific resource ('Signal8 cash position model'), and enumerates its components (anchor cash, monthly burn, raises, runway months), so an agent can immediately tell what data it returns. The 'current cash situation / runway / capital raise activity' phrasing distinguishes it from cash-history and runway-calendar siblings, even without naming them.

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

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

Explicitly states the trigger condition: 'Use when analyzing a company's current cash situation, runway, or capital raise activity.' It does not name alternative tools or give when-not-to-use guidance beyond the coverage caveat, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, but the description adds valuable context that the runway is an estimate based on current burn rate and depends on future events, going beyond the annotation.

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

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

The description is extremely concise with no wasted words. Core function is front-loaded, followed by defaults and caveats.

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 moderate complexity, full schema coverage, and the existence of an output schema, the description provides sufficient context about purpose, sorting, defaults, and the estimate nature of the runway.

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%, and the description does not add per-parameter details beyond the schema. Baseline score of 3 is appropriate as the schema already documents parameters well.

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 finds companies projected to run out of cash within a date window. It distinguishes itself from sibling tools by comparing to lockup expiration calendars and specifying it's for cash depletion events.

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

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

The description provides clear context for when to use (finding companies running out of cash) and mentions default window, but lacks explicit when-not-to-use or alternatives among siblings.

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

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

Annotations declare readOnlyHint=true, so the safety profile is clear. The description adds no further behavioral details such as pagination, data freshness, or limitations. Since annotations already cover the key behavior, the description provides minimal added value beyond the structured field.

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 key purpose, and contains no redundant or extraneous words. Every part contributes to understanding the tool's role.

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 presence of an output schema (not shown but indicated) and a simple parameter set, the description provides sufficient context for using the tool. It could mention that it returns a list of trials with specific fields, but overall it is adequate for a straightforward retrieval tool. The sibling search_clinical_trials might require more differentiation, but the current description still offers good 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?

Schema description coverage is 100%, with both parameters (ticker, limit) documented. The tool description mentions output fields (trial phase, status) but not parameters. It adds little additional meaning beyond what the schema already provides for the parameters, justifying the baseline score of 3.

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

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

The description clearly states the verb (Get), resource (clinical trial data), and context (for a biotech/pharma company), listing included data fields like trial phase and conditions. However, it does not explicitly differentiate from the sibling tool search_clinical_trials, which likely performs a similar but search-oriented function.

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 use context ('when analyzing a biotech company's pipeline or upcoming catalyst events'), but does not give when-not-to-use guidance or contrast with the sibling search_clinical_trials. The usage scenario is implied but not explicit about 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?

The description adds behavioral details beyond the readOnlyHint annotation: it explains the tool returns trading-halt status fields (halted/haltCode/haltedAt) and clarifies the behavior when trading normally (false/null). It also states this is a 1-credit operation, providing cost context.

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

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

The description is two sentences, efficient and front-loaded. Every sentence adds value: first sentence states purpose and outputs, second sentence provides usage guidance and behavioral note.

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 is a simple lookup with one parameter and an output schema exists, the description covers all essential aspects: what it does, when to use, what it includes, and a special behavioral note about trading halt status.

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 covers the single parameter ticker with a clear example. The description does not add deeper semantic meaning to the parameter but reinforces its purpose. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states it retrieves an enriched company profile using a ticker symbol and lists specific returned fields (CIK, exchange, sector, etc.). It also distinguishes from a 'full bundle' tool, helping the agent understand its 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 advises using this for basic company info rather than the full bundle, and notes it is a lightweight lookup (1 credit). It does not explicitly name a sibling tool for the full bundle but provides clear guidance on when to use this tool.

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

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

The description adds behavioral context beyond annotations: it discloses the 25-credit cost, the comprehensive nature (combining SEC, market, and exchange data), and the fact it runs multiple compliance checks. This enriches the readOnlyHint annotation without contradiction.

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

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

The description is two sentences front-loaded with the core purpose, followed by details on what it covers and a cost note. 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 the presence of an output schema (so return values are documented elsewhere) and 100% schema coverage for the single parameter, the description is complete. It explains what the tool does, its scope, and cost, providing sufficient context for an AI agent.

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

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

The input schema has 100% coverage with one parameter 'ticker' described as 'Stock ticker symbol.' The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get full compliance rules evaluation for a company.' It specifies what it runs (Nasdaq/NYSE deficiency detection, bid price tracking, delinquent filing detection) and what it combines (SEC filing data, market data, exchange rules), making it distinct from siblings like get_insider_transactions or get_filing_document.

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 as the most thorough compliance check, with a cost of 25 credits. It provides context about the scope but does not explicitly state when to use vs. alternatives or when not to use it. A brief mention of when to prefer this over lighter tools would improve 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 carries a heavy burden beyond the readOnlyHint annotation, and it delivers: it discloses that the call ALWAYS returns 200 and requires reading `available` and `reason` rather than HTTP status, that not_covered means not analyzed (not no dilution or outage), that null/absent/withheld means NOT MEASURED (never zero), and that outOfScope is about product coverage not the company. It also explains the 403 for non-Pro users. These are critical behavioral nuances that annotations alone do not provide.

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

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

The description is long but each sentence adds substantive information about interpretation, error handling, or tier requirements. It front-loads the purpose and usage, then details semantic pitfalls. While a more structured format (e.g., bullet points) would improve scannability, the length is justified by the complexity of the tool's semantics and there is no redundancy or filler.

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

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

For a tool with high semantic complexity (distinguishing not_covered from no dilution, null vs measured zero, outage vs unavailable, outOfScope meaning, tier requirements), the description covers all essential operational pitfalls. It also relies on the existing output schema for return-value details, so no gap remains. An agent can call this tool correctly and interpret its response without additional 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 covers the single parameter (ticker) with a clear description and 100% coverage, so the baseline is 3. The tool description adds no additional parameter-level detail beyond the schema, but none is needed for a simple ticker string. It does not compensate for any schema gaps because there are none.

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

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

The description states a specific purpose: a cheap pre-check for whether Signal8 holds a dilution analysis for a company, and enumerates exactly what it returns (coverage status, extraction state, timestamps, tier, out-of-scope flag). It explicitly differentiates from the expensive dilution tools by instructing to call this first, so an agent can distinguish it from siblings like get_dilution_history or get_dilution_snapshot without opening their schemas.

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

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

The description gives explicit when-to-use guidance: 'CALL THIS FIRST before the expensive dilution tools' and explains it answers 'is there anything to fetch' at a fraction of the cost. It also provides exclusion criteria for interpretation (e.g., not_covered vs outage, null vs 0) and mentions the Pro-tier requirement, making it clear when this tool is applicable 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?

With only readOnlyHint=true in annotations, the description adds a great deal of behavior: 200-always responses, split-basis caveats, series gaps, coverage semantics, NULL/zero meaning, as-of dates, and tier requirements. However, the split-basis statements are internally inconsistent ('as filed ... NOT rebased' vs 'rebased onto a single split basis'), which prevents a 5.

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

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

The description is front-loaded with purpose, but the warning section is long and repeats the same NULL/not-measured idea multiple times. The content is mostly useful, but it is not concise.

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

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

For a deceptively complex tool, the description covers sourcing, overlays, error handling, null semantics, coverage vs outage, tier gating, and rebasing. The internal split-basis contradiction and the lack of an explicit response-format note are the remaining gaps, though an output schema exists.

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

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

The schema already describes ticker with 100% coverage, so the description is not required to add parameter detail. It adds no new meaning beyond the schema for the single parameter.

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

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

The description names a specific verb ('Get') and resource ('historical shares-outstanding and cash series') and clarifies the data source and overlays. This clearly differentiates it from sibling tools like get_cash_history and get_split_history.

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

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

It explicitly says to use it for share-count growth over time and cash trajectory between financings, and includes strong cautions about split boundaries and unavailable coverage. It does not explicitly name when-not-to-use alternatives, so it stops short of a 5.

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

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

Annotations only declare readOnlyHint=true; the description carries the full burden and exceeds it. It discloses credit cost, always-200 behavior, row-level withholding semantics, not_covered vs outage, null/zero interpretation, as-of date caveats, split rebasing, and tier-gated 403 behavior. This is far beyond annotation coverage and enables correct handling of ambiguous responses.

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?

Long but dense: every paragraph covers a distinct critical behavior (withholding, availability, null semantics, as-of, tier). Front-loaded with the core purpose and family list before caveats. Slight redundancy between 'Never report a company as having no dilution...' and the NULL/absent/withheld sentence, but overall well organized and justified by the tool's interpretation-sensitive response.

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?

Exceptionally complete for a read-only tool with 2 params and an output schema. The description covers credit cost, per-field traceability, withholding/lower-bound semantics, availability/reason fields, coverage vs outage, NULL interpretation, as-of date, split rebasing, and tier gating. An agent has everything needed to call the tool and interpret ambiguous responses correctly.

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

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

Schema description coverage is 100%: both family and ticker are already described in the input schema, so baseline is 3. Description adds marginal meaning by noting 'one family per call' and reinforcing the family list, but does not materially enrich parameter semantics beyond the schema.

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

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

States a specific verb and resource: 'Get ONE instrument family's rows' with per-field SEC citations, and enumerates all ten families. This clearly distinguishes it from sibling dilution tools like get_dilution_snapshot or get_dilution_history, which focus on different aspects of dilution 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?

Provides clear context for use: 'One family per call — request the families you actually need rather than sweeping all ten.' It also explains the tier requirement (Signal8 Pro, 403 otherwise). However, it does not explicitly name alternatives or state when not to use this tool versus a sibling dilution tool.

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

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

Beyond the readOnlyHint annotation, the description discloses extensive behavioral nuances: the tool always returns 200 and requires reading `available` and `reason`; coverage is partial (`not_covered` vs no dilution vs outage); NULL/absent values mean 'not measured' never zero; numeric 0 is a measured zero; data is as-of a date with stale-date caveats; share counts are rebased with omitted rows; and a Pro-tier requirement returning 403. This goes far beyond the annotation and gives the agent critical interpretation guidance.

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 highly verbose and repetitive. For example, the warning 'NULL, absent or withheld means NOT MEASURED' appears in different phrasings multiple times, and the 'not_covered' explanation is also repeated. While the content is structured (purpose → usage → warnings), it does not earn every sentence's place; many warnings could be consolidated. The front-loading of the purpose is good, but the overall length is disproportionate for a single-parameter read-only tool.

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

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

Given the data's interpretive complexity (null vs zero, coverage distinctions, HTTP status behavior, staleness, share rebasing) and the presence of an output schema, the description covers every edge case an agent needs to avoid misreporting. It even addresses subscription-tier requirements and error codes. Nothing essential is missing for correct invocation and interpretation.

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

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

The only parameter is `ticker`, which is fully described in the schema ('Stock ticker symbol (e.g., "MNTS", "VNRX")'). The description adds no additional meaning about the parameter itself—no format validation, no examples beyond the schema, no mention of case sensitivity or exchange. Since schema coverage is 100%, the baseline of 3 applies, and the description does not elevate it.

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

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

The description opens with a specific verb-resource pair ('Get post-offering price performance') and explicitly states the data scope: 'for each recorded offering, how the stock traded after it priced or closed.' It also adds a clear use-case sentence. This distinguishes it from siblings like get_dilution_history or get_dilution_coverage, which focus on dilution amounts/coverage rather than post-offering price action.

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

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

The description provides a clear usage context: 'Use when assessing how the market has absorbed this issuer's past financings.' This tells the agent when to invoke the tool. However, it does not explicitly mention when not to use it or name alternative tools (e.g., get_dilution_risk for risk assessment), so it lacks the explicit exclusions/alternatives that would earn a 5.

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

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

The description goes far beyond the readOnlyHint annotation, explaining critical behaviors: the score denominator can shrink, levels are lower bounds, HTTP 200 is always returned, coverage gaps are not zero-risk, and null semantics. This is exceptional transparency for correct agent interpretation.

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

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

The description is long but densely packed with critical warnings, front-loaded with the core output and key caveats. The emoji markers aid visual scanning, though a slightly tighter rewrite could reduce redundancy while keeping all necessary warnings.

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

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

Given the complexity of the metric and the existence of an output schema, the description covers every ambiguity an agent might face: denominator handling, lower bounds, coverage gaps, null semantics, as-of dates, share rebasing, and tier gates. It is fully self-sufficient for correct 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?

The schema already fully describes the single required parameter with 100% coverage. The description adds no additional parameter-level details (e.g., ticker format is given in the schema), so the baseline of 3 applies without extra compensation needed.

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

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

The description states a specific verb ('Get') and resource ('dilution pressure score') with a 0-100 score, a seven-component breakdown, and four risk levels. This clearly differentiates it from siblings like get_dilution_snapshot or get_dilution_history by naming the exact metric produced.

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 defining the tool's output and includes a prerequisite (Signal8 Pro tier). However, it does not explicitly compare with sibling tools or state when to prefer this over get_dilution_snapshot or get_dilution_instruments, so guidance on alternatives is missing.

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

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

Beyond the readOnlyHint annotation, the description discloses critical behavioral traits: 25-credit cost, always-check-available/reason semantics, null-versus-zero meaning, rebasing of share counts, and the float/runway interpretive traps. However, it says 'ALWAYS RETURNS 200' and then later says the call returns 403 without Pro, which is an internal inconsistency that slightly undermines the 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 long but well organized, front-loading the purpose and cost and then grouping key warnings by topic with clear markers. Some redundancy exists, such as the repeated add-on purchase clarification, but every major caveat earns its place for a costly tool with many traps.

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 having an output schema, the description goes beyond it by covering authorization, cost, coverage semantics, missing-data interpretation, as-of date staleness, split rebasing, and the float/runway misuse risks. For a tool with this many edge cases, the definition is effectively complete.

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

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

The input schema has one required parameter, ticker, with a complete description of what it is. The tool description adds contextual warnings about covered vs. uncovered tickers but no additional parameter syntax or formatting details, so it stays at the baseline expected for full 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 names a specific verb and resource: it gets the dilution snapshot header/summary, and it explicitly says what is excluded (instrument rows), which cleanly separates it from get_dilution_instruments and get_dilution_coverage. The scope, contents, and caveats are all clear.

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

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

The description gives explicit routing guidance: call get_dilution_coverage first to avoid paying 25 credits for an uncovered ticker, and call get_dilution_instruments per family because instrument rows are not included. It also explains the 403/Pro-tier condition and covers the not_covered vs. outage distinction, so an agent knows when to use this tool and when not to.

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

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

Annotations declare readOnlyHint=true. Description adds context about aggregate nature and included breakdowns. No contradictions, but could mention data recency or scope ('ALL tracked politicians') more precisely.

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 specifies purpose and outputs, second provides usage guidance and sibling differentiation. No extraneous information.

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

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

Given read-only nature, optional parameters with defaults, and clear output description, the definition fully equips an agent to select and invoke this tool correctly.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description adds minimal extra semantic value beyond what schema already provides (e.g., default cycle behavior). Baseline 3 is appropriate.

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

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

The description clearly states it retrieves market-wide campaign-finance rollups across all tracked politicians for a cycle, listing specific outputs (total raised, top donors, splits, leaderboard). It explicitly distinguishes from sibling tool get_politician_donor_summary.

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 cases ('who are the biggest donors in 2024?') and contrasts with alternative for single politician ('For a single politician, use get_politician_donor_summary').

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

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

Annotations declare readOnlyHint=true, so description need not reiterate. Description adds output specifics but no additional behavioral traits like pagination or rate limits. Adequate for a read-only tool.

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

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

Two concise sentences, front-loaded with purpose. No wasted words.

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

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

Tool is simple with 2 parameters and an output schema. Description adequately covers purpose and output content. Could mention data range or default limit, but sufficient.

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

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

Schema coverage is 100% with both parameters documented. Description does not add parameter-level meaning beyond what schema provides. Baseline score applies.

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

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

Description clearly states it gets historical earnings data with specific fields (EPS, revenue, surprise percentages). However, it does not explicitly differentiate from sibling tools like get_analyst_estimates or get_earnings_calendar.

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

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

Explicitly states when to use: analyzing earnings beats/misses or upcoming expectations. Lacks when-not-to-use or alternative suggestions, but the provided context is 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 indicate readOnlyHint=true, and the description adds behavioral context by listing the returned fields and filter capabilities. It does not conflict with annotations, and the added detail (market cap filtering, specific data fields) is valuable for safe usage.

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

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

The description is three sentences, front-loaded with the main action, and every sentence adds value. No fluff 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 presence of an output schema, the description sufficiently covers the tool's capabilities: date range, ticker filter, market cap filter, and returned fields. No critical information is missing for a read-only data 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?

With 100% schema coverage, the description adds meaning beyond the schema by explaining the purpose of date range parameters and how market cap filtering works (e.g., 'focus on large-cap or small-cap earnings only'). This enhances 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 retrieves upcoming and recent earnings releases between two dates, with optional ticker and market cap filters. It specifies the returned fields (ticker, date, time, EPS estimate, revenue estimate), making the purpose distinct from sibling tools like get_earnings or get_economic_calendar.

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

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

The description provides clear context on when to use (earnings calendar between dates, with optional filters) but does not explicitly mention when not to use or suggest alternatives. It lacks exclusionary guidance compared to 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, indicating a safe read operation. The description adds that events are scheduled and date ranges are inclusive, but does not disclose additional behavioral traits such as rate limits or pagination. Given the annotation coverage, the description adds minimal extra value.

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 with no redundant words. The first sentence captures the core purpose and the second adds optional filter and default. Perfectly front-loaded and 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?

With an output schema present, the description does not need to explain return values. It covers the essential aspects: date range, country filter with default, and examples of event types. For a tool with 3 parameters (2 required) and an output schema, the description provides complete contextual guidance.

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% with detailed parameter descriptions. The tool description adds the default country behavior ('Defaults to US when omitted'), which is extra semantic information beyond the schema. This aids the agent in correctly invoking the tool.

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

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

The description clearly identifies the tool as retrieving scheduled macro/economic events with a specific verb 'Get' and a resource clearly defined. It lists example events (CPI, FOMC, etc.) and specifies date range and optional country filter, making it easy to distinguish from sibling tools that handle different data types.

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

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

The description provides clear context: when to use it (to get economic events between dates) and includes a default behavior (countries default to US). However, it does not explicitly exclude alternatives or contrast with similar tools like get_earnings_calendar, leaving some ambiguity for edge cases.

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

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

Annotations already indicate readOnlyHint=true. Description adds independent caching per data type and the bundling behavior, providing useful 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?

Four sentences, each with a purpose: purpose, data sources, caching, usage guidance. No redundancy, well organized.

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

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

Output schema exists, so return values are documented. Description covers data types, caching, and usage. Lacks mention of prerequisites or rate limits, but sufficient for a read-only bundle 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 covers both parameters with descriptions (100% coverage). The description adds context about include defaults and comma-separated format, but doesn't add entirely new meaning beyond 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 aggregates multiple ETF data sources into one call, explicitly listing the types (profile, holdings, etc.) and distinguishing it from individual siblings like get_company_profile.

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?

Describes when to use (for aggregated data) and how to customize with include/omit, but does not explicitly state when not to use or mention alternatives like individual getters.

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

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

The annotations already mark readOnlyHint=true, so the description's statement is consistent. However, no additional behavioral traits (e.g., pagination, permission needs) are disclosed beyond the annotation.

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

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

Two sentences, front-loaded with purpose and usage; every word is necessary and no filler.

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

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

Given the simple input schema and presence of an output schema, the description is sufficient. It hints at output fields (name, title, compensation, tenure) which compensates for not detailing the return structure.

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% for the single parameter 'ticker', with a clear description. The tool description adds no extra meaning 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 uses a specific verb 'Get' and resource 'key executives and officers'; it clearly identifies the data fields (name, title, compensation, tenure) and distinguishes from siblings like get_insiders by focusing on top executives.

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 when to use (researching company leadership or management quality) but does not mention alternatives or when not to use, leaving the agent to infer from the sibling list.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by explaining truncation behavior and the truncated boolean in the response. 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?

Three concise sentences: purpose, return fields, usage hint. 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?

With an output schema present, the description covers input, usage, and behavior fully. No missing information for an AI agent to use the tool correctly.

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

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

Schema coverage is 100% with clear descriptions. The description adds context about maxLength truncation and the truncated response field, going beyond 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 gets the full text/HTML content of a single exhibit from an SEC filing, with a specific verb and resource. It distinguishes from siblings by referencing get_filing_exhibits for finding IDs.

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

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

It explicitly instructs to use get_filing_exhibits first to find exhibit IDs and mentions the maxLength parameter for truncation. While it doesn't list when not to use, the guidance is clear and actionable.

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

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

Annotations declare readOnlyHint=true, consistent with the read nature. The description adds behavioral context: it returns a forward-looking calendar, default date ranges, and default form types. 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 that are direct and contain no extraneous information. Every word adds value.

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

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

Given the presence of an output schema, full parameter coverage, and read-only nature, the description is complete. It covers purpose, optional filters, and default behavior, leaving no critical gaps.

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

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

Schema coverage is 100% with parameter descriptions. The description adds meaning beyond schema by clarifying it is forward-looking and specifying default behavior (both 10-K and 10-Q). This helps the agent understand default values without inspecting schema defaults.

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 forward-looking SEC filing deadline calendar specifically for 10-K and 10-Q forms. It uses a specific verb ('get') and resource ('filing calendar'), distinguishing it from sibling tools like get_earnings_calendar or get_economic_calendar.

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

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

The description explains optional filters (universe and formTypes) and default behavior (both 10-K and 10-Q). It implicitly guides when to use this tool (when needing 10-K/10-Q deadlines) but does not explicitly state when not to use it or mention 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?

Discloses that filings can be very large (10-K up to 1MB+) and explains truncation behavior via maxLength, including the truncated boolean in the response. This provides behavioral benefits beyond the readOnlyHint annotation, which already indicates no 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, no redundancy. The first sentence states the core purpose, followed by size warning, preview guidance, and response fields. Every sentence adds value.

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

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

Given the output schema exists, the description sufficiently covers return fields and behavior. With only 2 parameters and clear annotations, the description is complete for an AI 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 covers both parameters (filingId, maxLength) with basic descriptions. The tool description adds value by clarifying filingId is numeric and must come from search_sec_filings, and that maxLength triggers a truncated boolean in the response. It enriches the schema but could be more explicit about expected formats.

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 text/HTML content of an SEC filing by its internal filing ID, specifying the verb (Get), resource (filing document), and key context (returns company_name, form_type, etc.). This distinguishes it from sibling tools like search_sec_filings or get_exhibit_content.

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 find filing IDs using search_sec_filings first and mentions maxLength for previews. While not listing alternatives or when-not-to-use, this guidance is clear and contextually sufficient given 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?

Annotations already mark this as read-only. The description adds behavioral context by stating it excludes XML/XBRL exhibits and returns metadata (not full content), which clarifies the tool's scope 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 sentences long, front-loaded with the primary action, and every sentence adds value: listing purpose, return content, and usage guidance. No wasted words.

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

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

Given the tool is a simple listing operation with read-only annotations, an output schema (not detailed but present), and clear parameter description in schema, the tool description provides all necessary context: what it does, what it returns, how to use it next, and what it excludes.

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 100% description coverage for the only parameter (filingId), referencing sibling tool search_sec_filings. The tool description does not add new meaning beyond the schema; it mentions 'within an SEC filing' but does not elaborate on the parameter itself. Baseline 3 is appropriate.

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

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

The description clearly states the tool lists exhibits within an SEC filing, returns metadata (type, description, size), and explicitly excludes XML/XBRL exhibits. It distinguishes itself from get_exhibit_content by positioning this tool as a discovery step.

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

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

The description explicitly tells the agent to use this tool to identify which exhibits to read with get_exhibit_content, providing clear usage context. It also notes that XML/XBRL exhibits are excluded, hinting at alternatives. However, it does not address when not to use this in favor of other sibling tools like get_filing_document.

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

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

Annotations already provide readOnlyHint=true, so the description does not contradict. However, beyond stating the data types and periods, it offers no additional behavioral context (e.g., data source, update frequency, pagination), so it adds minimal value beyond the annotations.

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

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

Two efficient sentences with no wasted words. The first sentence states the action and resource, the second specifies use cases, making it easy to scan.

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 presence of an output schema (mentioned in context signals) and the clear description of the financial statements and period types, the description is complete for an agent to understand what the tool returns and when to use 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 100%, so the baseline is 3. The description echoes the type parameter's enum values but adds no new meaning for 'ticker' or 'limit' beyond what is in the schema. It does not explain default behavior or constraints 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 retrieves income statement, balance sheet, and cash flow data, with explicit period options (annual, quarterly, TTM). This distinguishes it from sibling tools like get_earnings or get_cash_history, providing a specific verb-resource pair.

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

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

The description says 'Use when analyzing revenue, profitability, debt, or cash position,' giving clear context for when to invoke the tool. However, it does not mention when not to use it or suggest alternative tools for related but distinct data (e.g., cash history), missing an opportunity for explicit exclusion guidance.

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

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

Annotations only declare readOnlyHint=true, so the description carries the burden and exceeds it dramatically. It discloses the cardinal null semantics, the meaning of 'floatWithheldReason', the distinction between measured zero and absence, the four stand-in objects and how each may or may not be used, and the caveat about floatDefinition/source presence. This is rich behavioral and interpretive context 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 long and dense, but the length is largely earned given the number of nuanced null/withhold/stand-in cases that materially change how the result must be interpreted. It is front-loaded with the main purpose and cardinal rule, and uses numbered lists and clear labels. It loses one point because a few warnings repeat the 'never treat null as zero' idea across multiple forms, making it less concise than it could be.

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 data-retrieval tool with one parameter, an output schema, and read-only annotation, the description covers essentially every decision an agent needs to make before and after invoking the tool: which float definition is being read, when the float is withheld, what the stand-ins mean, and how to present them. No important call-time or interpretation behavior is left unstated.

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

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

The only parameter, 'ticker', is fully described in the schema with example symbols, so schema coverage is 100%. The description adds no additional ticker-specific format, validation, or behavior details, which is acceptable given the schema already handles it. Baseline 3 applies.

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

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

States a specific verb and resource ('Get float data for a company') and enumerates the core fields returned (floatShares, floatDefinition, as-of date, stand-ins). It is unmistakably about float data, but it does not explicitly contrast itself with sibling get_float_history or other float-related tools, so it falls short of full sibling differentiation.

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

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

Gives a clear usage context: 'Use when analyzing share supply.' It does not provide when-not-to-use guidance or name alternative tools, but the context is specific enough for an agent to select this tool over obviously unrelated ones. No misleading guidance is present.

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?

Description adds critical behavior beyond readOnlyHint: forward-only accumulation starting mid-2026, no backfill, empty rows as normal, source reliability variance, and API tier charging. Predicts expected data patterns and prevents misinterpretation.

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?

Single paragraph, front-loaded with purpose, then usage, then caveats, then cost. Every sentence provides unique value; no redundancy or filler.

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

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

Given historical complexity and presence of output schema, description covers all essential aspects: return fields, usage context, data gaps, source quality, and cost. No missing critical information for agent to decide and use tool correctly.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds context about the lookback window (implicitly tied to 'days') and the point-in-time nature, but does not significantly enhance parameter understanding beyond schema. Still above baseline due to schema covering parameters well.

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 point-in-time float history per trade date, with specific fields (float shares, shares outstanding, source). It distinguishes itself from sibling get_float by highlighting that it shows history across time, not just latest.

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

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

Explicitly states when to use (for historical float queries, dilution events) and when not (latest-only queries serve get_float better). Also advises weighing rows by source quality, guiding proper interpretation.

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. Description adds behavioral context: returns candle format, supports multiple resolutions, default period of 1 year. Adds value beyond annotations without 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 succinct sentences. First sentence states main purpose and resolution options. Second sentence covers period flexibility and use cases. No wasted words. Front-loaded with key 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?

Output schema exists, no need to explain returns. Description covers purpose, usage, parameter behavior, and example use cases. Complete for a data retrieval tool with good annotations.

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

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

Schema has 100% parameter descriptions. Description adds significant extra meaning: explains period shorthand values, default behavior (1Y daily), that from/to override period, resolution default. This goes well beyond 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?

Clearly states verb 'Get' and resource 'historical OHLCV price candles for a stock'. Lists supported resolutions and specific use cases (compute returns, chart, analyze volume). Distinguishes from siblings like get_intraday_bars and get_quote by specifying resolution and period options.

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 clear context for when to use: computing returns, charting, volume analysis. Explains period vs from/to timestamp usage. Doesn't explicitly exclude alternatives but given sibling count, context is sufficient.

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

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

Annotations indicate readOnlyHint=true, and the description elaborates on the analysis performed: identifies clusters with specific criteria (3+ insiders, 14-day window) and interprets the signal as bullish. No contradictions; adds valuable behavioral detail 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?

Two sentences: first states the core function, second details the criteria and implication. Every sentence adds value; no wasted words. Front-loaded with the main action.

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

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

Given the simple single parameter and existence of an output schema, the description fully covers the tool's purpose, criteria, and significance. No 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 single parameter 'ticker' is fully described in the schema with an example. The description does not add any additional semantic meaning or constraints beyond what the schema provides. Baseline 3 due to 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?

Description clearly states the tool detects cluster buying patterns for a company, specifying the trigger condition (3+ distinct insiders within 14 days) and its significance as a bullish signal. This distinctively separates it from sibling tools like get_insider_transactions.

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

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

The description provides context on when to use (to identify bullish insider clusters) but does not explicitly state when not to use or suggest alternatives. It implies use for predictive signals, which is clear enough among many insider 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?

Adds context beyond readOnlyHint: describes searching entire universe, detecting networks and clusters. 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?

Three concise sentences, front-loaded with purpose and differentiation, no wasted words.

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

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

Given output schema exists and all parameters described, the description adequately explains the tool's unique value, use cases, and scope. No need to elaborate on return values.

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. Description mentions filtering by name, type, date range which aligns with schema but does not add new meaning beyond what schema already provides.

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

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

Clearly states the verb 'discover' and resource 'insider trading patterns across multiple companies'. Distinctly differentiates from sibling get_insiders which focuses on a single ticker.

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 contrasts with sibling get_insiders, guiding when to use this tool (cross-company) vs single-ticker. Mentions filtering options but lacks explicit 'when not to use' scenarios.

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

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

Annotations indicate readOnlyHint=true, and the description adds that data is derived from Form 4 filings, includes a lookupMode field, and explains the fallback logic (issuer first, then insider). This adds meaningful context beyond the annotation.

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

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

The description is three concise sentences. The first sentence is the main purpose, followed by two sentences that add necessary nuance. No wasted words.

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

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

Given the tool's dual behavior and the presence of an output schema (not detailed), the description adequately explains both use cases, the lookupMode field, and the data source. It is complete for an agent to understand the tool's functionality.

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 covers the cik parameter with a description, but the tool description adds the dual interpretation logic (issuer vs. insider) and the fallback behavior, providing significant additional 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 retrieves current open insider positions for a CIK, distinguishing between issuer and insider interpretations. It uses a specific verb 'Get' and identifies the resource as 'insider positions', differentiating it from siblings like get_insider_positions_by_ticker.

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

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

The description explains when to use each CIK type (issuer vs. insider) and implies that for ticker-based lookups, other tools like get_insider_positions_by_ticker should be used. While not explicit about alternatives, it provides clear context for the two primary use cases.

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

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

Adds context beyond readOnlyHint: explains it returns lifetime aggregates of cost/value and source (Form 4). 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, front-loaded with core purpose, second sentence adds source. No fluff.

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

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

Given output schema exists and the tool has only one parameter, the description sufficiently explains purpose, source, and output nature. No missing critical info.

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

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

Schema coverage is 100% with a clear description for 'ticker'. Description repeats 'given ticker' but adds no extra meaning. Baseline 3 is appropriate.

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

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

Clearly states it gets 'per-insider lifetime position aggregates' for a given ticker, differentiating from sibling tools like get_insider_positions and get_insider_transactions. Verb and resource are specific.

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

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

Implies usage for aggregate insider positions per ticker, but no explicit when-not-to-use or alternative tools mentioned. Context from 'Derived from Form 4' helps, but guidance is minimal.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: explains transaction breakdown by SEC code, fields like netSharesSold12m and isPrimarilyTaxWithholding, and pagination support. 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?

The description is a single, well-structured paragraph that front-loads the purpose and efficiently conveys all necessary details without unnecessary repetition. Every sentence adds value.

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

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

Given the complexity of insider data, the description covers key aspects (cluster buying, transaction breakdown, flags, pagination) and leverages the output schema. It feels complete for an AI agent to understand what data to expect.

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

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

Schema coverage is 100%, and the description merely reiterates the parameters (ticker, limit, offset) without adding significant new information beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states 'Get insider trading discovery data for a company' and lists specific features like cluster buying detection, entity-centric insider model, and Form 4 cross-referencing, distinguishing it from sibling tools such as get_insider_transactions which focus on raw transactions.

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 comprehensive insider analysis but does not explicitly state when to use this tool versus alternatives like get_insider_transactions or get_insider_positions. There is no direct guidance 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?

Annotations include readOnlyHint: true, and description aligns with read-only behavior by stating 'Returns individual buy/sell transactions.' Discloses pagination and filtering behavior beyond annotations. 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 concise sentences with key information front-loaded. Every sentence adds value, no wasted words. Structure is efficient and easy to parse.

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, output schema present, and no nested objects, the description fully covers the tool's capabilities: pagination, filtering by year/month/transactionCode, and the use case. Nothing essential is missing.

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

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

Schema coverage is 100% with descriptions, but description adds value by explaining transactionCode with examples (P=Purchase, S=Sale, etc.) and clarifying that month requires year. This enhances understanding beyond the schema.

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

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

Description clearly states 'Get detailed insider transaction history for a company from Form 4 filings' with specific verb and resource. It also lists what is returned (insider name, title, shares, price, transaction codes), distinguishing it from sibling tools like get_insider_positions or get_insider_cluster_buys.

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 guidance on when to use: 'Supports pagination for companies with extensive insider activity' and 'Filter by year/month... use transactionCode to find only purchases...' Includes a use case: 'Useful for identifying first insider buy since X patterns.' Does not explicitly state when not to use, but context from sibling tools makes it 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 annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds 'Reads the number of trailing periods to include,' which clarifies parameter behavior but does not disclose additional traits like data source frequency or response format. With annotations present, the description provides adequate but minimal extra context.

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

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

Two concise sentences: the first states the core purpose with specific verbs and resources, and the second adds a brief parameter note. No unnecessary words, front-loaded with key info. This is an exemplary efficient description.

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, output schema exists), the description covers the essential purpose and parameter roles. It mentions '13F periods' for context. It could note the required CIK, but the schema already does that. For a read-only tool with rich schema, it is nearly complete.

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

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

Schema coverage is 100%, so the schema already describes both parameters (cik as SEC CIK, periods with min/max). The description adds only that periods 'include' trailing periods, which is a slight restatement. It does not add significant meaning beyond the schema, resulting in a baseline score.

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 gets an institution's position changes over recent 13F periods by CIK, specifying the resource (position changes) and the constraint (13F periods). This distinguishes it from siblings like get_institution_holdings (snapshot) and get_institution_position_changes (likely without period specificity).

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

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

The description implies usage when historical position changes over multiple quarters are needed, but it does not explicitly state when to use this tool over alternatives (e.g., get_institution_holdings for current holdings) or provide exclusions. Usage context is inferred but not 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 provide readOnlyHint=true, which matches. Description adds pagination/sorting behavior but no additional safety notes, recency, or other constraints. Fair for a read 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?

Single sentence, no extra words. All key elements present: verb, resource, identifier, features. Efficient.

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

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

Given 6 parameters, output schema, and annotations, the description adequately covers core purpose. Lacks error handling or edge cases, but sufficient for a retrieval tool with rich 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 coverage is 100%, so parameters are fully defined. Description mentions 'pagination' (implied by limit/offset) and 'sorting' but adds no semantics beyond the schema. Baseline 3 is appropriate.

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

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

Clearly states verb 'Get', resource 'PUT/CALL derivative positions', identifier 'by CIK (13F options)', and features 'pagination and sorting'. Distinguishes from siblings like get_institution_holdings by focusing on derivatives.

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. Lacks comparisons to sibling tools or exclusions. Agent must infer that this is for options data from the 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 the description aligns by stating it 'gets' information. The description adds value by detailing the output content (name, AUM, holdings, filing history), which goes beyond the annotation. No behavioral 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?

The description is two sentences with no fluff. The purpose is front-loaded, and each sentence serves a distinct function: stating the action and providing usage guidance. Perfectly concise.

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

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

Given the tool has an output schema (not shown but flagged by context signals), the description need not enumerate return fields in detail. It still lists key output fields and explains the prerequisite. For a one-parameter lookup tool, this is mostly complete, though it could mention error handling for invalid CIKs.

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 describes the 'cik' parameter with a format example, and schema coverage is 100%. The description adds extra context ('Use get_institutions first to find the CIK'), which helps the agent understand how to obtain the parameter value. This adds meaning beyond 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's purpose: 'Get detailed information about a specific institutional investor by their SEC CIK number.' It specifies the verb ('get'), the resource ('detailed information about a specific institutional investor'), and the method ('by their SEC CIK number'). It also lists the returned fields (name, AUM, holdings, filing history), distinguishing it from siblings like get_institutions.

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

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

The description provides explicit when-to-use guidance: 'Use get_institutions first to find the CIK for an institution.' This helps the agent understand the prerequisite. However, it does not contrast with other institutional detail tools like get_institution_activity, but the context is sufficient for correct usage.

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

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

Annotations provide readOnlyHint=true, so the agent knows it is a safe read operation. The description adds that it returns a list of filings with pagination. No contradictions or missing behavioral context that is not already covered by annotations.

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

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

The description is a single sentence front-loading the core purpose and key features. No extraneous text.

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

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

Given the tool's simplicity and the presence of annotations, input schema with 100% coverage, and an output schema, the description is sufficiently complete. It does not mention that 13F filings are quarterly, but that is not critical for selection.

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

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

Schema coverage is 100% with adequate descriptions for all parameters. The description adds minimal value beyond that by mentioning pagination. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Get', the resource 'list of 13F filings', the key parameter 'by CIK', and the feature 'with pagination'. It distinguishes itself from siblings like get_institution_holdings or get_institution_activity by specifying it is for filings.

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 its many siblings (e.g., get_institution_holdings, get_institution_activity). The agent would have no context to choose this tool over 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 indicate readOnlyHint=true, and the description aligns with that by stating it returns holdings details. It adds behavioral context beyond annotations by noting pagination support and the specific data returned (shares, value, weight).

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, no wasted words, and front-loaded with the key action and inputs. It is concise and well-structured.

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

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

With an output schema present, the description does not need to detail return structures. It covers the core functionality, pagination, and what data is returned, making it sufficient for the agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the description does not need to re-explain parameters. It adds context about pagination and the nature of the returned data (latest 13F filing), but does not significantly enhance understanding beyond the schema definitions.

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

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

The description clearly states the tool retrieves the full portfolio holdings for a specific institution by CIK, returning positions from the latest 13F filing with shares, value, and portfolio weight. It differentiates from sibling tools like get_institution_activity or get_institution_detail by focusing on portfolio holdings.

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

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

The description provides clear context for when to use the tool (e.g., when needing complete portfolio data for an institution by CIK). It does not explicitly state when not to use it or mention alternatives, but the use case is well-defined.

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, indicating a safe read operation. The description adds context about the output (sector allocation, top holdings) but does not elaborate on other behavioral traits like data freshness, pagination, or limits. It is consistent with annotations, but no additional behavioral details 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 a single concise sentence that front-loads the key action and resource. No extraneous words or redundant information.

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

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

Given the presence of an output schema (as indicated by context signals), the description adequately covers the tool's purpose. It is a simple lookup with one parameter, so the description is sufficient. However, a slightly more detailed description of the analytics (e.g., typical fields returned) would be helpful but not necessary.

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?