equibles

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

Beyond the readOnlyHint annotation, the description discloses important behavioral details: returns one row per ticker with the latest-restated value, lists tickers with no data separately, and emphasizes that fiscal periods follow each company's own calendar (with a concrete NVDA example). This gives the agent a clear mental model of output and data quirks.

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 purpose, then output behavior, then the critical fiscal calendar caveat. Every sentence earns its place; no redundant or generic filler. Excellent structure.

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

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

Given the tool's complexity (multi-company comparison with fiscal period nuances) and no output schema, the description covers the essential return format, missing-data handling, and a significant data interpretation pitfall. It could mention sorting or additional output fields, but it is sufficient for an agent to use the tool correctly. Slightly more detail would push it to 5.

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 covers all 4 parameters with descriptions (100% coverage). The description adds extra meaning by explaining that 'concept' uses aliases, that fiscalYear/fiscalPeriod are relative to each company's own calendar, and that values are latest-restated. This goes beyond the schema's baseline, but does not dive into exact parameter syntax.

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: 'Compare one financial concept across several companies for the same fiscal period — peer comparison.' It uses a specific verb (compare), names the resource (financial concept across companies), and defines the scope (peer comparison across several companies). This distinguishes it from siblings like GetFinancialFact (single company/fact) and GetFinancialStatement.

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 establishes the intended use case: 'peer comparison' across companies for the same fiscal period. It also warns about fiscal calendar differences, which is valuable usage guidance. However, it does not explicitly name alternative tools or state when not to use it (e.g., for single-company analysis), so it falls 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?

Beyond the readOnlyHint, the description discloses sourcing (10-K/10-Q/8-K filings, no XBRL equivalent), the 13-month scanning window, the derived/exhausted status, and the caveat that nothing is estimated. This substantially informs the agent about data provenance and limitations.

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

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

The description is information-dense without being bloated. The first sentence front-loads the core purpose and output fields; the second sentence adds essential caveats about data sources, time window, and empty-result interpretation. Every sentence earns its place.

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

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

Given only one parameter, no output schema, and minimal annotations, this description thoroughly covers expected returns, data provenance, limitations, and edge-case interpretation. It leaves little ambiguity about what the tool provides and how to interpret results.

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

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

The only parameter, 'ticker', is fully documented in the schema with example symbols, so the description adds little parameter-specific meaning. The baseline of 3 applies because schema coverage is 100% and the parameter is straightforward.

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 verb ('Get') and specific resource ('a company's at-the-market equity offering programs'), then enumerates the returned fields. It explicitly distinguishes itself from GetBuybackPrograms by calling ATM programs the 'dilution mirror-image' of buybacks.

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 names GetBuybackPrograms as the analogous but different alternative, signaling when to choose this tool for ATM data versus buyback data. It also provides critical interpretation guidance: empty results mean no program was captured in the last 13 months of filings, not proof that no ATM program exists.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral details: ATR is denominated in USD, the smoothing is warmed up using pre-startDate history, and values are independent of the range's left edge. It also explains the True Range formula, providing deep insight into expected behavior.

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

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

The description is five sentences, each serving a distinct purpose: definition, formula, use case, units, and warm-up behavior. No filler or redundant restatement of the schema is present.

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 an indicator tool with no output schema, the description covers calculation, units, and an important edge-case behavior (warm-up). It does not explicitly describe the return format, but the maxResults parameter implies a list of records, making the description adequate for invocation.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds context about the formula and units but does not add new meaning to individual parameters 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 opens with 'Average True Range (ATR) for a stock,' clearly identifying the metric and target resource. It further distinguishes itself from sibling indicators like GetBollingerBands by explicitly calling it a 'volatility measure' and describing its construction.

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 concrete use cases: 'commonly used for position sizing and stop placement.' It does not explicitly mention alternatives, but the behavioral context is sufficient for an agent to decide when to invoke 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?

Annotations already declare readOnlyHint=true, so the description carries less burden. It adds valuable non-obvious behavior: the moving-average window is warmed up on prior price history, making results independent of the requested range's left edge. This is meaningful behavioral context beyond the annotation.

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

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

The description is four sentences, each earning its place: definition, volatility behavior, column list, and warm-up note. It is front-loaded with the core purpose and free of fluff or repetition.

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

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

With no output schema, the description adequately explains return values (bands, %B, bandwidth) and the warm-up behavior. It is sufficient for an agent to know what data it will receive, though it does not mention date ordering or error scenarios.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context by explaining the formula (middle band = SMA, upper/lower = ± standard deviations), which helps interpret the 'period' and 'stdDev' parameters. It also clarifies output columns, indirectly explaining the derived values.

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

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

The description clearly explains what the tool returns: Bollinger Bands with middle, upper, and lower bands, plus %B and bandwidth columns. It specifies the resource ('for a stock') and differentiates from sibling indicator tools by detailing the calculation and output.

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 the tool by explaining the indicator's meaning, including the overbought/oversold cue when price touches a band. It does not explicitly exclude alternatives or name sibling tools, but the usage context is specific and sufficient.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context: figures come from XBRL facts plus verified narrative extractions, 'nothing is estimated,' and stale figures carry an explicit staleness label. This goes beyond the annotation but doesn't cover all possible behaviors (e.g., response format, rate limits), which is why it's a 4 rather than 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 compact for the amount of information it conveys, but the first sentence is long with many embedded lists. Still, every clause adds value, and the structure is logical: main output, data provenance, and alternative tool. It earns a 4 due to being well-organized if slightly dense.

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

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

With no output schema, the description carries the burden of explaining return content. It does so by naming the three major output groups (programs, authorization figures, history) and noting key attributes like the staleness label. This is adequate for a complex tool, though it doesn't exhaustively list every field, so a top score isn't warranted.

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

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

Schema description coverage is 100% for the single parameter 'ticker', with the description 'Stock ticker symbol (e.g., AAPL, MSFT).' The tool description adds no additional parameter-specific semantics, so it meets the baseline for high schema coverage but doesn't exceed 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 clearly states what the tool does: 'Get a company's share-repurchase (buyback) picture' and enumerates the key components (programs, authorization figures, history). It uses a specific verb and resource, and explicitly distinguishes itself from GetAtmPrograms, making it stand out among siblings.

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

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

The description provides explicit when-to-use guidance by stating, 'For the dilution mirror-image — at-the-market (ATM) equity offering programs — use GetAtmPrograms.' This directly names an alternative for a closely related but distinct use case, which is exactly what the dimension asks for.

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 provide readOnlyHint=true, but the description adds valuable behavioral context: results are newest-first, verifier-approved only, quarters may be missing with a gap note. It describes the shape of return data without contradicting annotations.

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

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

The description is three sentences, front-loaded with the core output, and each sentence adds distinct value: what it returns, ordering/approval behavior, and intended use. 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?

With no output schema, the description adequately describes the return values (tone scores, themes, mention counts, per-theme tone) and the gap note. It covers the tool's key behavioral nuances; it could mention list length or response structure, but it is sufficiently complete for selection and invocation.

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

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

Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds no parameter-specific semantics beyond what is in the schema, but the 'newest first' default behavior is implied. 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 gets AI-scored insights for a company's recent earnings calls, listing concrete outputs (net tone score, hedging score, key themes with mention counts and per-theme tone). This distinguishes it from sibling tools like GetEarningsCallEvent or GetEarningsBrief by emphasizing the AI-scoring and verifier-approval aspect.

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

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

It explicitly says 'Use it to gauge how confident or guarded management sounded and what they talked about most,' giving a clear use case. It also sets expectations around ordering and missing quarters, though it does not explicitly mention alternatives or when not to use the 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?

Annotations only state readOnlyHint=true, so the description adds meaningful behavioral detail: data source ('legacy futures-only COT report'), cadence ('positions as of each Tuesday, published Friday'), and type of values ('contract counts'). This goes beyond the annotation and helps the agent understand what the tool returns.

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 concise sentences, each providing necessary information: purpose, output summary, data source/cadence, and a pointer to a prerequisite tool. No filler or redundant content.

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

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

Given there is no output schema, the description reasonably covers the return type (commercial and non-commercial positions, contract counts, time series). It also covers data frequency and how to resolve market codes. A minor gap is the lack of explicit differentiation from GetLatestCftcData, but the 'over time' phrasing implies historical series.

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 adds some context about the report type and cadence, but it does not meaningfully elaborate on parameters beyond what the schema already provides. The schema already includes examples and 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 the tool retrieves COT positioning data for a specific futures contract, using a specific verb and resource. It distinguishes itself from sibling tools like GetLatestCftcData by mentioning 'over time' and 'specific futures contract' and the legacy futures-only report.

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

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

The description gives clear context: it is for a specific contract's historical positioning data. It also provides a direct prerequisite: 'Use SearchCftcMarkets to find available market codes.' It does not explicitly name alternatives or exclusions, but the use case is unambiguous.

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?

Despite the readOnlyHint annotation covering the safety profile, the description goes far beyond it by detailing behavior: output structure (time series with latest value, period, filed date, source), the YoY change only when comparability exists, the verbatim disclosure, the exact-value/scale guarantee, and the optional Reconciliation line. It discloses both limitations and edge-case handling without contradicting annotations.

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

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

The description is longer than typical, but every sentence carries essential information about source, output structure, comparability, and reconciliation. It is front-loaded with the core purpose, then methodically details behavior. The density is justified given the tool's complexity and lack of an output schema, though it could be slightly streamlined without losing content.

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

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

With no output schema, the description fully specifies the return semantics: latest value, period, filed date, written source, YoY change conditions, verbatim disclosure, and the Reconciliation line for GAAP-to-non-GAAP bridges. It also covers the metric-history mode and exclusions (e.g., earnings-call transcripts). This is complete for an agent to invoke the tool correctly and interpret results.

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

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

While schema description coverage is 100% for both parameters, the description adds meaningful semantics: 'metric' is optional and can be expanded to full history, matches company labels case-insensitively, and may return candidates on ambiguous matches. It also clarifies the behavior of omitting 'metric' (overview of latest readings). This adds value beyond the schema's basic field descriptions.

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

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

The description names a specific verb ('Get'), a specific resource ('a company's own key performance indicators'), and provides detailed scope (extracted from Item-2.02 8-K earnings releases and 10-K/10-Q MD&A sections, listing examples of metric types). It also clearly distinguishes the tool's dual mode (overview vs. full history) and explicitly excludes earnings-call transcripts as a source, differentiating it from related tools like GetNonGaapBridge.

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

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

The description gives clear usage context: it explains when to pass 'metric' vs. omit it, and states an explicit exclusion ('Earnings-call transcripts are deliberately not a KPI figure source'). However, it does not name alternative tools or explicitly describe scenarios where another tool would be preferred, so it stops short of a full when-to-use/alternatives guide.

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

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

Annotations only declare readOnlyHint=true, so the description adds valuable context: newest-first ordering, default last-year window, amounts as disclosed ranges (not exact), and Asset identifying instrument type. It does not describe pagination or return format, but the added caveats go 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, front-loaded with the action, and every clause adds meaningful detail (ordering, defaults, range caveat, Asset field, alternative tool). No redundancy or fluff.

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

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

Despite no output schema, the description covers what the response reveals (members, purchase/sale, transaction/filing dates, amount ranges, Asset type). It also notes defaults and the sibling distinction. With readOnlyHint provided and 5 params fully documented, this is complete for agent use.

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

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

Schema coverage is 100% with clear descriptions for every parameter (ticker, endDate, startDate, maxResults, transactionType). The description adds no new parameter-level semantics but does clarify default behavior (last year, newest first). 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 starts with a specific verb+resource ('Get congressional securities transactions') and clearly scopes it to a specific ticker. It also distinguishes from GetMemberTrades, making the purpose unmistakable.

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

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

The description explicitly states when to use this tool (for a specific ticker) and points to an alternative ('Use GetMemberTrades for one member's transactions across all tickers'). This provides clear if/when guidance and differentiates from 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 only provide readOnlyHint, so the description carries the behavioral burden. It adds key details beyond the schema, such as the ranking order (by number of funds, then combined value) and the 'latest common report date' constraint. It does not disclose potential edge cases (e.g., what if no common report date exists), but it is still richer than typical.

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, each adding essential information: purpose, ranking behavior, and use case/filter. No redundant filler, well front-loaded, and every sentence earns its place.

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

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

Despite no output schema, the description explains what is returned (stocks ranked) and provides clear context for usage. It could mention edge cases (e.g., no common quarter) or result limits, but the schema covers maxResults and the description is adequate for the tool's complexity.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces minFunds ('Filter by minFunds to only show stocks held by at least that many funds') and mentions the 2-25 range, but these are already fully documented in the schema. It does not add meaningful new parameter semantics beyond what schema descriptions already provide.

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 ('consensus / combined portfolio of 2-25 institutions'), clearly distinguishing it from sibling tools like GetFundHoldings or GetFundOverlap. It also explains ranking logic (by number of funds, then combined value), leaving no ambiguity about the tool's 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?

It explicitly states when to use the tool: 'Use this to answer "what do these funds agree on?" or "show me the top picks across these N investors combined."' However, it does not explicitly name alternatives or say when not to use it, 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?

With readOnlyHint=true annotation, the description goes far beyond by disclosing computation details (split/dividend-adjusted closes, log returns, never raw prices), universe constraints ($100M market cap, overlapping trading days), and output behavior (each row reports observation count). This is rich behavioral transparency that helps the agent set expectations.

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

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

The description is dense but every sentence contributes: purpose, methodology, scope semantics, direction, constraints, output details, and alternatives. It is front-loaded with the primary purpose and structured logically, making it easy to parse without wasted words.

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

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

Despite having no output schema, the description explains key output characteristics (observation count). It also covers universe selection, constraints, and alternatives comprehensively. For a tool with this complexity, the description is complete enough for an agent to invoke correctly and interpret results.

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

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

Schema coverage is 100%, so baseline is 3. The description adds contextual meaning for 'scope' (explaining what each universe means) and 'direction' (explaining hedge candidates), which goes beyond schema descriptions. It doesn't add detail for days, ticker, or maxResults, but those are self-explanatory and well-covered by the schema.

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

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

The description clearly states the tool's purpose: 'Get the stocks whose daily price returns are most (or least) correlated with one stock' with specific methodology (Pearson correlation of daily log returns on adjusted closes). It also distinguishes from siblings by explicitly mentioning GetStockPrices and the screener as alternatives, making the unique value of this tool evident.

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

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

The description provides explicit usage guidance: it explains when to use different scopes (Industry, Sector, Market) and the meaning of direction=Negative for hedge candidates. It also names alternatives: 'Use GetStockPrices for the underlying series and the screener for fundamentals-based peer sets.' This gives clear when-to-use and when-not-to-use context.

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

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

Beyond the readOnlyHint annotation, the description discloses key behavioral traits: it uses only 'verified extractions of the filings' own narrative text', intentionally skips XBRL-tagged filers, and clarifies miss semantics ('A miss is never a statement of no risk'). It also explains the source and scope limitations. This far exceeds what annotations convey.

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

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

The description is a single dense paragraph of four sentences, with no filler. It is front-loaded with the core purpose, then adds provenance, exclusions, a caveat, and parameter guidance. Every sentence earns its place and the structure is logical.

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 no output schema, the description enumerates the return fields (basis, customer count, percentage, period, quote, source filing) and explains coverage limitations, the alternative tool, and trend behavior. For a read-only tool with a simple two-parameter schema, this is a complete and self-sufficient definition.

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 adds meaning to maxFilings by explaining the trend use-case: 'Pass maxFilings > 1 to also see earlier filings' disclosures (the concentration trend).' It also provides concrete examples of the returned data, enriching understanding of the ticker 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 opens with a specific verb and resource: 'Get a company's customer-concentration risk disclosure' and then details exactly what is returned (basis, customer count, percentage, period, verbatim quote, source filing). It clearly distinguishes from sibling GetFinancialFact by explaining the division of labor for XBRL-tagged vs untagged disclosures.

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 the alternative tool: 'issuers that tag it in structured XBRL (e.g. NVDA, AAPL) are skipped by design and answered with a pointer to GetFinancialFact's 'customer-concentration' concept.' It also gives usage guidance for maxFilings > 1 to see concentration trends. The caveat 'A miss is never a statement of no risk' manages expectations about absence of results.

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 include readOnlyHint=true, so the description carries the burden of explaining behavior. It discloses that only approved briefs appear (quarters may be missing), newest quarter first, and that it is the same brief shown on the Equibles stock page. These are non-obvious traits beyond the annotation and add significant 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 concise and front-loaded with the core purpose, then adds crucial caveats and usage guidance in a few sentences. Every sentence earns its place with no fluff or repetition of schema 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?

Given no output schema, the description thoroughly explains what the returned brief contains and how it is ordered, and it sets expectations about missing quarters. Combined with the complete parameter schema, the description is fully sufficient for an agent to understand the tool's behavior and output.

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

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

Schema coverage is 100%, with each parameter already having a description. The tool description adds no additional per-parameter semantics, so the baseline of 3 is appropriate. It does provide subtle context about missing quarters that relates to fiscalYear/Quarter, but not enough to raise the 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 the AI 'Earnings Brief' for a company's recent earnings calls, specifying its contents: TL;DR, bullish/bearish points, and verbatim pull-quotes with speaker and role. It distinguishes itself from siblings by describing a verifier-approved, curated brief rather than raw call 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?

It explicitly says 'use it for a fast qualitative read of what management said and how it landed,' giving clear usage context. It also warns that quarters can be missing, which sets expectations. However, it does not explicitly mention alternatives like GetCallInsights or when not to use it.

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

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

Beyond the readOnlyHint annotation, the description richly details the return payload: event id, title, call date, status, artefact availability, linked document ids, and extracted guidance rows. It also discloses conditional behavior (when transcript available, when 8-K carries approved guidance) and downstream use of the id with GetInvestorEventSpeakers. 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?

Four sentences, each adding essential value: purpose, return structure, related tool usage, and a concrete usage example. No fluff; front-loaded with the primary action and resource.

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

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

Given the absence of an output schema and the tool's moderate complexity, the description is comprehensive. It covers what the event contains, what fields are returned, when to use it, how the returned id connects to other tools, and alternatives for transcript reading. This gives an agent sufficient context to invoke the tool correctly and interpret the result.

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

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

Schema coverage is 100% with detailed descriptions for all three parameters (ticker, fiscalYear, fiscalQuarter). The tool description does not add additional parameter semantics beyond what the schema already provides, so the baseline 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 purpose: 'Get the earnings-call event for a company's fiscal quarter' and details what it returns. It distinguishes from siblings by defining the event as the single record grouping all call artefacts, and explicitly contrasts with alternatives like GetEarningsCallSpeakers and GetEarningsBrief.

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 when-to-use guidance: 'Use this to ask "what do we have for AAPL FY2025 Q3?" rather than chasing each artefact separately.' It also names alternatives for reading the transcript and related AI summaries, making the decision boundary clear.

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

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

Annotations already include readOnlyHint=true, and the description adds meaningful behavioral context: identities appear only when resolution is trusted, unverified voices are shown as role labels or neutral speaker numbers, and turns are returned in order. This goes beyond the annotation without contradicting it.

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

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

The description is compact and front-loaded: the main purpose appears in the first sentence, followed by two sentences explaining output behavior and a usage hint. Every sentence contributes distinct information without redundancy.

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

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

The description explains what the tool returns (ordered speaker turns with attribution and fallback labeling) and provides a prerequisite check. It lacks explicit mention of pagination or the 200-turn cap, but the schema's limit/offset parameters cover that, and the description is otherwise complete for a read-only transcript 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?

Input schema covers 100% of parameters with detailed descriptions (e.g., fiscalYear explains the fiscal vs calendar year distinction). The tool description does not add extra semantic value to the parameters themselves, so the baseline 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 states a specific verb and resource: 'Get the speaker-labelled transcript of a company's earnings call for a fiscal quarter'. It clearly distinguishes itself from siblings like GetEarningsCallEvent and GetInvestorEventSpeakers by focusing on the full ordered transcript with speaker attribution.

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

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

The description explicitly says 'Use GetEarningsCallEvent first to check a transcript exists', providing a clear next-step prerequisite and directing to an alternative tool. This gives the agent actionable guidance on when to invoke this tool relative to its sibling.

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?

Despite the readOnlyHint annotation, the description adds substantial behavioral context: the calendar covers both upcoming and recent releases, includes importance tiers with specific examples, defaults to the next 30 days, and explicitly states FOMC exclusions. This goes well beyond the annotation and gives a full picture of the tool's scope and limitations.

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

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

The description is front-loaded with the core purpose and concise in its expansions. Each sentence provides distinct value: definition, exclusions, defaults, and parameter usage guidance. 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?

With no output schema, the description adequately explains the return contents (release dates, FRED series, importance tiers) and usage context. It covers defaults, exclusions, and cross-references to sibling tools, making it sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the meaning of the minImportance parameter ('High = tier-1 market movers') and clarifies the default date range ('Defaults to the next 30 days'), offering semantic context beyond the schema's raw 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 a specific verb and resource: 'Get the economic release calendar' with scheduled and recent US macro data publication dates. It further distinguishes itself by detailing the included FRED series and importance tiers, and explicitly excludes FOMC meetings, which sets it apart from siblings like GetMarketCalendar or GetEconomicIndicator.

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 when-to-use and when-not-to-use guidance: mentions FOMC meetings are NOT included and directs to the Federal Reserve's calendar, and tells users to use GetEconomicIndicator to fetch series data after release. Also advises using minImportance=high for market movers, giving clear context for parameter use.

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

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

With readOnlyHint=true already indicating a safe read operation, the description adds meaningful context by disclosing the scope limitation (curated 40-series set vs. full FRED) and providing concrete series examples. No contradictions with annotations; it supplements them with operational boundaries.

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 front-loaded core functionality, followed by useful scope and alternative guidance. Every sentence adds value, with no redundant wording or unnecessary detail.

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 4 parameters and no output schema, the description adequately covers the purpose, scope, examples, and a pointer to a search tool. The behavior of date defaults and maxResults is already in the schema, so the description focuses on what the agent needs beyond that. It lacks explicit return format details, but that is not critical for a time series tool.

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

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

The input schema already covers 100% of parameters with detailed descriptions, including examples and defaults. The description repeats some series ID examples but does not add significant new semantic meaning beyond what the schema provides, meriting the 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's function: 'Get time series data for a FRED economic indicator.' It names specific examples (FEDFUNDS, CPIAUCSL, UNRATE) and explicitly distinguishes itself from the full FRED catalog, referencing SearchEconomicIndicators as a sibling for finding series. This provides a specific verb+resource+scope and differentiates from related tools.

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

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

The description provides explicit when/when-not guidance: it covers 'the curated ~40-series set Equibles tracks, not the full FRED catalog,' and directs users to 'use SearchEconomicIndicators to find available series.' This clearly states when to use this tool versus an alternative, and the 'historical observations' phrasing implies this is for history rather than latest values.

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 extraction method ('from the filings' narrative text'), verification ('verified before publication'), ordering ('newest filing first'), and a major limitation: coverage is still back-filling and the output names the oldest covered filing date. It also explains the meaning of empty results, which is essential behavioral context.

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

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

The description is efficiently structured: it leads with the core purpose, then details the output fields, then addresses coverage/interpretation. Every sentence adds distinct value, with no repetition of schema details or filler. It is moderately long but information-dense.

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

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

For a read-only retrieval tool with no output schema, the description compensates by enumerating exactly what each change record contains, the source form type, and the important coverage caveat. This gives an agent sufficient understanding of return values and edge cases. No critical gaps are apparent for the tool's complexity.

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

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

The input schema already provides full descriptions for all five parameters (100% coverage), so the description need not repeat them. It does add useful context about the output fields (person, role text, normalized role, action, effective date) that helps interpret parameter effects, but it does not directly augment parameter meanings 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?

The description opens with a specific verb and resource: 'Get a company's executive and director changes...' and enumerates exact categories (CEO/CFO/officer/board appointments, resignations, terminations, retirements) tied to 8-K Item 5.02 filings. This clearly distinguishes it from sibling tools like GetExecutiveCompensation or GetInsiderTransactions.

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 makes the tool's context obvious by specifying the source filings and ordering, and it gives critical usage guidance about back-filled coverage and how to interpret empty answers. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide when to invoke it.

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

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

Beyond the readOnlyHint annotation, the description discloses critical behavioral traits: figures are exactly as disclosed, Total is the filer's own figure never recomputed, coverage is back-filling, and the output explicitly states the newest proxy on file to make staleness visible. This gives the agent strong awareness of data reliability and limitations.

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

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

The description is information-dense but not overly long; every clause adds value. It is front-loaded with the core purpose and then appends important caveats. A minor issue is that it is a single long sentence, which could be split for readability, but this does not hurt clarity.

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

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

Given no output schema, the description sufficiently explains the return structure (per executive per fiscal year, newest first), the data source, coverage limitations, and how to detect stale data. It covers all essential aspects for an agent to decide to use the tool and interpret results.

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

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

Schema description coverage is 100% for both parameters (ticker and maxYears), so the schema carries the full burden. The description does not add additional parameter semantics beyond what the schema already provides, such as the meaning of maxYears defaulting to 0 meaning all imported years.

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 ('named-executive compensation as disclosed in DEF 14A proxy statements' Summary Compensation Table'), detailing the exact data fields (salary, bonus, stock awards, etc.) and output ordering. It clearly distinguishes itself from sibling tools like GetExecutiveChanges.

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 context about when the tool is applicable: 'Coverage is limited to US DEF 14A filers' and explicitly excludes foreign private issuers. However, it does not name alternative tools for cases where this tool does not apply, so it stops short of full 'when/alternatives' guidance.

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

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

The readOnlyHint annotation already indicates safety, and the description adds significant behavioral nuance by explaining that ongoing offerings are re-noticed through D/A amendments that restate the same offering, and that rows may double-count capital unless deduplicated. It also lists the fields returned, which is useful beyond the minimal 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 front-loaded with the primary purpose and then provides necessary caveats and usage guidance. The first sentence is somewhat long due to enumerating output fields, but it is efficient and each sentence serves a purpose.

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

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

With no output schema, the description sufficiently explains return values by listing the key fields (issuer, first-sale date, offering amount, amounts sold/remaining, min investment, investors, exemptions, amendment status, accession number). It also covers the critical deduplication behavior and gives a use case, making it complete for this tool's complexity.

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

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

Schema description coverage is 100%, so parameters are already well documented in the schema. The description does not add parameter-specific guidance beyond the schema, but it does mention that results include the first-sale date and offering amount, which are not parameters. 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 gets recent exempt securities offerings (private placements) for a company from SEC Form D notices. It names the specific resource (Form D/Regulation D) and scope (per company), distinguishing it from public-filing and other capital-raising tools among siblings.

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

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

The description provides clear context: use this to track how a company is raising private capital alongside its public filings. It also gives a strong caution about D/A amendments restating the same offering, but does not explicitly mention alternative tools or when-not-to-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?

The annotation only declares readOnlyHint=true. The description adds substantial behavioral detail: Quantity is an outstanding balance (never sum across dates), Price is the previous trading day's close, Value is a computed product, absent dates indicate no fails within the covered window, earlier dates are partially covered, and there is a publication lag. This fully discloses the data's interpretive nuances.

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

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

The description is a single, well-structured paragraph of six sentences. Every sentence earns its place: purpose, key caveats, date coverage, publication lag, and interpretation. It is detailed but not bloated, and the most critical operational warning (never sum Quantity) is placed early.

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

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

Given the tool's complexity and the absence of an output schema, the description is exceptionally complete. It explains the exact meaning of the return fields, the data source (SEC twice-monthly files), coverage limitations, and how to interpret missing dates. An agent can confidently use this tool and correctly interpret its results.

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

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

The input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaning beyond the schema by explaining date coverage semantics (absent dates, partial coverage, lag), which informs how startDate and endDate should be interpreted. It also clarifies the meaning of the output fields (Quantity, Price, Value), though these are not parameters.

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

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

The description clearly states the tool's function: 'Get fails-to-deliver (FTD) data for a stock from the SEC's twice-monthly FTD files.' It uses a specific verb and resource, and the subject matter (FTD) is distinct from sibling tools that cover short interest, short volume, or other market metrics.

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 establishes clear context for when the tool is appropriate (when FTD data is needed) and explains important data caveats. However, it does not explicitly mention alternatives or when-not-to-use conditions, such as contrasting with short interest tools, which would have earned 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?

Even though readOnlyHint=true is already annotated, the description adds substantial behavioral context: the data source (FDA.gov calendar), the inclusion of a link per meeting, the default 90-day window, the coverage start date, and the fact that entries are FDA's own listings without ticker linkage. These details go beyond the annotation and give the agent a realistic model of what the tool returns and its limitations.

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

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

The description is three sentences long, each earning its place: the first states the core purpose and source, the second explains default behavior and how to extend the range, and the third provides crucial caveats. It is front-loaded and avoids fluff, making it easy for an agent to parse quickly.

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

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

With no output schema, the description carries the burden of explaining return values. It mentions each meeting includes a link to its FDA page, which is useful, but it doesn't enumerate other likely fields (e.g., meeting date, committee name, agenda). For a simple calendar tool, this is a minor gap, and the description otherwise covers source, time range, and data freshness/coverage, making it reasonably 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 already provides full descriptions for all three parameters (startDate, endDate, maxResults) with defaults and format, so schema coverage is 100%. The description's mention of a 90-day default and 'pass a date range' somewhat echoes the schema but doesn't add significant new semantic meaning. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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

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

The description clearly identifies the tool's purpose with a specific verb ('Get') and resource ('scheduled FDA advisory-committee (AdComm) meetings'). It distinguishes this from sibling calendar tools by focusing on the FDA-specific domain and mentioning the source (FDA.gov advisory-committee calendar), making it unmistakable among the many other financial calendar tools in the sibling list.

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

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

The description provides concrete usage context: it defaults to the next 90 days, explains how to look further ahead with a date range, and explicitly warns that it is forward-looking with coverage starting in late 2025. It also notes that entries are not linked to stock tickers, which is a key exclusion for catalyst-focused users. While it doesn't name alternative tools, the 'not a historical archive' statement serves as a clear when-not-to-use guideline.

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 rich behavioral details: returns a time series with one row per fiscal period, uses the latest restated value unless asOriginallyReported is set, reports actual period start/end, follows the company's fiscal calendar, and warns about premature alias termination. No contradiction with annotations.

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

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

Four sentences, front-loaded with the core purpose. Each sentence earns its place: return format, restatement policy, calendar semantics, warning behavior, and sibling alternatives. No filler or redundancy.

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

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

With 8 parameters and no output schema, the description explains the return structure (time series, one row per fiscal period, period start/end) and key behavioral aspects including warnings. It doesn't explicitly cover empty-result or error scenarios, but for a read-only financial lookup it covers the core context well.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining default restatement behavior ('latest restated value unless asOriginallyReported is set') and fiscal-period semantics ('fiscal years/quarters follow the company's own fiscal calendar'), enriching understanding of the asOriginallyReported and fiscalPeriod parameters beyond schema descriptions.

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

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

The first sentence states the exact purpose: 'Get a single financial concept ... over time for a company', with concrete examples like revenue and net income. It also explicitly distinguishes from sibling tools by naming GetFinancialStatement and CompareFinancialFact as alternatives.

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

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

Explicitly provides when-to-use vs alternatives: 'For a full statement use GetFinancialStatement; to compare peers use CompareFinancialFact.' It also adds contextual guidance about fiscal calendars and XBRL tag change warnings, helping the agent decide when this tool is appropriate.

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

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

Beyond the readOnlyHint annotation, the description discloses the data source (SEC Company Facts XBRL), the 'latest-restated value' behavior, and the period-boundary semantics that keep discrete-quarter vs. YTD facts distinguishable. It also clearly states exclusions, adding significant context for safe use.

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, tightly packed with purpose, return behavior, and alternatives, with no filler or redundant information. Every sentence earns its place.

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

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

Despite lacking an output schema, the description covers data source, line items returned, restatement behavior, period semantics, exclusions, and alternative tools. This is sufficient for an agent to select and invoke the tool correctly 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the meaning of year/period in the context of fiscal reporting and the Q4 caveat, plus the 'latest-restated value' nuance, which enriches understanding beyond the schema field descriptions.

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

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

The description clearly specifies the tool gets a company's income statement, balance sheet, or cash-flow statement for a given fiscal year and period, with a direct verb 'Get' and explicit resource. It also distinguishes from siblings by naming GetRevenueBreakdown and GetFinancialFact/CompareFinancialFact for alternative use cases.

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 when-to-use guidance by stating what is not included (dimensional facts) and recommending alternatives. It also gives a concrete period caveat: 'Most filers report no discrete Q4 income/cash-flow facts… use FY for annual figures,' which directly informs parameter choice.

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?

Although readOnlyHint=true already signals a safe read operation, the description adds valuable behavioral context: it reconstructs quarterly snapshots, rebalances on the SEC filing lag to avoid look-ahead bias, and explains output metrics. This goes well beyond the annotation and gives the agent realistic expectations.

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 well-organized sentences: purpose, methodology, and output. It is front-loaded with the core function and contains no redundant or filler text. 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?

Without an output schema, the description compensates by enumerating exact return values (total return, CAGR, max drawdown, alpha) and thoroughly explaining the simulation logic. Given the tool's moderate complexity and rich sibling context, this description is fully sufficient for an agent to understand and invoke the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds contextual meaning by explicitly explaining the relationship between windowYears and fromDate/toDate ('over a trailing window... or an explicit range'), and clarifies that the simulation uses only information available at filing time. This enhances the parameter semantics without repeating schema details.

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

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

The description uses a specific verb ('Backtest') and a clear resource ('cloning an institutional filer's reported 13F portfolio'). It distinguishes this tool from sibling tools like GetFundHoldings or GetInstitutionPortfolio by focusing on performance simulation rather than static holdings or summaries.

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 concrete use case ('Use this to answer "how would cloning fund X have performed against the market"') and clearly explains the two window modes (trailing vs explicit date range). It does not name alternative tools or explicit when-not-to-use scenarios, but the context is clear enough for an agent to choose correctly.

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 mark readOnlyHint=true, and the description adds substantive context beyond that: the data source (NPORT-P), the 'no data' behavior for operating companies, ticker resolution limitations, and the option to use fund profile ids. No contradiction with annotations.

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

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

Structured with a clear lead sentence, then input flexibility, then output contents, then comparisons, then caveats. No filler; each sentence contributes a distinct, useful fact.

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

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

Given no output schema, the description fully enumerates return contents: series, reporting period, net assets, and holdings with issuer name, CUSIP, position size, value, share of net assets, and asset category. It also covers error/edge cases and provides sibling alternatives, making the tool self-contained.

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, but the description further clarifies ticker semantics: 'Accepts the fund's own ticker or a fund profile id from SearchFunds, so it also reaches the many fund series that have no ticker of their own' and warns that share-class tickers don't resolve. This adds meaning beyond the schema's parameter descriptions.

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

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

Description opens with 'Get the portfolio holdings of a registered investment company (mutual fund or ETF) from its most recent SEC Form NPORT-P monthly report' – a specific verb, resource, and source. It explicitly differentiates from siblings (GetFundProfile, GetFundsHoldingStock) by naming them, and clarifies scope: registered funds only.

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 routing: 'Use SearchFunds to discover funds, GetFundProfile for the same view with the fund's registrant and total assets, and GetFundsHoldingStock for the inverse question.' Also gives exclusion criteria: share-class tickers of multi-class mutual funds (VOO, VFIAX) do not resolve, and operating companies return no data.

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, but the description goes well beyond that by detailing exactly what the response contains (classification, file number, reporting period, first/last filing, service providers, filed-name history) and disclosing limitations (ticker resolution constraints, no data for operating companies). This gives the agent a comprehensive understanding of the tool's behavior without contradicting annotations.

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

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

The description is somewhat long but every sentence adds value. It is front-loaded with the primary purpose, then moves through limitations, response contents, and usage context. The structure is logical and not wasteful, though it could be tightened slightly without losing meaning.

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

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

Despite having no output schema, the description thoroughly explains what data will be returned (classification, file number, reporting period, first/last filing, service providers across categories, filed-name history). It also covers edge cases (unlisted tickers, operating companies) and provides alternatives. For a simple 2-parameter tool with strong annotations, this description is complete enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant parameter-level detail beyond the schema—it neither elaborates on the ticker format nor on maxResults behavior. However, it does provide context for what the parameters relate to (e.g., ticker resolution constraints), so it meets the baseline without exceeding 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: 'Get operational data for a registered investment company from its SEC Form N-CEN annual reports.' It clearly distinguishes the tool from siblings by explaining its focus on N-CEN filings and explicitly noting that unlisted mutual-fund tickers do not resolve, directing users to SearchFunds/GetFundProfile instead.

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

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

Explicit when-to-use and when-not-to-use guidance is provided: it resolves only exchange-listed tickers (ETFs, CEFs, UITs), while unlisted mutual-fund share-class tickers (e.g., VFIAX) will not resolve, with a direct alternative ('find that fund via SearchFunds/GetFundProfile instead'). It also states that only registered funds file N-CEN and operating companies return no data, plus a clear use case: 'Use this to see who runs and services a fund.'

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

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

With readOnlyHint=true, the safety profile is already disclosed. The description adds valuable behavioral context about output contents (Jaccard similarity, dollar-weighted overlap, per-fund counts, side-by-side table) and the calculation method for $-weighted overlap. It does not disclose error handling or rate limits, but the annotation covers the read-only nature.

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

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

The description is a single paragraph but densely packed with essential details: purpose, metrics, definitions, coverage, alternatives, and use cases. It is front-loaded with the main action and adds necessary nuance. The parenthetical explanation of $-weighted overlap is verbose but clarifies a key metric, so it earns its place.

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

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

Given the tool's complexity and lack of an output schema, the description does a good job enumerating the return contents and the formula for one metric. It also explains report-date behavior implicitly. It stops short of describing the exact response structure or table format, but the level of detail is sufficient for an agent to invoke it correctly.

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

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

The input schema describes all four parameters in detail (clamps, date snapping, partial name resolution), covering 100% of parameters. The description adds little beyond that: it mentions 'two institutions' and 'latest common report date,' both reflected in the schema. Since schema coverage is high, the baseline of 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?

The description opens with a specific verb and resource: 'Get the 13F portfolio overlap between two institutions for their latest common report date.' It clearly differentiates from siblings by stating 'Covers 13F institutional managers only... for mutual-fund/ETF (NPORT) portfolios use GetFundHoldings.' The use-case phrasing ('do these two funds own the same stocks?') reinforces the purpose.

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 names an alternative tool (GetFundHoldings) for NPORT portfolios and instructs to use SearchInstitutions for finding institution names. It also provides the typical use case ('Use this to answer...'), which clearly signals when this tool is appropriate.

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

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

The annotations already declare readOnlyHint=true, and the description adds meaningful caveats: for large multi-series trusts only tracked-stock positions are stored, while net-asset totals are real. This is valuable behavioral context beyond the safe-read annotation, though it does not discuss error cases or data freshness beyond 'most recent.'

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, then returns, then usage guidance and a data caveat. Every sentence earns its place, with no filler or unnecessary elaboration.

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

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

Even without an output schema, the description fully enumerates the returned fields (registrant/series, period, assets, holdings details) and explains the tracked-stock limitation. Combined with the rich parameter schema and read-only annotation, the agent has enough context to 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 description coverage is 100% and both parameters are well documented in the schema. The description repeats the ticker/profile-id options but does not add meaningfully new parameter details beyond usage context, so the 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 opens with a specific verb and resource: 'Get a registered fund's profile and largest holdings from its most recent SEC Form NPORT-P report.' It clearly differentiates from siblings by naming GetFundHoldings as the equivalent view and GetFundsHoldingStock as the inverse tool, so the agent knows exactly what this tool does.

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 advises using this after SearchFunds because the profile id reaches fund series without tickers, and distinguishes it from GetFundHoldings and GetFundsHoldingStock. This gives the agent concrete when-to-use guidance and 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 goes well beyond the readOnlyHint annotation by detailing the data source, CUSIP matching on recent filings, exclusion of stale reports (18 months), return fields, ordering, and the as-of date caveat. This provides rich behavioral context and potential pitfalls.

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

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

The description is front-loaded with the core purpose, followed by matching logic, return fields, a critical date caveat, and a use case. Every sentence adds value, and the structure is logical without redundancy.

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

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

Despite no output schema, the description lists the return fields and addresses key complexities (stale filings, differing report dates, as-of values). It is complete for a tool of this complexity, covering both what it returns and important limitations.

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

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

Schema coverage is 100%, with clear descriptions for all three parameters (ticker, maxResults, registrantOrSeries). The description does not add parameter-specific details 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 retrieves funds/ETFs holding a given stock from SEC NPORT-P reports, with a specific verb and resource. It distinguishes from sibling tools like GetFundHoldings (which likely returns holdings of a fund) and GetTopHolders by focusing on fund holdings of a specific stock.

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 use case ('see which funds and ETFs own a stock and how concentrated each position is') and explains the matching logic and data limitations. It does not explicitly name alternatives or when not to use, but the context is sufficient for an agent to decide.

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

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

Beyond the readOnlyHint annotation, the description extensively discloses behavior: extraction from newest 10-K/10-Q narrative text, verification before publication, that absence of language means no doubt, and that coverage starts at first examination so absence from history doesn't rule out prior episodes. This is far beyond annotation-only information.

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

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

The description is two sentences but every clause earns its place: it front-loads the core purpose, then efficiently conveys return content and important caveats. No wasted words.

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

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

Despite no output schema, the description explains what the tool returns (status, verbatim disclosure, filing source, history of doubt events) and covers processing and coverage limitations. It is complete for a single-parameter tool.

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

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

The schema fully documents the only parameter, 'ticker', with a clear example. The description adds no additional parameter detail, but the baseline of 3 applies because schema coverage is 100%.

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 a company's going-concern doubt status' with a specific verb and resource, and distinguishes itself from siblings by detailing the return contents (verbatim disclosure, filing, history). It is unambiguous and specific.

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

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

The opening phrase 'Get a company's going-concern doubt status' clearly implies when to use it, and the coverage caveat provides helpful context about historical limitations. No explicit alternatives or when-not-to-use guidance are given, but none are needed given the unique subject.

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?

Despite readOnlyHint annotation, the description adds substantial behavioral context: source (USAspending.gov), exact value definition ('obligated dollars plus unexercised ceiling — not revenue received'), coverage thresholds ($1M+ prime awards), and listed output fields. This goes well 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?

Three tightly written sentences: what it does, what it returns, and when to use an alternative. Every clause adds value, with no fluff or repetition.

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

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

No output schema exists, yet the description enumerates the returned fields, defines the value metric, states source and coverage exclusions, and points to a sibling tool. This fully equips an agent to decide and interpret results.

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

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

All six parameters are fully documented in the input schema (100% coverage), so the description need not repeat them. The description clarifies the meaning of output fields and coverage, but doesn't add parameter-specific detail beyond the schema's already rich descriptions.

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

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

The description uses a specific verb ('Get') with a clear resource ('federal government contract awards ... won by a specific public company'), and differentiates from the sibling GetTopGovernmentContractors by noting that tool ranks companies market-wide. The title reinforces the purpose.

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

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

Explicitly states it is 'useful for gauging a company's reliance on federal spending' and directs users to 'GetTopGovernmentContractors to rank companies market-wide.' The coverage caveat also tells users when results understate totals, which provides important 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 only provide readOnlyHint=true, leaving the description to carry the behavioral burden. The description goes beyond a simple read-only claim by disclosing: the source materials used, the ordering (newest release first), the handling of closed periods with the '(ended)' marker, the delayed nature of actuals comparison (only after XBRL facts land, with Q4 derivation caveats), the policy of never comparing non-GAAP guidance against GAAP actuals, and the backfilling caveat that empty results are not equivalent to no guidance. These are significant behavioral traits that prevent misinterpretation, exceeding the baseline set by 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 a single, dense paragraph with valuable caveats. It is not as lean as a two-sentence example, but each clause earns its place by preventing misinterpretation: the '(ended)' marker, the actual-vs-guidance comparison logic, and the backfilling caveat. It could be restructured with a couple of sentences for easier scanning, but no sentence is wasted. The front-loaded purpose sentence is strong.

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 a single parameter, high schema coverage, readOnlyHint annotation, and no output schema, the description's job is to explain the return semantics. It does that thoroughly: what metrics come back, the provenance, ordering, status labeling, actual comparison mechanics, and caveats about coverage gaps. This is complete enough for an agent to decide when to call the tool and to interpret empty or partial results correctly.

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

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

The input schema already covers 100% of the single parameter 'ticker' with a clear description, so the schema does the heavy lifting. The tool description adds no additional parameter-level detail beyond the schema, such as formatting or case sensitivity. Since the coverage is 100%, a baseline of 3 is appropriate; the description's explanation of output interpretation is not directly about parameter semantics.

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

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

The description begins with a specific verb phrase 'Get a company's earnings guidance' and immediately distinguishes the resource: forward-looking outlook extracted from Item-2.02 8-K releases and earnings-call transcripts. It goes beyond any sibling tool by mentioning guided metrics, ranges, GAAP/non-GAAP basis, period, and provenance. The mention that some issuers guide only verbally on the call clarifies scope, differentiating it from tools that might only read formal 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?

The description provides clear context on how to interpret results: it explains that covered fiscal periods are marked '(ended)', that coverage is backfilling, and that empty results mean documents are not processed yet rather than the company gave no guidance. This effectively tells the agent when the tool's output is meaningful and when it is not. It does not explicitly name alternative tools, but given the sibling list includes tools like GetEarningsBrief and GetNonGaapBridge, a direct exclusion would be stronger; however, the detailed interpretation guidance is strong enough for a 4.

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: rows are as-of the most recent SEC Form 3/4/5 filing, former insiders may show stale dates or zero shares, and share counts are restated onto today's split basis, differing from raw filings. Also notes the maxResults cap.

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: the core purpose, key caveats about data freshness and split adjustment, and usage guidance. No wasted words; each sentence adds important information and the main action is front-loaded.

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

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

Even without an output schema, the description explains the important nuances (as-of dates, stale rows, split basis, maxResults cap) and provides usage guidance. This is sufficient for an agent to select and invoke the tool correctly.

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

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

The input schema already provides 100% coverage with detailed descriptions for ticker, offset, and maxResults. The description repeats the default 30 and mentions the ranking context, but does not add parameter-specific meaning beyond the schema, so the 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 gets a summary of insider ownership for a stock, ranked by shares held, and explicitly differentiates from the sibling GetInsiderTransactions by naming it for underlying trades. This provides a specific verb+resource+scope.

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

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

It gives explicit guidance on when to use this tool ('Use this to understand the insider ownership structure') and points to GetInsiderTransactions as an alternative for underlying trades. It also warns about stale rows and split adjustments, aiding appropriate selection.

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 computation source (open-market Form 3/4/5), exclusion of Rule 10b5-1 trades, the handling of unknown flags, and that filters never renumber universe rank. This gives an agent robust behavioral expectations.

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

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

The description is dense but every sentence adds a distinct piece of information: score definition, data scope, parameter semantics, exclusions, and alternative tool. It is front-loaded with the core purpose and contains no filler.

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

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

Given the tool's complexity, seven optional parameters, and no output schema, the description is remarkably complete. It covers purpose, construction, parameter behavior, edge cases, and alternatives, leaving no major gaps for invocation decisions.

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 100% of parameters, but the description adds crucial semantic context: filters preserve universe-relative ranks, 'ticker' ignores other filters, and 'bottom' reverses ranking direction. These details go well beyond schema descriptions.

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

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

The opening verb phrase 'Get the stocks with the highest composite insider sentiment score' clearly states the tool's purpose with a specific resource and scope. It further differentiates from siblings by explicitly pointing to GetInsiderTransactions for underlying 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?

Provides detailed guidance on when to use each filter (clusterBuysOnly, liquidity params, bottom, ticker) and explicitly names an alternative: 'Use GetInsiderTransactions for one stock's underlying filings.' This makes usage context and exclusions clear.

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

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

Annotations only declare readOnlyHint=true. The description goes far beyond that by explaining the Type column semantics, 10b5-1 column meaning, split-adjusted Owned After values, and per-row data treatment. This provides detailed behavioral context without contradicting 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?

Front-loaded with a crisp purpose statement followed by six focused sentences, each adding unique context. No filler or repetition of schema details; every sentence earns its place given the complexity of insider transaction data.

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

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

Despite no output schema, the description explains key result fields (Type, 10b5-1, Shares/Price/Value, Owned After) and the split-adjustment nuance. It covers filters, ordering, and interpretation, making the tool's behavior sufficiently understandable for an agent to invoke and interpret results correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds interpretive value for the transactionType parameter by clarifying that Buy/Sell are open-market trades while other types are compensation/derivative mechanics, which is not in the schema. It also mentions date-range and insider-name filters, reinforcing their purpose.

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 recent insider trading transactions from SEC Form 3/4/5 filings, newest first. This specific verb+resource combination distinguishes it from sibling tools like GetInsiderOwnership or GetInsiderSentimentScores, which focus on different insider data aspects.

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

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

It explicitly states 'Use this to understand insider buying/selling activity' and explains that non-Buy/Sell types are 'not conviction trades', guiding interpretation. It does not name specific alternative tools, but the context is clear enough for an agent to infer when this tool is appropriate relative 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 provide readOnlyHint=true and the description uses 'View', so no contradiction. The description adds valuable behavioral context: shows largest tracked holdings by market value, includes share counts, market values, percent of portfolio, total value, and position count. It does not mention pagination or error handling, but these are covered in the schema.

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

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

The description is two sentences, front-loaded with the primary action and then providing usage guidance. Every word earns its place; no redundancy or extra fluff.

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

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

With no output schema, the description adequately explains the result set: holdings, values, percentages, total value, and position count. It also covers ambiguous-name handling referral. It does not describe offset paging, but the schema covers that. Overall, it is complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats some schema details (default 20, max 500) but adds no new semantic layer beyond what the parameter descriptions already provide. It does not clarify parameter relationships or usage nuances.

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 ('View') and resource ('stock portfolio of a specific institutional investor from their SEC 13F-HR filing'). It clearly differentiates from sibling tools by targeting individual institutions' 13F filings, not market-wide or fund-specific views.

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 SearchInstitutions first when the name is ambiguous, and gives the intended use case: 'understand what stocks a particular fund manager or institution is investing in.' This provides clear when-to-use and an alternative.

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

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

With readOnlyHint=true, the annotation already communicates the safe-read nature. The description adds valuable behavioral details: the result is bucketed markdown sections, sorted by absolute Δ market value, and clarifies that the Δ value includes price movement rather than just trading. These go beyond the annotation and schema, giving the agent a clear picture of what to expect.

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

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

The description is four sentences long, starting with the core function and then layering essential details about output format, sorting behavior, and an example use case. Every sentence contributes information without repetition or filler, making it efficient and well-structured.

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

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

With no output schema, the description compensates by explaining the return format (markdown sections per bucket, sorted by absolute Δ value). It also covers the key semantic nuance of Δ Value. It does not specify the exact fields returned for each stock, but the level of detail is adequate for a typical query and matches the tool's complexity.

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

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

The schema provides 100% parameter coverage, describing each of the four parameters in detail. The description adds only a minor interpretation of `bucket` (filtering to a single bucket) and doesn't introduce new parameter meaning. It neither undermines nor significantly enhances the schema, so the 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 retrieves an institution's quarterly position-change activity, specifying the four bucket types (Initiated/Increased/Reduced/Exited) and comparing against the prior quarter. It distinguishes itself from sibling tools like GetInstitutionPortfolio (current holdings) or GetMarketWide13FActivity (aggregate market) by focusing on per-institution changes over time.

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 usage context: 'Use this to answer "what did this fund do this quarter?"' and instructs how to filter with the `bucket` parameter. It does not explicitly contrast with alternatives or state when not to use it, but the purpose is clear enough to infer appropriate versus inappropriate scenarios.

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

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

With only readOnlyHint=true in annotations, the description goes well beyond by disclosing output format (markdown table sorted by % of portfolio descending), handling of unclassified stocks (collapsed into a single row), default report date behavior, and name resolution behavior (unique partial resolves, ambiguous partials return candidates). No contradictions with annotations.

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

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

The description is a single well-organized paragraph that front-loads the core action, then covers output format, defaults, and name resolution. Every sentence provides necessary information without fluff or repetition, making it appropriately sized 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?

The tool has moderate complexity (grouping, defaults, output formatting, name resolution) and only a readOnlyHint annotation. The description covers all key behaviors: default to latest, grouping options, markdown table sorting, unclassified row handling, and partial name resolution. No output schema exists, but the description adequately explains the return value shape.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains that reportDate snaps to the nearest report on or before the given date, and that institutionName can be a CIK or unique partial. These details are valuable and not present in the schema.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource ('institution's 13F portfolio allocation') and the grouping dimensions ('fine-grained industry' or 'sector'). It distinguishes from siblings like GetInstitutionPortfolio by focusing on allocation grouped by industry/sector rather than raw 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 explicitly instructs users to use SearchInstitutions for an exact CIK, and clarifies that ambiguous partial names return candidates rather than silently resolving. It does not explicitly contrast with sibling tools like GetInstitutionPortfolio, but the use case (allocation by sector/industry) is clearly implied. A 'when-not-to-use' statement would make it 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 specify readOnlyHint=true; the description adds valuable behavioral context by clarifying the value is 'long U.S. positions only, not total firm AUM' and explaining the candidate-returning behavior for ambiguous names. It does not disclose return structure or error handling, but for a simple read-only summary this is adequate.

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

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

The description is two sentences, front-loaded with the output fields, and includes only necessary caveats and disambiguation guidance. Every clause earns its place; no filler or redundancy.

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

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

With no output schema, the description enumerates the key return values (value, count, concentration, turnover, dates) and provides important scoping caveats. It also references a related tool for CIK resolution, making the workflow complete for a two-parameter read-only tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description reinforces the CIK-resolution behavior already in the schema ('Resolve exact CIKs with SearchInstitutions') but adds no new parameter-level semantics beyond the schema text. The reportDate snapping behavior is only in the schema, not the description, but is already covered.

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 a 'portfolio summary header' for an institutional 13F filer, with a specific list of fields (13F reported value, position count, concentration, turnover, report dates). It explicitly differentiates from total firm AUM and other institutional tools by noting 'long U.S. positions only, not total firm AUM', distinguishing it from siblings like GetInstitutionPortfolio.

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 points to SearchInstitutions as the proper tool for resolving exact CIKs and warns that ambiguous partial names return candidates rather than silently selecting a filer. It does not explicitly state when to use this tool over other institution tools, but the purpose and field list give clear context for summary needs.

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 readOnlyHint is already declared in annotations, and the description adds value by detailing the returned data (names, SEC file number, AUM, employee count, fee structure). It avoids contradicting annotations and covers return semantics in the absence of an output schema.

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

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

The description is two sentences; the first packs meaningful detail about the output without redundancy, and the second is a useful pointer to the sibling search tool. 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?

For a single-parameter read-only lookup with no output schema, the description fully explains what the tool returns and how to obtain the required input. The absence of pagination/auth notes is acceptable given the tool's simplicity and the readOnlyHint.

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 repeats the parameter name ('Organization CRD number') rather than adding new semantics beyond the schema's own description. The added example in the schema is sufficient, so the description provides no extra parametric insight.

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') with a clear resource ('full Form ADV profile') and a specific identifier ('Organization CRD number'). It also enumerates the key fields returned, distinguishing it from sibling tools like SearchInvestmentAdvisers and GetFundProfile.

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 this tool by specifying the required input (CRD number) and directs the user to the alternative SearchInvestmentAdvisers for finding CRD numbers. This provides clear usage context and a named alternative.

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

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

The description goes beyond the readOnlyHint annotation by explaining speaker attribution behavior, including how trusted resolutions are shown with names/roles and unverified voices fall back to role labels or numbers. This adds meaningful context not covered by annotations or schema.

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

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

The description is compact and front-loaded; the first clause states the core purpose, and each subsequent sentence adds essential context about speaker resolution and usage. No filler or redundancy.

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

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

For a read-only retrieval tool with a well-covered schema and no output schema, the description adequately describes the return content (speaker turns with attribution) and prerequisites (event ID). It does not detail pagination mechanics, but the schema handles limit/offset, so the context is sufficiently complete.

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

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

Schema coverage is 100%, so the parameter semantics are already fully documented. The description adds no new parameter information beyond what the schema provides, even citing the ListInvestorEvents source that is already in the schema, so the 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 returns a speaker-labelled transcript for a specific investor event, using a specific verb and resource. It distinguishes from siblings like GetEarningsCallSpeakers by explicitly noting its use for non-earnings events and referencing ListInvestorEvents for the ID.

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 this for conferences and other non-earnings events, implying when not to use it (for earnings events with fiscal quarters). However, it does not name the alternative sibling tool, so it stops short of the highest bar for alternative identification.

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 set readOnlyHint=true; the description adds behavioral context beyond that, including that data is scraped from the company IR website, coverage is partial, results are sorted soonest-first, and unclassified events only appear without an eventType filter. No contradiction with annotations.

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

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

Two focused sentences: the first states the tool's purpose, result ordering, and optional filter; the second covers the coverage caveat and alternatives. Every sentence earns its place with 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?

The tool has no output schema and only a readOnlyHint annotation, so the description carries the burden. It covers data source, future-only behavior, sorting, filtering, coverage limitations, empty-result interpretation, and sibling alternatives, making it sufficient for correct invocation.

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

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

All three parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description reinforces eventType semantics and adds a few examples, but it does not materially extend the schema's parameter-level documentation.

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

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

The description opens with 'Get upcoming investor-relations events for a stock' — a specific verb and resource — and enumerates the event types covered. It also distinguishes itself from siblings by explicitly directing past-event/transcript needs to ListInvestorEvents/GetInvestorEventSpeakers.

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 temporal scope ('Only future events are returned'), names alternatives for past events and transcripts, and explains when an empty answer means a coverage gap rather than an empty calendar. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already mark the tool as readOnly, and the description adds significant behavioral detail: results are reverse-chronological, sourced via IR-page scraping, coverage is partial, and the response distinguishes a coverage gap from actual silence. No contradiction with annotations.

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

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

The description is front-loaded and logically organized, with each sentence contributing meaning. It is slightly redundant ('recent' in the first sentence and 'most recent' in the second, and 'IR website' repeated twice), but remains compact and readable.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: it lists the fields, ordering, source, and coverage limitations. This sufficiently equips an agent to interpret results and handle edge cases.

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 clear descriptions for ticker, since, and maxResults. The description adds no parameter-specific semantics beyond the schema, so the baseline score of 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?

The description names the exact verb and resource: 'Get recent investor-relations press releases for a stock, scraped from the company's IR website.' It also distinguishes the tool from third-party news and specifies the returned items (headline, publish date, summary, link), making its purpose unmistakable relative to siblings.

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

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

The description gives clear usage context: 'Use this to see a company's latest official announcements straight from its IR page, distinct from third-party news.' This implies when to use it but does not explicitly name alternative tools or state when not to use it.

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

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

Annotations declare readOnlyHint=true, consistent with description. Description adds that all information is verified against filing text and missing fields are reported as 'not stated', never estimated, which builds trust.

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 lists many details efficiently, but is somewhat verbose. Could be slightly more concise without losing clarity.

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

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

No output schema, but description enumerates all fields returned: lifecycle status, ticker, exchange, price range, quotes, business description, use of proceeds, underwriters, risk factors, financials, filing chain. Covers everything clearly.

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

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

Only one parameter (cik) with schema description already covering leading zeros. Description adds minimal extra value ('as listed by GetIpoFeed'). Baseline 3 for 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?

Title and description clearly state it retrieves detailed IPO registration information by CIK. Distinguishes from sibling tool GetIpoFeed which lists IPOs, by specifying 'one IPO registration's full picture'.

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

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

States the CIK should be 'as listed by GetIpoFeed', providing sequential guidance. Does not explicitly mention when not to use, but context is clear.

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

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

Beyond the readOnlyHint annotation, the description discloses substantial behavior: data source (SEC filings), extraction and verification methods ('extracted from the prospectus and verified against its text'), handling of missing annual data ('say whether the import is pending or completed'), and the SPAC classification basis (SIC 6770). This gives a rich, transparent picture with no contradictions to annotations.

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

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

The description is a single dense paragraph but well-organized, with the core purpose front-loaded and subsequent clauses logically adding details. Every sentence contributes value, though it is longer than the typical description; this is justified by the tool's complexity.

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

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

Despite having no output schema, the description thoroughly covers the return contents, edge cases, and relationship to sibling tools. It even explains what rows without annual data contain, making the tool's behavior predictable and complete for a feed.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context by explaining the purpose of filerType (splits out SPACs using SEC's SIC 6770 classification) and reinforcing that status filters by lifecycle stage. This goes beyond the schema's bare parameter descriptions, though not extensively.

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 clearly identifies the resource ('US IPO pipeline'), enumerating exact contents (S-1/F-1 registrants, lifecycle status, financials). It distinguishes itself from the sibling GetIpoDetails by stating the feed is the only surface covering pre-IPO companies and pointing to GetIpoDetails for full detail.

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

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

The description explicitly states when to use this tool ('Pre-IPO companies... this feed is the only surface that covers them') and directs the user to GetIpoDetails for the full picture. It also provides rationale for using the filerType filter due to SPAC dominance, giving clear context on 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 only declare readOnlyHint=true. The description adds significant behavioral context: data source (FINRA daily short sale volume files), default date behavior, sorting order, explanation of Short % as off-exchange/TRF volume share with a 40-50% normal baseline, and a clear NOT short interest caveat. This goes well 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?

Purpose is front-loaded in the first sentence. The second sentence contains the caveats and sibling distinctions in a dense but efficient structure. It is slightly long-winded with parentheticals, but every clause earns its place.

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

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

With no output schema and only a read-only annotation, the description covers all essential context: purpose, scope, data source, metric definition, sorting defaults, caveats about shortPercent ranking, and explicit alternatives. The agent has enough 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?

Input schema provides 100% parameter description coverage, so baseline is 3. The description reinforces the sortBy=shortPercent behavior with a minTotalVolume floor, but this guidance is already present in the schema's sortBy parameter description. No new parameter semantics are added 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 uses a specific verb+resource: 'Get the stocks with the largest daily short sale volume for a single trading day' and explicitly distinguishes from related tools by naming GetShortVolume and GetShortInterest. The scope (single day, sorted by short volume descending) is exactly stated.

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 alternatives: 'use GetShortInterest/GetShortInterestSnapshot for positions and GetShortSqueezeScores for squeeze candidates; use GetShortVolume for one stock's daily history.' It also provides concrete guidance on using sortBy=shortPercent with a minTotalVolume floor to rank by short intensity.

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

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

Beyond the readOnlyHint annotation, the description adds meaningful context about the data source (legacy futures-only COT report), timing (positions as of Tuesday, published Friday), and units (contract counts). This is useful but does not cover all possible behavioral details.

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

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

The description is two sentences, front-loaded with the main action, and every sentence adds value. It efficiently conveys the tool's purpose, scope, data source, timing, and relation to a sibling 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 tool's simplicity (one optional parameter, no output schema), the description sufficiently covers return value composition, grouping, timing, and linkage to GetCftcPositioning. Minor details like exact row fields are omitted but not critical for usage.

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

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

The input schema already documents the 'category' parameter fully with enumerated values and a default. The description lists categories in parentheses but adds no additional parameter 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 clearly identifies the tool as retrieving the latest COT positioning snapshot across all tracked futures contracts, grouped by category. It distinguishes the tool from sibling GetCftcPositioning by noting that each row carries the market code accepted by that tool.

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

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

The description provides clear context that this tool is for a broad, latest snapshot, and implies that GetCftcPositioning is the next step for specific market codes. However, it does not explicitly state when not to use this tool or name alternative scenarios.

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

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

The annotation readOnlyHint=true is respected, and the description adds useful behavioral detail about the output structure: each row contains the latest observation, its date, the previous observation, and the change. This goes beyond the annotation to explain freshness and direction, which is valuable for an AI agent.

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

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

The description is three sentences, front-loaded with the core purpose, and every sentence adds value – purpose, output format, and use case. 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?

For a tool with one optional parameter and no output schema, the description is highly informative. It explains what data is returned, how to interpret freshness and change, and the scope of categories, making it self-sufficient for an agent.

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

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

The input schema already fully documents the single `category` parameter with allowed values and default. The description's list of categories largely duplicates the schema description, adding no new semantic information about the parameter.

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

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

The description clearly states the tool retrieves the latest values for key economic indicators across a comprehensive list of categories. The verb 'Get' and resource 'latest values for key economic indicators' is specific and distinguishes it from siblings like GetEconomicIndicator (singular) and SearchEconomicIndicators (search).

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

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

The description provides clear context that this returns a broad snapshot of current macro conditions, suitable for getting a general economic overview. However, it does not explicitly name alternatives for specific indicator lookups or exclusion cases, so it falls short of a full 5.

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

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

The description goes far beyond the readOnlyHint annotation, disclosing subtle behavior: change columns are one-session moves, dates can differ within a response due to settlement, 52W range is based on daily closes, raw rows lack split-basis metadata, and Off High/Above Low are percent distances. These are non-obvious behaviors critical for correct 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 fairly long but every sentence carries substantive behavioral information needed to interpret results correctly. It is front-loaded with the purpose and use case, followed by necessary caveats. While not as terse as ideal, none of the text is redundant 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 that there is no output schema, the description fully explains the meaning of each returned field, including edge cases like one-session change, date discrepancies, and 52-week range calculation. It also addresses limitations such as lack of split-basis metadata, making the tool's behavior predictable for the user.

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, tickers, is already fully described in the schema (format, max 25, class share notation). The description adds no additional parameter detail beyond what the schema provides. With 100% schema coverage, the 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 opens with a specific verb and resource: 'Get the most recent closing price (USD), daily change, volume, and trailing 52-week range for one or more stocks.' It clearly identifies what the tool does and distinguishes itself from siblings like GetLiveQuote (live quotes) and GetStockPrices (history) by emphasizing 'most recent closing price' and 'settled daily bar'.

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

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

The phrase 'Useful for quick price checks across a portfolio or watchlist' provides clear context on when to use this tool. It implies that for live quotes users should look elsewhere (e.g., GetLiveQuote), though it does not explicitly name alternatives or exclusions. This is sufficient guidance for proper selection.

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

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

Beyond the readOnlyHint annotation, the description discloses that readings only update during US market hours, returns last session reading otherwise, and lists tickers without a live reading separately. It also notes data may be real-time or 15-minute delayed, providing important expectations for the agent.

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

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

The description is front-loaded with the core purpose and uses five sentences to cover purpose, output fields, usage distinction, and edge cases. All sentences add value, though a bit dense; still 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 only one parameter, a read-only annotation, and no output schema, the description provides sufficient context: purpose, field details, usage guide, and edge cases. It does not specify the exact response container (e.g., JSON object), but 'Each row' implies a list, which is adequate.

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

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

The single parameter 'tickers' is fully described in the schema (100% coverage), including format and max count. The description's mention of 'one or more stocks' adds no new meaning beyond the schema, but does not need to compensate.

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 current intraday price, specifying it is a live market reading rather than a daily bar. It distinguishes itself from GetLatestPrices and GetStockPrices by contrasting live price with recent close and daily 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?

Explicitly says 'Use this for "what is it trading at now"; use GetLatestPrices or GetStockPrices for the most recent CLOSE and daily history.' It also describes behavior outside market hours, giving clear context for when this tool is appropriate.

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

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

Annotations already declare readOnlyHint=true, lowering the bar. The description adds valuable behavioral context beyond that: the early-close time of 1:00 p.m. ET, NYSE/Nasdaq coverage, and the curated range limitation with a non-guessing fallback. This exceeds the minimum required 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?

The description is two sentences. The first sentence front-loads the core purpose with the verb and resource. The second sentence adds a critical caveat about the curated range. 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 simple read-only tool with one optional parameter, the description fully covers purpose, default behavior, exchange coverage (NYSE/Nasdaq), and the range limitation. No output schema is present, but the description sufficiently informs the user of what will be returned (a list of holidays and half days).

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 year parameter with type, default, and description (100% coverage), providing a baseline of 3. The tool description adds practical meaning beyond the schema by repeating the default and introducing the important range constraint ('curated for 2025 through 2027'), which helps users understand valid inputs.

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

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

The description uses the specific verb 'List' and clearly specifies the resource: 'US equity market holidays and early-close (1:00 p.m. ET) half days for a calendar year (NYSE/Nasdaq).' This distinguishes it from siblings like GetEconomicCalendar and GetMarketStatus, making the tool's function unambiguous.

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

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

The description provides clear usage context: 'Defaults to the current year' and 'curated for 2025 through 2027; a year outside that range reports so rather than guessing.' This tells users when the tool is appropriate and what happens for invalid years, but it does not explicitly name alternative tools or when not to use it.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable context beyond that: it specifies the timezone (America/New_York), the fact that it's based on the exchange's curated calendar rather than a heuristic, and the variety of status details returned. This gives agents a clear picture of the tool's behavior without contradicting annotations.

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

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

The description is a single, information-dense sentence that front-loads the core action and then lists the specific outputs. Every element adds value, with no redundant or vague phrasing. It is concise yet comprehensive.

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?

Since there is no output schema, the description must fully explain return values, and it does: it lists status, session, holiday/early close, regular and extended hours, and next open/close. It also mentions data provenance. This is complete for a zero-parameter, read-only 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 zero parameters, the description has no parameter semantics to add, and the baseline for 0 params is 4. The description fully compensates by explaining what the tool returns, so the agent understands the tool without needing parameter docs.

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 the current US equity market status for NYSE/Nasdaq, with a specific verb and resource. It distinguishes from siblings by enumerating the exact outputs (open/close, session, holiday/early close, trading hours, next open/close) and referencing the exchange's curated 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 for when to use the tool: when needing current market status, session, or trading hours. It does not explicitly mention alternatives or exclusions, but the specificity implies its use case. Sibling GetMarketCalendar exists, but no comparative guidance is given, so it doesn't reach the explicit when-to-use vs. alternatives bar.

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 important behavioral details: bucket-specific ranking logic (Δ shares > 0, sorted by Δ value), and the critical nuance that Δ Value includes the quarter's price move while Δ Shares represents the actual position change. This adds significant informational value without contradicting annotations.

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

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

Every sentence serves a purpose: the core definition, bucket specifications, metric caveat, and use-case all convey necessary context in a compact, front-loaded structure. It's longer than minimal but each clause is substantive.

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

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

With no output schema, the description hints at return content (leaderboards with Δ Shares and Δ Value) but doesn't explicitly list response fields or pagination. Still, it covers the core concept, the four modes, and the key metric caveat, making it functionally complete for the intended query.

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 describes all three parameters, but the description enriches semantics by explaining each bucket's ranking condition and clarifying the difference between Δ Value and Δ Shares. This goes beyond the schema's simple enumeration of bucket options, though some detail (e.g., maxResults clamping) remains schema-only.

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 opens with a specific verb+resource: 'Get the market-wide 13F leaderboards for a given quarter' and enumerates the four bucket categories (most bought, sold, initiated, exited). It distinguishes itself from institution-specific siblings like GetInstitutionQuarterlyActivity by emphasizing 'market-wide' and 'across all 13F filers.'

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 clear use-case: 'Use this to answer "what's the consensus 13F move this quarter?"' and implies when it's appropriate (market-wide consensus). However, it doesn't explicitly name alternative tools or when not to use it, so not 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?

Discloses that the window anchors on disclosure date, explains the 45-day filing deadline, and notes that amount ranges are estimated via midpoints, which is crucial for interpreting results. Annotations already mark read-only, and the description adds rich context without contradicting them.

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

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

Description is dense but every sentence carries distinct information: purpose, time window rationale, row composition, parameter behaviors, and sibling alternatives. No filler, well-structured with clear front-loading.

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

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

With no output schema, the description provides a thorough breakdown of row contents and aggregate metrics, plus edge-case context (late filings) and sibling fallbacks. Sufficient for an agent to select and interpret the tool.

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

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

All four parameters are already described in the schema (100% coverage). The description adds semantic clarity for direction (buys/sells) and chamber, and explains how they affect ranking, which goes slightly beyond the schema's bare 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 returns market-wide congressional stock trading aggregates over a trailing window, with explicit mention that it does not require a ticker or member name. This distinguishes it from siblings like GetCongressionalTrades and GetMemberTrades.

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 market-wide aggregation context, and explicitly names alternatives for single-stock and single-member looks. Provides a representative query 'what did Congress buy this week' to clarify the intended use.

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

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

Beyond the readOnlyHint annotation, the description discloses that values are range bands rather than point estimates and that missing years imply no electronic filing, not zero net worth. This is essential behavioral nuance that prevents misinterpretation and exceeds what annotations convey.

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

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

The description is three sentences with no filler, front-loading the core purpose and then adding distinct, valuable caveats. Each sentence contributes new information: what it returns, how values are represented, and how to interpret missing years.

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

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

With no output schema, the description explains the return format conceptually (annual range bands) and how to treat missing data. It could specify the exact response shape or field names, but the provided details are sufficient for an agent to understand 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?

The schema already provides thorough descriptions for both parameters, including case-insensitivity, examples, defaults, and max results. The tool description adds domain context about annual disclosures but does not materially enhance parameter-level understanding beyond the high 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 begins with 'Get a congress member's net worth history,' clearly identifying the specific verb and resource. It distinguishes this tool from siblings by noting annual financial disclosures and range-based values, which is distinct from trade-related tools like GetMemberTrades and GetCongressionalTrades.

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 instructs to use SearchCongressMembers to find member names, providing concrete usage context. It also clarifies that missing years indicate no electronic filing, which is critical for interpreting results. It does not explicitly list alternative tools for net worth, but enough context is provided.

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

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

Annotations already declare readOnlyHint=true, so the description adds additional behavioral context beyond that, such as default date range ('last year by default') and output fields ('Shows tickers, transaction and filing dates, disclosed amount ranges, and the filed Asset'). This provides useful details without contradicting the read-only hint.

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

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

The description is two sentences, with the primary purpose in the first sentence and supporting details in the second. Every sentence contributes value, and it is front-loaded with the most important information. No fluff or redundant wording.

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

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

Given the tool's complexity (6 params, no output schema), the description adequately covers the essential context: what it returns, ordering, default date range, and alternative tools. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with detailed descriptions for all six parameters. The description does not add much parameter-specific meaning beyond what is already in the schema, such as the default date range and pagination behavior. It maintains the baseline without introducing extra context.

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

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

The description clearly states the tool's function: 'Get a congress member's disclosed securities transactions' with specifics like 'newest first, last year by default'. It also differentiates from siblings by explicitly mentioning GetCongressionalTrades for all members in one ticker, making the purpose unmistakable.

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

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

The description provides explicit usage guidance: 'Use SearchCongressMembers to find member names, and GetCongressionalTrades for all members' transactions in one ticker.' This tells the agent when to use alternatives and implies when to use this tool (when querying a specific member).

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, the description discloses key behaviors: default sorting, how funds lagging during the filing window are carried at prior-quarter positions, and that fully-sold-out names are excluded. It also lists the output fields (Δ filers, total value, Δ value, share) which is especially valuable given no output schema.

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

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

The description is front-loaded with the core purpose and then packs in essential details (sort options, output fields, edge cases) without wasted words. Every sentence serves a purpose, and the length is appropriate for the tool's complexity.

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

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

Given the absence of an output schema, the description compensates by listing the returned metrics and explaining edge cases like the filing-window carry-forward and the sold-out-name exclusion. It also explicitly names the close sibling for alternatives, making the tool's scope fully clear.

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

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

The input schema already covers all three parameters with 100% coverage, so the baseline is 3. The description adds meaningful context for the 'sort' parameter by explaining the warming/cooling semantics and default behavior in prose, and it clarifies the reportDate's relationship to the filing window, adding value beyond the schema.

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

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

The description uses a specific verb ('Get') and identifies both the resource ('cross-sectional ranking of stocks by institutional 13F breadth') and the temporal scope ('for a given quarter'). It clearly differentiates from siblings by explicitly naming GetMarketWide13FActivity for sold-out names and stating the tool's focus on currently-held stocks.

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

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

It provides explicit when-to-use guidance with the example question 'which stocks are most owned by institutions right now, and is breadth expanding or contracting?' It also states a clear exclusion: 'Only currently-held stocks rank; fully-sold-out names live in GetMarketWide13FActivity's sold-out-positions bucket,' naming the alternative tool.

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