equibles

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

Annotations only indicate a non-read, non-destructive operation. The description adds substantial behavior: rejects unknown/expired contracts, requires verified OCC symbols for options, signed quantity semantics, positive costPerUnit, and idempotent retries within a duplicate window. This goes well beyond annotations and is critical for correct usage.

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

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

The description is dense but each sentence adds unique value. It leads with purpose, then covers inference prohibition, instrument specifics, quantity/cost semantics, and idempotency in a logical order. No redundant or filler content; every sentence earns its place.

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

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

Given the tool's complexity (7 parameters, 5 required) and no output schema, the description covers all critical usage constraints: instrument selection, signed quantity, cost semantics, rejection rules, and duplicate behavior. It doesn't mention prerequisites like portfolio existence, but that's a minor gap likely handled elsewhere. Overall, it's quite complete for a write operation.

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, so the baseline is 3. The description adds meaningful cross-parameter context: that for options you must pass both the underlying ticker and the optionContract, and that costPerUnit is never the per-contract total. These relationships are not explicit in the schema, elevating 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 first sentence states a specific verb ('Record') and resource ('a user-confirmed purchase or sale in the caller's portfolio'). It clearly indicates this is a write operation for adding lots, distinguishing it from siblings like UpdatePortfolioLot, RemovePortfolioLot, and GetMyPortfolio. The purpose is 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 gives clear context for instrument types (stock vs option), requires user confirmation ('Never infer or guess'), and explains idempotency for retries. It does not explicitly name alternative tools, but the context and sibling names make it obvious that this is for adding new lots. The guidance is solid but could be strengthened by explicitly saying 'use this to add a new lot, not to modify or close an existing one.'

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

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

Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false (not destructive). The description adds valuable context: 'The lot moves out of the open positions and its realized profit is kept.' It explains partial close splitting behavior and how options work. This goes beyond annotations and provides necessary behavioral disclosure.

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

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

The description is well-structured: first paragraph states the primary action with a critical user instruction, second explains partial close behavior, third handles options edge cases. Every sentence adds value, no redundancy, and key information is front-loaded.

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

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

Given the tool's complexity (partial close, options handling) and the absence of an output schema, the description covers the recording action, user interaction requirement, splitting behavior, and connection to AddPortfolioLot. A brief note on the expected response (e.g., confirmation or updated portfolio) would make it fully complete, but the current level is strong.

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 meaning: clarifies that quantity is optional (omit to close all), closeDate cannot be future or before acquisition, and closePrice is per share received/paid (zero for expired worthless). This adds value beyond the schema's own descriptions, especially for the zero-price case and the partial close behavior.

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 verb 'Record that the USER sold (or covered, or let expire)' and the resource 'all or part of a lot'. It distinguishes from siblings by noting that options exercised/assigned require a separate AddPortfolioLot for resulting shares, and implies a difference from RemovePortfolioLot by focusing on recording a sale with price and date.

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

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

The description provides explicit guidance: 'Ask the user for the closing price and date; never guess them from a market quote.' It explains how to handle options (expired worthless at price 0, exercised/assigned leads to AddPortfolioLot). While it does not explicitly list when not to use this tool versus RemovePortfolioLot or UpdatePortfolioLot, the context and examples are clear enough for correct usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description correctly doesn't repeat that. It adds behavioral detail beyond those annotations: the return format (one row per ticker, latest-restated value, separate listing for tickers with no data) and the fiscal calendar alignment caveat. This enriches the agent's understanding of the tool's output without contradicting the annotations.

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

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

The description is two concise sentences: the first states the primary purpose and return behavior, the second provides a critical caveat about fiscal calendar variation. Every sentence earns its place, with the main purpose front-loaded and 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 read-only comparison tool with no output schema, the description adequately covers key operational details: the return row structure, treatment of missing data, and the fiscal calendar nuance. It even directs the agent to check the Period End column, which implies that column exists. This is sufficient for an agent to call 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?

The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds extra meaning by highlighting that fiscalYear/period refer to each company's own fiscal calendar, which is not explicitly stated in the schema descriptions but is crucial for interpreting results. This goes beyond the schema to clarify a potential source of confusion.

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: comparing a single financial concept across multiple companies for a given fiscal period, explicitly calling it 'peer comparison'. It also specifies the return structure ('one row per ticker...') and distinguishes itself from single-company tools like GetFinancialFact by its multi-company focus.

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 important usage context, notably that fiscal years follow each company's own calendar and that peer rows can cover different months, urging the agent to check the Period End column. However, it does not explicitly name alternative tools or specify when not to use it, though the peer-comparison purpose implies the appropriate 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?

The description goes beyond the readOnlyHint annotation by disclosing operational nuances: published values normally use report-date closing prices, may fall back to filer values, and can be zero when unavailable. This is material behavioral context that an agent needs to interpret results correctly.

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 carrying distinct value: what the tool does, what it returns, how to interpret data caveats, and which sibling to use instead. The most important information is front-loaded and there is no filler or repetition of schema 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?

Despite having no output schema and minimal annotations, the description covers purpose, return values, data caveats, name resolution, and the key alternative tool. For a read-only comparison tool with four well-documented parameters, this is sufficient for an agent to select and invoke it correctly.

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

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

Schema coverage is 100%, so the schema already fully documents all four parameters. The description adds some context about the 'latest common report date' and the fact that inputs are institution names, but it does not materially enrich parameter understanding 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 starts with a strong verb and resource: 'Compare two institutions' 13F portfolios' and specifies the exact output: Jaccard and dollar-weighted overlap, portfolio totals, and shared or unique positions. It also distinguishes itself from GetFundProfile for NPORT portfolios, making it clear what the tool is not for.

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 to use SearchInstitutions for resolving filer names and to use GetFundProfile for mutual-fund or ETF NPORT portfolios instead. This gives clear routing guidance and tells the agent when this tool is appropriate versus when an alternative should be chosen.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds context: the portfolio is empty initially, holdings must be added separately via AddPortfolioLot, and duplicate names are rejected rather than merged. This provides useful behavioral detail beyond the annotations.

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

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

Two sentences, front-loaded with purpose, no wasted words. Every sentence adds essential guidance.

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

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

For a simple tool with one parameter and no output schema, the description covers creation, uniqueness, user consent, and follow-up actions. It is fully sufficient.

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

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

Schema coverage is 100% with a clear description of the 'name' parameter. The description adds value by explaining uniqueness constraints and rejection behavior, which are not in the schema.

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

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

The description clearly states it creates a new empty portfolio in the user's account, and explicitly mentions the sibling tool AddPortfolioLot for adding holdings, distinguishing it from other tools.

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

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

The description instructs the agent to ask the user before creating, providing explicit user consent guidance. It also notes uniqueness constraints and rejection behavior, though it does not explicitly list alternatives or when not to use.

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

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

The description goes beyond the destructiveHint=true annotation by detailing exactly what is destroyed: 'every lot in it, open and closed', and what is lost: 'recorded cost basis and realized-profit history'. It emphasizes irreversibility. 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?

Three concise sentences, each substantive. First sentence states action and scope, second explains consequences and irreversibility, third provides safety guidance. No wasted words.

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

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

Given the tool has only one parameter, no output schema, and annotations are present, the description fully covers purpose, usage guidelines, behavioral transparency, and parameter context. The agent can confidently select and invoke this tool correctly after reading the description.

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

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

The single parameter 'name' has 100% schema description coverage, stating it requires 'The exact name of the portfolio to delete'. The description adds only contextual emphasis (confirming the name) but no new semantic details 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 clearly states the verb 'permanently delete one of the USER's own portfolios and every lot in it', specifying the resource (portfolio) and scope (including lots). It distinguishes this tool from sibling tools like RemovePortfolioLot or AddPortfolioLot by mentioning deletion of the entire portfolio.

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 the agent to 'ALWAYS confirm with the user first, naming the portfolio and how many lots it holds' and to call GetMyPortfolio if the number of lots is unknown. This provides clear contextual guidance on when and how to use the tool safely.

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 openWorldHint=false implies the tool returns complete results, while the description explicitly states that only the last ~13 months of filings are scanned and an empty result is not proof of absence. This is a direct contradiction, so per rubric transparency is 1. Despite extensive additional detail about normalization and estimation, the contradiction makes the description unreliable.

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

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

The description is long but every sentence adds value: return field list, normalization caveat, source/coverage limitation, and estimation disclaimer. It's front-loaded with the core purpose and logically structured, with 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 complex financial data tool with no output schema and minimal parameter schema, the description is exceptionally complete. It lists all output components, explains the source filings (10-K, 10-Q, 8-K), the time-window limitation, and the confidence level. The only minor gap is explicit response format, but it's not necessary given the field enumeration.

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

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

The only parameter, ticker, is fully described in the schema with examples and 100% coverage. The description doesn't add parameter-level detail, but none is needed for this self-evident parameter. Baseline 3 is appropriate.

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

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

The description clearly states 'Get a company's at-the-market (ATM) equity offering programs' and enumerates specific returned fields (agreement date, capacity, sales, availability, status, source filings). This is a specific verb+resource statement that distinguishes it from sibling tools like GetBuybackPrograms by focusing on ATM offerings.

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, explaining the 13-month filing scan window and warning that an empty result does not prove the company runs no ATM program. It also explains the data source and XBRL limitation, helping an agent interpret results appropriately. However, it doesn't explicitly name alternative tools or state when-not-to-use, but the caveats are 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 mark readOnlyHint=true and destructiveHint=false, and the description adds non-obvious behavior: the recursive smoothing is warmed up on price history before startDate, so output doesn't depend on the requested range's left edge. It also clarifies the unit (USD), which is useful 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?

Four dense sentences, each informative: definition, formula, use case, and behavior. No filler; the technical description 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?

No output schema exists, and the description doesn't explicitly state the return shape, but the maxResults parameter description covers record ordering and count. The description provides the essential interpretive and behavioral context (unit, warmup, volatility interpretation) needed to use the tool confidently.

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 value by explaining that period is a smoothing window used recursively and that startDate's left-edge warmup makes values stable; this goes beyond the schema's terse 'Start date in YYYY-MM-DD' definition.

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

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

The description opens with 'Average True Range (ATR) for a stock' and unpacks the indicator with a precise formula (True Range max of high-low, |high-prev_close|, |low-prev_close|), distinguishing it from related indicators like Bollinger Bands or Stochastic Oscillator. The scope is clear: a volatility measure for a single stock, in USD.

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

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

It states ATR is 'commonly used for position sizing and stop placement' and explains that higher ATR means wider daily moves, giving clear applied context. It doesn't explicitly name alternatives or when-not-to-use, but the domain is sufficiently specialized.

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 two important behaviors: the inclusion of %B and bandwidth columns, and the warm-up of the moving-average window on price history before startDate, which ensures values do not depend on the requested range's left edge. This adds significant context about data computation and edge-case handling that annotations alone do not provide.

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

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

The description is concise—three sentences that front-load the tool's purpose, then explain the calculation, interpretation, included columns, and a nontrivial edge-case behavior. Every sentence contributes meaningful information without waste 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?

Despite the absence of an output schema, the description adequately explains what the tool returns (BB bands, %B, bandwidth) and how the indicator behaves relative to the requested date range. It also covers the key formula components and the smoothing effect of the warm-up, providing enough detail for an agent to understand the tool's behavior without missing critical information.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters affect the output: 'moving average of close' corresponds to period, 'standard deviations above and below' corresponds to stdDev, and the warm-up behavior clarifies startDate semantics. This is more than just restating the schema, though it does not delve into every parameter detail, hence a 4.

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 'Bollinger Bands for a stock', clearly identifying the tool's purpose. It provides specific details about the calculation (middle band, upper/lower bands, standard deviations), distinguishes it from sibling indicators like GetAverageTrueRange or GetStochasticOscillator, and mentions included columns (%B, bandwidth), making the tool's scope unmistakable.

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

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

Usage context is provided through interpretive guidance: 'Bands widen when volatility rises and contract when it falls; price touching the upper/lower band is a common overbought/oversold cue.' This helps an agent decide when to use Bollinger Bands. However, it does not explicitly name alternatives or state when not to use this tool, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with these. It adds valuable context beyond the annotations: data sources (XBRL facts + verified filing extractions), the 'nothing is estimated' guarantee, and explicit staleness labeling for non-restated figures.

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 are used, and each earns its place: the first enumerates outputs, the second explains data provenance and staleness, and the third names the alternative tool. It is somewhat dense, but appropriately so for a complex data retrieval 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?

Even without an output schema, the description thoroughly covers what the agent will receive: program details, authorization figures, history fields (cash spent, shares, average price), and data provenance. The staleness label and explicit sibling reference complete the picture for a single-ticker 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?

There is only one parameter, ticker, and the input schema already describes it clearly ('Stock ticker symbol (e.g., AAPL, MSFT)'), giving 100% schema coverage. The description does not add specific parameter-level semantics, but none are needed given the schema's completeness.

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: a company's share-repurchase picture, including tracked programs, authorization figures, and repurchase history. It explicitly differentiates from the sibling GetAtmPrograms by naming the at-the-market mirror image.

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 final sentence explicitly directs the agent to GetAtmPrograms when ATM equity offerings are the focus, providing a clear alternative. It also gives context that figures come from XBRL facts and document extractions, helping the agent judge 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 read-only and non-destructive behavior. The description adds valuable context about the data source (legacy futures-only COT report), the reporting schedule (as of Tuesday, published Friday), and that values are contract counts, enhancing expectations beyond annotations.

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

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

The description is concise, three sentences, with the purpose front-loaded in the first sentence. Every sentence adds value—purpose, data characteristics, and a pointer to a related tool—with no unnecessary words.

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

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

Given the absence of an output schema, the description conveys the essential output characteristics (positions over time, contract counts, futures-only report). It could more explicitly describe the response format or number of reports returned, but the provided context is largely sufficient for a capable agent.

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

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

The schema descriptions cover all four parameters with 100% coverage, so the description adds little beyond the structured data. It does suggest using SearchCftcMarkets to obtain marketCode values, which is a minor useful hint, but this aligns with the baseline 3.

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

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

The description clearly states the tool retrieves COT positioning data for a specific futures contract and explains it shows commercial and non-commercial positions over time. It does not explicitly differentiate from the sibling GetLatestCftcData, but the purpose is specific and 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?

Provides clear context for when to use this tool (historical COT positions for a specific contract) and explicitly directs users to SearchCftcMarkets for finding market codes. No exclusions are stated, but the intended use case is evident.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail: values retain the company's stated scale, GAAP-to-non-GAAP reconciliation includes its stated bridge, and transcripts are not sources. These details explain what the tool does and does not return beyond the schema, enriching the agent's mental model 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 dense but efficient, with every sentence earning its place. It front-loads the core purpose, then details the parameter-dependent output, and ends with two important constraints (transcripts not sources, reconciliation bridge). There is zero fluff, and the structure leads with the most critical information for an agent deciding whether to use the 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?

The tool has no output schema, so the description must explain the return format. It does: 'period, filing date, source quote and exactly comparable year-over-year change.' It also specifies the scale handling and reconciliation behavior. While it doesn't mention pagination or limits, the tool is a read-only lookup with only two parameters and the description covers the essential facets an agent needs 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 coverage is 100% and the schema already describes the parameters, but the description goes further. It explains the metric parameter's behavior in detail: matching case-insensitively, listing candidates when multiple metrics match, and omitting for the latest reading. It also clarifies that values retain the company's stated scale, which is a semantic nuance not fully captured by the schema. This adds significant meaning beyond the structured fields.

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

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

The description states a specific verb ('Get'), a precise resource ('company-stated operational and non-GAAP KPIs extracted from written 8-K earnings releases and 10-K/10-Q MD&A'), and details the output fields (period, filing date, source quote, YoY change). It also distinguishes itself from related tools by explicitly limiting sources to written filings, not transcripts or other data types, so an agent can separate it from siblings like GetEarningsCallTranscript or 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 context about when to use the tool (to get company-stated KPIs from written filings) and an explicit exclusion: 'Earnings-call transcripts are not figure sources.' It provides a 'when-not' but does not name specific alternative tools for transcript-based data, so it stops short of a full 5. The parameter usage guidance (omit metric for latest reading, pass metric for history) also informs when to call with or without the metric.

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 read-only, and the description adds several useful behavioral details: results are newest first, the default lookback is one year, transaction amounts are disclosed ranges rather than exact values, and Asset refers to the filed instrument type. These are exactly the kind of behavioral nuances that prevent misinterpretation beyond 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?

Three sentences, no filler, with the core action and defaults front-loaded before the alternative routing. 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 there is no output schema, the description compensates well by describing what the response contains: members of Congress, transaction and filing dates, amount ranges, and the Asset field. Combined with thorough parameter schemas and a clear sibling pointer, nothing essential is missing for correct invocation and interpretation.

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

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

Schema description coverage is 100%, so the baseline is 3 because the schema already documents all parameters clearly. The description adds little beyond what the schema states; it echoes 'specific ticker' and 'last year by default' but does not materially enhance understanding of offset, maxResults, or transactionType.

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: getting congressional securities transactions for a specific ticker. It also clearly differentiates from the sibling GetMemberTrades by scoping this tool to one ticker, so an agent can select it without inspecting the schema.

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 GetMemberTrades as the alternative for one member's transactions across all tickers, giving a clear routing condition. This tells the agent when to use this tool versus that sibling, which is strong usage guidance.

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

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

Beyond the readOnlyHint annotation, the description discloses critical behavioral details: the correlation is computed on log returns, not raw price levels, dividends are excluded, only overlapping trading days are used, and candidates must meet a $100M market cap and sufficient overlapping days. It also notes that each row reports the observation count, adding transparency about data quality 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 dense paragraph that front-loads the main action and method, then efficiently covers scope options, direction, filters, output details, and alternatives. Every sentence adds value, with no redundancy or filler, making it highly information-dense yet concise.

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

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

Despite the absence of an output schema, the description is nearly complete: it explains the computation method, candidate selection criteria, output semantics (each row reports observation count), and provides explicit cross-references to related tools. It gives users a thorough understanding of what to expect and when to use it, with no significant gaps for a read-only data retrieval tool.

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

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

With 100% schema coverage, the schema already documents parameter basics. The description adds meaningful context for scope (e.g., 'Industry ranks the subject's direct industry peers; Market surfaces cross-industry relationships') and direction (negative for hedge candidates), which goes beyond the schema's brief descriptions. However, it does not add much for days or maxResults, which are adequately covered by the schema alone.

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

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

The description clearly states the tool's function: finding stocks whose daily price returns are most or least correlated with a given stock. It specifies the statistical method (Pearson correlation of daily log returns) and distinguishes itself from sibling tools by emphasizing correlation rather than price or fundamentals.

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

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

It explicitly instructs when to use this tool versus alternatives: 'Use GetStockPrices for the underlying series and the screener for fundamentals-based peer sets.' It also explains the scope choices (Industry, Sector, Market) and when negative correlation is useful for hedging, providing clear context for tool 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?

The description discloses key behavioral traits beyond the annotations: it explains the two data sources (XBRL-tagged vs narrative extraction with verbatim quotes), clarifies that a 'miss is never a statement of no risk,' and describes the trend functionality with maxFilings. This adds significant context that is not captured in the readOnlyHint or destructiveHint annotations.

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

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

The description is concise at roughly 4 sentences, with no filler. It is front-loaded with the core purpose, then efficiently covers data sources, interpretation of results, and parameter guidance. Each sentence serves a distinct purpose 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 having no output schema, the description provides a comprehensive picture of what the tool returns: example of the disclosure, fields included (basis, customer count, percentage, period, source filing), and the difference between XBRL and narrative extraction. It also notes the important caveat about misses and the trend option. This is 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?

Both parameters have descriptions in the schema (100% coverage). The description adds value by explaining the use case for maxFilings (>1 shows concentration trend), which goes beyond the schema's description of 'how many of the newest disclosing filings to return.' This extra context helps the agent decide when to adjust 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 a company's customer-concentration risk disclosure, specifying the types of data returned (percentage, basis, customer count, period, source filing). It distinguishes from siblings like GetFinancialFact by focusing on this specific risk and mentioning examples (NVDA, AAPL) and the use of XBRL vs narrative extraction.

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 (to get customer concentration risk) and gives explicit guidance on the maxFilings parameter ('Pass maxFilings > 1 to also see earlier filings' disclosures'). However, it does not explicitly mention when not to use this tool or suggest alternative tools for related queries, such as GetFinancialFact for general financial 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 already convey readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context by revealing that the response bundles current balances, a filing observation, covenant bullets, exact source quotes, and SEC documents, and that history, covenants, and documents are independently paged. This goes beyond the annotation baseline.

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

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

Three sentences with no filler: the first states the core purpose, the second summarizes the returned data, and the third covers paging and prerequisite. The most important information 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?

For a 10-parameter read tool with no output schema, the description adequately describes what will be returned, notes that subresources are paged independently, and routes the agent to the prerequisite call. Remaining details like evidence character limits are fully specified in the schema.

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

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

Schema description coverage is 100%, with all ten parameters documented including defaults, maximums, and offsets. The description reinforces that instrumentId comes from GetDebtProfile and that collections page independently, but it does not materially add meaning beyond what the schema already states.

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'), a specific resource ('one durable debt instrument'), and a key ('Equibles identifier'), then enumerates the exact return contents. It clearly distinguishes this from the sibling GetDebtProfile by positioning that tool as the source of the identifier.

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 GetDebtProfile first to obtain the instrument identifier', giving the agent a concrete prerequisite and call sequence. It does not mention when not to use the tool or list alternative detail tools, but GetDebtProfile is the relevant sibling and the guidance is clear enough.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses meaningful methodology: the latest 10-K establishes the annual baseline, 10-Q/8-K filings update durable instrument records rather than creating duplicates, and unmatched observations are disclosed and excluded. This gives the agent accurate expectations about deduplication and data coverage.

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 carries distinct value: the core purpose, the deduplication behavior, and the pointer to the sibling tool. It is front-loaded with the main function and avoids repetition of schema 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 compensates by stating what results contain: instrument summaries, IDs, reported totals history, and disclosed unmatched observations. It could go slightly further in describing the paging-related outputs, but the parameter schema already covers paging parameters and the description covers the key behavioral details.

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 parameters are already well documented. The description adds context about output shape but does not add parameter-level meaning beyond what the input schema provides, 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 names a specific verb and resource: get a company's reported total debt history and identified notes, loans, and revolving credit facilities. It clearly differentiates this from GetDebtInstrument by describing summary-level output with instrument IDs.

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

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

The description explicitly points to GetDebtInstrument for paged covenants, filing observations, exact evidence, and SEC exhibits, which tells an agent when to choose the sibling instead. It does not explicitly state when to prefer GetDebtProfile over related debt tools, but the intended use is clearly implied.

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

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

Annotations already declare readOnlyHint true and destructiveHint false, so the safety profile is covered. The description supplements this with ordering behavior, row fields, ex-date semantics, the possibility of future ex-dates, and the primary-ticker/issuer-level restriction—valuable context beyond the annotations.

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

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

The description is four dense sentences with no filler. The core action and result ordering are front-loaded, followed by only high-value caveats that an agent needs before calling the 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?

Even without an output schema, the description tells the agent what each returned row contains, how results are ordered, how filters apply, and a critical ticker restriction. Combined with the schema's parameter documentation, this is complete enough for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter semantics by stating that date filters apply to the ex-dividend date and that records are tied to the current primary ticker, clarifying startDate/endDate and ticker beyond their schema descriptions.

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

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

The description states a specific verb and resource: 'Get a company's stored declared cash dividends newest first.' It clearly identifies the row contents, ordering, and the primary-ticker constraint, and no sibling tool covers dividend history, so an agent can distinguish it.

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 invocation context: date filters apply to the ex-dividend date, records are issuer-level, and only the current primary ticker is valid. It does not explicitly name alternatives or say when not to use this tool, but that is a minor gap given no sibling directly overlaps.

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=true annotation, the description discloses significant behavioral nuances: the narrative shift 'is derived from approved bullets and is not separately verifier-approved', comparisons 'use filed GAAP XBRL facts, never estimates', ordering is 'Newest quarter first', and quarters can be absent from the sequence because only approved briefs appear. These caveats prevent the agent from misinterpreting missing quarters or over-trusting the shift metric.

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

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

The description is long (four sentences) but every sentence earns its place: each adds a disambiguating constraint ('not analyst consensus', 'not separately verifier-approved', 'quarters can be missing'). It is front-loaded with the core content definition before the caveats. The density is justified given the tool's complexity, though it could trim some redundancy around ordering.

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 retrieval tool with no output schema, the description lists the return elements (TL;DR, points, quotes, shift, guidance deltas, reported quarter vs guidance) plus all caveats (verification status, missing quarters, XBRL facts). Annotations already cover the read-only safety profile. The only gap is that the exact return structure/field naming isn't specified, but the content inventory is sufficient for an agent to call 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 coverage is 100% — every parameter (ticker, limit, fiscalYear, fiscalQuarter) is already well-documented, including the clamp range for limit and the exact-period semantics for the fiscal fields. The description's 'Newest quarter first' and 'Omit both period fields for newest briefs' reinforce schema text but add little new meaning. Baseline 3 is appropriate since the structured schema carries the parameter 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 opens with a specific verb and resource — 'Get the AI Earnings Brief for a company's recent earnings calls' — and enumerates the exact content: verifier-approved TL;DR, bullish/bearish points, verbatim pull-quotes, and a narrative shift. It also carves out the data provenance ('company guidance, not analyst consensus... filed GAAP XBRL facts, never estimates'), which sharply distinguishes it from siblings like GetGuidance, GetEarningsCallTranscript, and GetEarningsCallToneAndThemes without naming them.

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

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

The description provides rich context about what the tool returns and its data constraints ('Only calls with an approved brief appear, so quarters can be missing from the sequence', 'Newest quarter first'). However, it never explicitly names sibling alternatives or states when NOT to use this tool in favor of GetGuidance, GetEarningsCallTranscript, or GetFinancialStatement. Usage context is implied through content specificity, but no explicit routing or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered; with annotations present the bar is lower. The description adds real behavioral context beyond that: the selection semantics (omit both period fields for the latest call; year alone selects the latest in that year; quarter alone selects the latest matching quarter) and the group-scope behavior that distinguishes this from single-artefact tools. It discloses what the call returns (status, artefact availability, linked document ids, guidance rows) without contradicting the annotations.

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

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

The description is front-loaded with the core purpose before moving to return content, sibling routing, and a concrete usage example. Every sentence earns its place — the return enumeration is useful given there is no output schema, and the sibling routing is essential. It is on the longer side (roughly 90 words) for a read-only getter, with slight redundancy between the artefact enumeration in sentence one and the return-content detail in sentence two, but it remains well organized and not wasteful.

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

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

Given the nuanced nullable-period selection rules and the absence of an output schema, the description carries the full burden of explaining return values — and it does: id (usable with GetInvestorEventTranscript), title, call date, status, artefact availability, transcript/earnings-release document ids, and extracted guidance rows. It also covers the period-selection semantics and onward routing. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3 even with no parameter details in the description. The schema already documents ticker, and the nullability/defaults and omission rules for fiscalYear and fiscalQuarter. The description echoes the 'omit the fiscal period for the latest call' rule but does not add material syntax or format detail beyond the schema. Value added is marginal but not absent, so a defensible 3.

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

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

The description opens with a specific verb+resource+scope: 'Get the earnings-call event for a company's fiscal quarter — the single record that groups the quarter's call artefacts.' It clearly distinguishes itself from siblings by naming GetEarningsCallTranscript, GetEarningsBrief, GetEarningsCallToneAndThemes, and GetInvestorEventTranscript as the tools for the underlying artefacts rather than the grouping event. An agent can tell this apart from the adjacent investors-event and transcript tools without inspecting either schema.

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

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

Usage direction is explicit and actionable: 'Use this to ask "what do we have for AAPL FY2025 Q3?" rather than chasing each artefact separately — or omit the fiscal period for the company's latest call.' It also routes onward behavior: 'When a transcript is available, read it with GetEarningsCallTranscript, or get the AI read via GetEarningsBrief / GetEarningsCallToneAndThemes.' When-to-use and alternatives are both spelled out, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond that: verifier-approved calls only, potential missing quarters with gap notes, and AI-scored nature of the data. It does not contradict annotations and enriches understanding of data quality and completeness.

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—three sentences—with the primary purpose stated upfront, followed by key data quirks and a usage hint. Every sentence adds value and there is no redundancy or filler.

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

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

For a tool with four parameters, full schema coverage, annotations covering safety, and a clear description of return content (tone scores, themes, mention counts), nothing essential is missing. The description even explains the gap-note behavior and ordering, making the tool fully navigable 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?

Schema description coverage is 100%, so all four parameters (ticker, limit, fiscalYear, fiscalQuarter) are already documented in the schema with meaningful descriptions. The tool description does not add any additional parameter-level detail beyond what the schema provides, so a 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 exact resource (company earnings calls), the specific outputs (net tone score, hedging score, key themes with mention counts and per-theme tone), and the ordering (newest first). It distinguishes itself from similar siblings like GetEarningsBrief and GetEarningsCallTranscript by focusing on AI-scored tone and themes.

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 clear context on when to use the tool ('to gauge how confident or guarded management sounded') and explains data availability quirks (verifier approval, gaps in quarters). However, it does not explicitly name alternative tools or state conditions for selecting this one over others, leaving some routing inference to the agent.

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

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

Beyond the readOnlyHint annotation, the description discloses when speaker identities appear (only trusted resolution) and how unverified voices are labelled (role or neutral number). This adds meaningful behavioral context about output reliability 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?

Two sentences with zero fluff. The core purpose is front-loaded, followed by behavioral nuance and a usage directive. Every word earns its place.

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

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

For a tool with no output schema, the description explains the output format (ordered speaker turns with attribution) and the identity resolution rule. It also provides a prerequisite check. The agent has enough context to decide and invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the fiscal quarter focus but adds no new parameter details; the schema already documents each parameter adequately. No compensation is needed.

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

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

The description clearly states the verb 'Get', the resource 'speaker-labelled transcript of a company's earnings call', and the scope 'for a fiscal quarter'. It also distinguishes from GetEarningsCallEvent by implying that tool checks existence, making the purpose unambiguous.

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

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

The description explicitly directs the agent to 'Use GetEarningsCallEvent first to check a transcript exists', which is a clear alternative tool and an explicit precondition. This is a strong usage guideline that prevents failed calls.

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=true annotation, the description adds rich behavioral context: it defines the importance tiers (High/Medium/Low) with specific examples, explains why FOMC meetings are excluded, and notes the default date range (next 30 days). These details help the agent understand the tool's limits and output semantics without needing to invoke 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 a dense single paragraph but logically structured: it starts with the main purpose, then defines tiers, mentions exclusions, defaults, and usage tips. Every sentence adds value, but the density makes it slightly less scannable than bulleted sections; still, it is concise and well-organized.

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

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

Given there is no output schema, the description carries the burden of explaining behavior. It covers data coverage, tier filtering, exclusions, defaults, and related tools, which is sufficient for correct invocation. It doesn't describe the exact return format (e.g., array of objects with fields), but the calendar concept is straightforward enough that this is a minor gap.

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

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

Schema coverage is 100% for all four parameters, so the baseline is 3. However, the description adds meaningful semantics: it defines the minImportance tier values (low/medium/high) and explains the default date behavior ('Defaults to the next 30 days'), clarifying startDate/endDate usage. It doesn't add much for maxResults beyond the schema's 'chronological' note.

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 the economic release calendar — scheduled (upcoming) and recent publication dates of US macro data releases', which clearly states the verb, resource, and scope. It distinguishes itself from sibling tools by specifying US macro data and explicitly excluding FOMC meetings, setting it apart from GetMarketCalendar and 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?

The description provides explicit alternatives: 'FOMC meetings are NOT included ... use the Federal Reserve's published meeting calendar for those' and 'use GetEconomicIndicator to fetch a series' data after it prints.' It also gives usage advice with 'Use minImportance=high to see only the market movers' and states defaults, making when-to-use clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds useful behavioral context by emphasizing the tool only covers a curated set (not all of FRED) and returns historical observations. 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 three sentences and front-loaded with the primary purpose. Each sentence adds essential information: what it does, examples, and scope limitation with a pointer to SearchEconomicIndicators. No filler or repetition.

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

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

Given the tool has 4 parameters, no output schema, and annotations, the description provides key context: historical observations, a curated series set, and where to search for more. However, it does not describe the return format or observation frequency, which would be helpful since there is no output schema.

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

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

The input schema already documents all parameters with 100% coverage, so baseline is 3. The description adds value by listing concrete example series IDs (FEDFUNDS, CPIAUCSL, UNRATE, etc.) and noting that seriesId accepts standard indicator names in addition to FRED IDs, enriching the schema's description.

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

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

Description uses a specific verb ('Get time series data') and identifies the unique resource (FRED economic indicators). It clearly distinguishes itself from siblings by noting this covers only a curated ~40-series set, not the full FRED catalog.

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 context on when to use this tool: for historical time series of specific FRED indicators. It explicitly names SearchEconomicIndicators as the alternative to discover available series, and clarifies the curated scope, helping the agent 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 already declare readOnlyHint and destructiveHint, but the description adds valuable behavioral details: the data source is the latest NPORT-P, results are sorted largest-first, and coverage is conditional ('full, tracked U.S. equities only, or unknown') depending on availability of the authoritative reported count. This goes beyond 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?

Three tightly written sentences, with the core purpose and data source in the first sentence. Every sentence carries useful information and there is no filler 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?

For a read-only listing tool with fully documented parameters and safety annotations, the description is complete. It explains the source, sorting, coverage behavior, and pagination approach, so an agent has enough context to call 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 parameters are already fully documented. The description adds a small behavioral note about offset for broad portfolios and ordering context, but does not substantially expand parameter semantics beyond the schema.

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

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

The description states a specific verb ('Get'), a resource ('an ETF's stored portfolio holdings'), a source ('latest SEC Form NPORT-P report'), and the ordering ('largest position first'). This clearly distinguishes it from sibling tools like GetFundsHoldingStock or GetTopHolders.

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 covers ETF portfolio holdings from the latest NPORT-P, with coverage caveats, and explicitly tells the user to use 'offset' for broad portfolios. It does not explicitly name alternative tools or exclusion cases, but the use case is clear enough for agent 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=true annotation, the description discloses meaningful behavioral traits: data is 'settled' (not live/intraday), SEC assets come from filings, dividend history is 'currently primary-listing-only,' and issuer-trained short-interest forecasts/squeeze scores are excluded from ETF analytics. These caveats tell the agent what the tool will and will not return, all consistent with the readOnly and closed-world 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 core function is front-loaded in a concise first sentence, followed by logically ordered sections: same-ticker routing, holdings differentiation, filing caveat, data limitations. However, the routing catalog is long and reads like a data directory, and the final clause about 'issuer-trained short-interest forecasts and squeeze scores' is cryptic — informative but not zero-waste.

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

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

For a one-parameter read-only tool with no output schema, the description covers what is returned (settled performance, SEC assets, allocation, top holdings), what alternative tools handle other data categories, and known limitations. Minor gaps remain: no return format or units for SEC assets/allocation, and no indication of performance time periods.

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 schema already documents the single parameter well: 'Exact exchange-traded ticker (for example SPY, VOO, or IVV).' The description only reinforces exact ticker matching ('For this same exact ETF ticker') without adding new parameter semantics, so the baseline 3 applies.

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

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

The opening sentence names a specific verb ('Get'), a specific resource ('ETF profile'), and the exact deliverables: 'settled performance, SEC assets, allocation and top holdings.' It immediately differentiates from the most confusable sibling, GetEtfHoldings ('instead returns investments inside the ETF'), so an agent can distinguish them without opening schemas.

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

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

The description goes beyond vague context by enumerating explicit routing rules: prices → GetStockPrices/GetLatestClosingPrices, intraday quotes → GetLiveQuote, options → GetOptionExpirations/GetOptionChain/GetOptionContract, short interest → GetShortInterest, and so on. It also states when-not-to-use: ListFilings/SearchDocuments 'may include sibling funds, not just this ETF series,' which is exactly the guidance an agent needs to avoid scope errors.

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 establish read-only and non-destructive behavior; the description goes beyond them by disclosing extraction from narrative text, verification before publication, reverse-chronological ordering, and the back-filling coverage caveat with explicit empty-result semantics. This adds real behavioral context without contradicting the annotations.

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

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

Every sentence earns its place: scope, source, return fields, ordering, extraction/verification behavior, and the coverage/empty-result caveat. The most important scoping information is front-loaded before the detailed behaviors.

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 properly enumerates the returned fields: person name, raw and normalized role, action, effective date, verbatim disclosure, and filing source. Combined with full parameter documentation and safety annotations, nothing needed to invoke the tool correctly is missing.

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

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

All six parameters are fully documented in the input schema, so the description does not need to add parameter-level meaning. The prose adds useful output and coverage context but does not materially extend the semantics of ticker, date filters, action, offset, or maxResults.

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

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

States a precise verb and resource: getting a company's executive and director changes from 8-K Item 5.02 filings. The event types are enumerated, and the source filing basis distinguishes it clearly from siblings such as GetExecutiveCompensation.

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 use case clear: an agent needing executive/board appointment, resignation, termination, or retirement events from a company's 8-K filings. It does not explicitly name alternative tools or exclusion conditions, but the source-specific scope gives clear selection 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 read-only/destructive annotations, the description adds substantial transparency about data integrity: figures are exactly as disclosed, Total is the filer's own figure (never recomputed), and the tool states the newest proxy on file to surface stale coverage. This goes well beyond the annotations.

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

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

The description is concise but information-dense, with three well-structured sentences. Each sentence adds value: output specification, data integrity caveat, and coverage limitations. 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 fully explains the return content (salary, bonus, awards, etc., per executive per fiscal year, newest first). It also covers coverage limitations and data quality indicators, making it complete for a data retrieval tool.

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

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

Schema coverage is 100% (ticker and maxYears are both documented). The description adds some context about year ordering and the 'newest year first' behavior, which aligns with maxYears, but it does not significantly enhance the parameter meaning beyond the schema.

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

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

The description clearly states the tool retrieves named-executive compensation from DEF 14A proxy statements' Summary Compensation Table, listing components and per-executive/per-year granularity. It distinguishes itself from siblings like GetExecutiveChanges, which deals with changes rather than compensation.

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 important usage context by specifying coverage is limited to US DEF 14A filers and noting the data is back-filling, which guides when to use it. It also implies the tool is for compensation data, not other executive-related data, though it does not explicitly name alternative tools.

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

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

The annotations already mark this as read-only and non-destructive, and the description adds substantial non-obvious behavior: Quantity is an outstanding balance rather than new fails and must not be summed, Price follows the SEC prior-day close convention, coverage windows explain missing dates, and publication lag means newest rows trail today. This goes well beyond annotation signals.

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 first sentence front-loads the core purpose, and every subsequent sentence adds a distinct, necessary caveat or definition. Though lengthy, it is dense with useful information and contains 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 compensates by explaining Quantity, Price, Value, date coverage, missing-date semantics, and data lag. It provides enough interpretive context for an agent to call the tool and correctly understand 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 has 100% description coverage for all four parameters, so the description does not need to restate them. It adds no new input-parameter meaning beyond the schema, and the baseline of 3 applies because the schema handles the 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 states a specific verb and resource: retrieving fails-to-deliver data for an exact listed stock or ETF from the SEC's twice-monthly FTD files. It is clearly distinguishable from related short-selling tools like GetShortInterest or GetShortVolume because it anchors the data source and metric.

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 intended use clear: analyzing SEC-reported FTD balances for a single ticker, with coverage and lag caveats. It does not explicitly name alternatives or say when not to use this tool, but the FTD-specific framing leaves little ambiguity about its niche.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns links to FDA meeting pages, defaults to a 90-day window, and has limited historical coverage starting late 2025. This exceeds the annotation information 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 (three sentences) and front-loaded: the first sentence states the core function, the second clarifies defaults, and the third clarifies limitations and scope. No filler or redundant information.

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

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

For a simple read-only calendar tool with no output schema, the description covers the essentials: what is returned, the source, defaults, coverage limitations, and what it is not. It does not detail the exact output fields, but that is not critical given the simplicity and the provided link. It is complete enough for an agent to decide when and how to call it.

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

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

The schema already fully describes all three parameters with defaults and formats (100% coverage). The description's mention of 'next 90 days' and 'date range' echoes the schema without adding new meaning. Thus the description adds no significant value for parameter understanding, though it is consistent with 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: retrieving scheduled FDA advisory-committee meetings from the FDA.gov calendar, each with a link to its meeting page. It also specifies the scope (forward-looking, not historical) and the coverage start date, which distinguishes it from other calendar tools in the sibling list like GetEconomicCalendar or GetMarketHolidayCalendar.

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 context: it is for forward-looking FDA advisory-committee meetings, not a historical archive, and coverage starts in late 2025. It also notes entries are not linked to stock tickers, indicating it is not for market-impact analysis. While it does not name specific sibling tools, it clearly frames when this tool is appropriate and when it is not.

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 read-only and non-destructive. The description adds valuable behavioral context: returns a time series with latest restated values unless asOriginallyReported is set, each row includes actual period start/end, fiscal periods follow the company's own calendar, and a warning is raised when the selected alias ends materially before other facts (indicating a possible XBRL tag change). 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 dense paragraph that efficiently conveys purpose, usage, and behavioral details. It front-loads the core action and then adds specifics. While it could be slightly more structured (e.g., bullet points for the warning or parameter clarifications), it is not overly long and every sentence adds value.

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

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

Given the tool has 8 parameters, no output schema, and moderate complexity, the description is highly complete. It explains the return type (time series, one row per fiscal period with period start/end), the default data treatment (latest restated), the warning mechanism, and scope exclusions. No output schema is needed because the description sufficiently describes the output structure.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema: it explains the default behavior of asOriginallyReported, mentions that calling concept with an unknown value lists supported aliases, and clarifies the fiscalPeriod note about discrete Q4 rows. This pushes the score above baseline.

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 a single financial concept over time for a company from SEC XBRL data, naming example concepts. It explicitly distinguishes from sibling tools (GetFinancialStatement for full statements, CompareFinancialFact for peer comparison) and mentions that dimensioned disclosures are out of scope.

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

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

The description provides explicit guidance on when to use this tool versus alternatives: 'For a full statement use GetFinancialStatement; to compare peers use CompareFinancialFact.' It also notes that dimensioned disclosures (e.g., customer concentration) are outside this tool, and instructs calling with an unknown concept to list supported aliases.

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

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

The annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavioral detail beyond that: it returns latest-restated values, targets one exact period end, derives discrete quarterly flow rows from cumulative YTD values when necessary, and marks those rows as Derived. This gives the agent a clear picture of what the tool actually does at runtime.

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 average but every sentence earns its place: scope, output behavior, derived-quarter caveat, and sibling routing are all covered without redundancy. It is front-loaded with the core purpose and then layers in necessary constraint details.

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

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

With no output schema, the description carries the responsibility for explaining return semantics, and it does so: standard line items, latest-restated value, one exact period end, discrete quarterly rows, and the Derived flag are all disclosed. It also covers source provenance, exclusions, and alternatives, making it complete for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so the description is not burdened with compensating for undocumented parameters. It restates the statement types and period concept already covered by the schema, and the Q4 caveat is already present in the period parameter description. It adds little parameter-level meaning beyond the structured 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 names a specific action and resource: get a company's income statement, balance sheet, or cash-flow statement for a fiscal year and period. It also differentiates itself from siblings by explicitly excluding dimensional facts and naming GetRevenueBreakdown, GetFinancialFact, and CompareFinancialFact as the alternatives for those 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?

The description gives explicit when-to-use guidance, including the note that most filers do not report discrete Q4 income/cash-flow facts and that 'FY' should be used for annual figures. It also tells the agent exactly when to prefer sibling tools such as GetRevenueBreakdown and GetFinancialFact.

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 only declare the tool read-only and non-destructive. The description adds valuable behavioral context: results are sorted with the most recent notices first, a note flags when more results exist than returned, heavy 10b5-1 filers can flood the recency window, and a Form 144 proposal may never execute. These details go well beyond the structured annotations.

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

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

The description is dense but not padded; every sentence contributes value: purpose, returned fields, sort order, overflow behavior, date-scoping rationale, and legal caveats. It is front-loaded with the core capability and then fills in the nuances an agent would need to interpret results correctly.

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 compensates well by enumerating the key returned fields: seller, relationship, shares, aggregate market value, percent of shares outstanding, approximate sale date, broker, and remarks/10b5-1 plans. It also covers ordering, overflow, date filtering, and the caveat that proposals may never execute. Nothing essential for correct invocation or interpretation is missing.

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

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

The input schema documents all 5 parameters with descriptions, so the baseline is 3. The description adds extra meaning by explaining why fromDate/toDate matter — heavy 10b5-1 filers can flood the recency window — and noting that an overflow flag appears when more results exist than were returned. This goes slightly beyond the schema's basic 'filter' language.

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 recent proposed insider sales for a stock from SEC Form 144 notices,' a specific verb and resource. It makes clear these are declarations of intent, not completed trades, which distinguishes it from actual insider transaction tools like GetInsiderTransactions. The subsequent Form 4/5 note further reinforces the precise 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 concrete guidance to use fromDate/toDate to scope the period because heavy 10b5-1 filers can flood the recency window with small notices. It also warns that a proposal may never execute and that completed sales may only show up on Form 4 or 5 when reportable, which helps agents know when not to over-interpret results. However, it does not explicitly name a sibling tool as the alternative for executed sales, 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?

The description discloses a critical non-obvious behavior: D/A amendments restate the same offering, and warns the agent to group by first-sale date and offering amount and use only the latest notice to avoid double-counting. This goes well beyond the readOnlyHint/destructiveHint annotations and provides essential operational guidance.

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

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

The description is front-loaded with the core purpose, then provides a useful field enumeration, then ends with a vital deduplication warning. Each sentence contributes meaning; the second sentence is slightly dense but earned because there is no output schema to document the fields.

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 lookup tool with no output schema, the description is complete: it explains what the data represents, lists the important data points, and warns about the duplicate-amendment trap. The schema covers parameter constraints, and annotations cover safety, so nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema fully documents ticker, offset, fromDate, toDate, and maxResults. The description does not add parameter-level detail 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 first sentence names a specific verb ('Get'), a specific resource (SEC Form D notices), and a specific subject (exempt securities offerings / private placements for a company). This clearly distinguishes it from sibling tools like GetForm144ProposedSales and ListFilings, and the final sentence reinforces its intended tracking use case.

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 an explicit use case: 'Use this to track how a company is raising private capital alongside its public filings.' It does not explicitly list alternative tools or exclusion conditions, but the context is clear enough for an agent to select this tool among the many finance-focused siblings.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: N-CEN is filed at registrant level, ingestion happens through tracked issuer feeds, and a series in an untracked multi-series trust may have no record. It also clarifies the 'operating companies return no data' boundary. No contradiction with annotations, and it enriches beyond the structured hints.

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. It leads with the purpose, then details accepted inputs, the data returned, and important caveats about data availability and filing scope. Every sentence adds value without redundancy. It is appropriately sized 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?

For a read-only tool with two parameters and no output schema, the description covers the essential usage context: accepted identifiers, report contents, data availability limitations, and filing eligibility. It does not explicitly describe the return format (e.g., list vs. single record) or pagination behavior for maxResults, but maxResults is self-explanatory and the listed fields imply a structured response. Minor gaps exist but are not critical.

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 covers 100% of parameters with descriptions and examples. The description adds meaning by specifying that identifiers come from SearchFunds and detailing the accepted identifier types (profile id, SEC series id, stored series ticker, verified share-class alias). This goes slightly beyond the schema's generic 'Fund or ETF ticker' and clarifies the data source relationship.

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 operational data for a registered investment company from its SEC Form N-CEN annual reports.' It clearly distinguishes from sibling tools like GetFundProfile by focusing on N-CEN filings, and it enumerates the data fields returned. No ambiguity or tautology.

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 accepts tickers or identifiers from SearchFunds, and notes that only registered funds file N-CEN, with operating companies returning no data. It implies when to use this tool, but does not explicitly name alternative tools or state when not to use it. The guidance is solid but not exhaustive.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral nuance: it notes that multi-series trusts may store only tracked-stock positions but that reported counts and asset totals still reflect the full filing. This explains potential data quirks without contradicting annotations, adding value beyond the structured fields.

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

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

The description is compact and front-loaded: it states the core purpose first, then details return values, then notes a data quirk, and finally points to the alternative. Every sentence serves a purpose, with 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 read-only fund profile tool with three parameters and no output schema, the description provides a complete picture: what it returns (registrant, series, assets, holding counts, largest positions), the acceptable input formats, the underlying SEC form, and a relevant data caveat. Given the annotations and schema, nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, with each parameter (fund, offset, maxResults) already documented in detail, including examples for the fund identifier. The description adds no meaning beyond the schema; it only repeats the accepted identifier types and mentions pagination control indirectly. Baseline of 3 is appropriate because the schema carries the full semantic load.

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 a registered fund's profile and largest stored holdings from its latest SEC Form NPORT-P report.' It clearly distinguishes from siblings by naming the inverse tool, GetFundsHoldingStock, and specifying the input types accepted. The purpose is unambiguous and distinct.

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 GetFundsHoldingStock for the inverse lookup,' providing a direct when-not condition and naming the alternative. It also implies when to use this tool by describing the return values and the source data, making the decision between this and related fund tools 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 mark this as read-only and non-destructive, and the description adds substantial behavioral detail: exact CUSIP matching, exclusion of funds that stopped filing more than 18 months ago, the guarantee that exited positions never show as current, and the caveat that report dates differ and cross-row totals mix as-of dates. This goes well beyond the annotations.

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

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

The description is dense but not bloated; each sentence carries distinct information: purpose/source, matching logic and exclusions, returned fields and ordering, and the date-mixing caveat. It is front-loaded with the primary use case 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?

With no output schema, the description compensates by enumerating what is returned: registrant, series, reporting period, position size, dollar value, share of net assets, and payoff profile. It also covers edge behavior around report dates and stale filings, making the tool's behavior predictable enough for an agent to invoke and interpret correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value by explaining how 'ticker' works via authoritative CUSIP matching, that results are ordered 'largest positions first' (relevant to maxResults), and that 'registrantOrSeries' lets you reach positions beyond the largest 500. This enriches the parameters without duplicating the schema.

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

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

The description opens with a precise verb and resource: 'Get the registered investment companies (mutual funds and ETFs) holding an exact stock or ETF listing, from SEC Form NPORT-P portfolio reports.' It clearly distinguishes this from sibling tools like GetInstitutionPortfolio by specifying the data source and entity type. The exactness of security matching is also stated, leaving no ambiguity about scope.

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

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

The description gives clear context about when this tool applies: when you need mutual fund or ETF holdings from NPORT-P filings, with recent-report and 18-month staleness constraints. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5 but provides strong situational 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?

The description enriches the annotations substantially by disclosing the extraction methodology (from newest 10-K/10-Q narrative, verified before publication), the semantic of 'no doubt' when language is absent, and the coverage boundary. This goes well beyond the readOnlyHint and destructiveHint 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 packed into two dense sentences, front-loaded with the main purpose. The first sentence is long but every clause adds value—scope, output, and history. The second sentence clarifies coverage limitations. No wasted words, though slightly complex sentence structure prevents a perfect 5.

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 explains what the agent will receive: verbatim disclosure, filing identifier, and history of doubt episodes. It also explains methodology and coverage limits, making it complete for a one-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?

The input schema covers ticker with a clear description (e.g., AAPL, MSFT), and schema coverage is 100%. The description does not add any parameter-specific semantics beyond the tool's overall purpose, 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 exactly what the tool does with a specific verb and resource: it retrieves a company's going-concern doubt status from its latest examined SEC filing, including verbatim disclosure, filing source, and history of doubt episodes. This clearly distinguishes it from sibling tools like GetFdaCatalysts or 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?

While no alternative tools are explicitly named, the narrow purpose makes the intended use obvious. The description adds important context about coverage limitations (examined filings only, with no analysis of earlier periods), which helps an agent know when the data may be incomplete.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context beyond that: data source (USAspending.gov), coverage limitations (only prime awards of $1M+ resolving to a listed company), and the key caveat that reported total value is 'not revenue received.' It also notes that sums understate total federal revenue, which helps agents interpret results correctly. No contradiction with annotations is present.

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

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

The description is appropriately sized for a tool with 7 parameters, packing source, scope, field semantics, coverage caveats, and an alternative into a compact paragraph. The main action is front-loaded in the first sentence, and later clauses are information-dense rather than padded. A slightly tighter organization could help, but it is not bloated.

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

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

Given the moderate complexity, 7 parameters, and no output schema, the description covers everything an agent needs: what data is returned, source, coverage/exclusions, definition of key values, defaults context, and when to use a sibling tool. Pagination and date defaults are already in the schema, so the description complements rather than duplicates structured info. This is effectively complete for correct invocation and result interpretation.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds additional meaning by clarifying that total value is 'obligated dollars plus unexercised ceiling — not revenue received,' which informs how sortBy='amount' and maxResults should be interpreted. It also expands on the meaning of output fields such as outlays and period-of-performance end date, enriching parameter context. The description does not repeat parameter names or formats, keeping value-add high.

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 federal government contract awards ... won by a specific public company.' It clearly differentiates from the sibling GetTopGovernmentContractors by noting the per-company scope versus market-wide ranking. The title and annotation reinforce the same purpose, and no ambiguity remains about what the 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?

The description states the tool is 'useful for gauging a company's reliance on federal spending' and explicitly directs agents to 'use GetTopGovernmentContractors to rank companies market-wide.' This provides clear when-to-use guidance and names the alternative, so an agent can select between the two without opening schemas.

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, openWorldHint, and destructiveHint, but the description adds rich behavioral detail: how closed periods are marked, how revenue/EPS guidance includes actuals once comparable XBRL facts exist, the non-GAAP comparison rule, and coverage notes distinguishing unprocessed documents. This transparency goes well beyond the structured annotations.

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

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

The description is compact yet information-dense, front-loading the primary purpose and then efficiently covering ordering, period marking, comparison rules, and coverage notes. No redundant sentences; each 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?

Given the single parameter, no output schema, and read-only annotations, the description provides a thorough explanation of the returned content: source types, ordering, period status, comparison behavior, and coverage classification. This suffices 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?

The schema fully describes the only parameter 'ticker' with an example and type, achieving 100% schema description coverage. The description does not add extra parameter-level detail, which is unnecessary given the baseline of 3 for high coverage.

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

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

The description clearly states the tool retrieves company guidance from Item 2.02 earnings releases and transcripts, newest first, with specific attributes like range, unit, GAAP basis, fiscal period, and provenance. This specific verb+resource combination distinguishes it from siblings such as GetEarningsBrief or GetFinancialFact.

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

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

The description implies the tool is for guidance data from written earnings releases and call transcripts, and notes nuances like non-GAAP never being compared to GAAP actuals. However, it does not explicitly name alternative tools or conditions for when not to use it, relying on the detailed purpose to guide 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?

Annotations already mark the operation as read-only and non-destructive, and the description adds substantial behavioral transparency beyond that: it explains window-based dating, collapse of duplicate records across funds, and the reporting lag. These are exactly the non-obvious traits an agent needs to interpret results correctly.

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 first sentence is a clear front-loaded purpose statement, and every subsequent sentence adds necessary nuance about derivation, timing, deduplication, and reporting behavior. It is longer than the minimal case, but the complexity of the tool justifies each sentence with 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?

For a two-parameter read-only list tool with no nested objects and no output schema, the description is unusually complete. It covers what the tool returns conceptually, the meaning of the returned events, the data source derivation, and key caveats such as window granularity and deduplication.

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 both "index" and "maxResults" are already documented with examples and defaults. The description adds context about index change events but does not need to repeat parameter mechanics; the baseline of 3 is appropriate because the schema carries the parameter 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 opens with a specific verb and resource: "Get the companies that have joined or left a major US stock index, newest first." It clearly identifies this as a change-history tool for index constituents and distinguishes it from related index tools by emphasizing observed membership rather than an announcement feed.

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 for when the data is available: changes appear only after a tracking fund has reported them, and overlapping fund reports are collapsed. It also explicitly frames the tool as "observed membership, not an announcement feed," which is a useful exclusion, though it does not name alternative tools such as GetIndexComposition or GetIndexForecast.

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 read-only and non-destructive, but the description goes far beyond that: it reveals the data provenance (SEC Form N-PORT or daily holdings file), the fact that the fund name and date are returned, that partial filings are never served, and that unmatched rows are preserved under their reported names rather than dropped. These are significant behavioral traits that an agent needs to know and are not present in the annotations.

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

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

The description is long but every clause earns its place: it states the purpose, lists supported indices, explains data source, notes handling of partial filings and unmatched rows, and gives explicit alternatives—all in a logical flow. It is front-loaded with the key action and scope, and there is no redundant or filler 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?

The tool has only three parameters, no output schema, and no nested objects, yet the description provides a thorough account of the response structure (rank, ticker, share), data provenance, and edge-case behavior (unmatched rows, partial filings). It even covers what the tool does not do via pointers to sibling tools. For a simple read-only list tool, this is complete and exceeds what is needed.

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 all three parameters (index, offset, maxResults), and the schema already includes defaults and explanations such as 'heaviest first' for maxResults. The description does not add any new information about the parameters themselves; it only describes output structure and behavior, which is not the focus of this dimension. Thus, a baseline score of 3 is appropriate because the schema handles parameter semantics well.

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

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

The description opens with a specific verb and resource: 'Get the current constituent list of a major US stock index' and enumerates seven concrete indices, immediately making the tool's scope clear. It also distinguishes itself from siblings by referencing GetIndexChanges and GetIndexForecast as alternatives for different queries, which prevents confusion.

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 usage guidance is provided: 'Use GetIndexChanges for what has joined or left, and GetIndexForecast for who the published rules point to next.' This tells the agent when not to use this tool and names the alternatives. The description also explains the data source (fund filings) and the guarantee about complete listings, offering clear context for when to rely on 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 only establish read-only and non-destructive behavior. The description adds essential behavioral detail: estimates are not guarantees, missing figures produce no entry verdict, unmeasured members are handled differently across indices, and model revisions are immutable with a highest-revision rule. This materially changes how an agent should interpret results.

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 operation and then organized by index family, edge cases, and revision semantics. Although dense, every sentence contributes a distinct and material constraint; there is no redundant filler.

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

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

This is a complex endpoint with no output schema, yet the description covers the output form (candidates with evidence, probabilities, departure buckets), index-specific forecast certainty, edge-case behavior, and versioning. That is sufficient for an agent to invoke and interpret 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 documents both parameters with 100% coverage, including accepted index forms, the Dow limitation, and maxResults bounds. The description reinforces index-level semantics but does not add new parameter syntax or formatting details, 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 first sentence states a specific verb ('Apply'), a resource ('an index's published entry rules'), and a concrete deliverable ('return candidates with rule-by-rule evidence'). It also distinguishes this from sibling tools by framing it clearly as a forecast rather than a historical change 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 explicit guidance on when results are SCREENS vs PROJECTIONS and states that the Dow has no forecast, so an agent knows where the tool applies and where it does not. It does not explicitly name alternative sibling tools for actual index changes, which keeps it from a 5.

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

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

The description adds substantial behavioral detail beyond the annotations: shares come only from the most recent Form 3/4/5 filing, options and derivatives are excluded, figures are restated onto today's split basis, Indirect can understate because only the last vehicle balance is kept, and former insiders may show stale dates or zero shares. These nuances materially affect how an agent interprets results.

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 efficient: it front-loads the core purpose, then packs several important caveats into compact sentences, ending with clear usage guidance. Every sentence contributes meaningful information about behavior or usage, with no filler or tautology.

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 responsibility of explaining what the result contains, and it does so thoroughly: source filings, ownership buckets, split adjustment, exclusions, indirect holding limitations, max results, and ranking order. An agent has enough context to call the tool and correctly interpret the response.

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 documents all three parameters. The description adds useful contextual semantics like the maxResults default and implicit ranking by total shares, but it does not significantly extend the meaning of individual parameters beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states the exact verb and resource ('Get a summary of insider ownership for a stock'), specifies the ranking basis ('ranked by total shares held'), and clearly differentiates itself from sibling tools like GetInsiderTransactions and GetInsiderSentimentScores. It is unambiguous about what the tool returns.

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 ('Use this to understand the insider ownership structure of a company') and names the alternative for the underlying trades ('use GetInsiderTransactions'). This gives an agent clear routing guidance without needing to infer usage from the schema.

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 read-only/destructive annotations, the description discloses substantive behavior: data source (qualifying open-market Forms 4/5), treatment of Form 3, exclusion of Rule 10b5-1 trades, and the non-obvious invariant that filters never renumber the universe rank. These are exactly the behavioral traits an agent needs to interpret results correctly.

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 dense sentences front-load the core purpose and then add methodology, exclusions, modes, and an alternative tool without redundancy. Every clause adds information, and no space is wasted restating the title or annotation fields.

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 no output schema and no required parameters, the description is suitably complete: it defines the score, source data, exclusions, filter behavior, rank invariant, ticker mode, and alternative for raw filings. An agent can select and invoke it correctly without needing additional context.

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

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

The schema already documents all eight parameters completely, so the baseline is 3. The description adds value by explaining non-obvious parameter interactions—ticker mode returns factors and rank, bottom ranking is for distribution, and filters do not renumber the universe rank—which go beyond the individual property 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 opens with a specific action and object: 'Rank stocks by a peer-relative 0-100 insider-accumulation score over 90 days' and lists the inputs to the score (net buyers, net shares bought %, net buy value). This clearly distinguishes it from the many insider-related siblings, and the closing pointer to GetInsiderTransactions reinforces what this tool is not.

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 identifies concrete usage modes: default leaderboard, bottom ranking, ticker lookup, and filtering by cluster buys or liquidity. It also names the explicit alternative for raw filings ('Use GetInsiderTransactions for the filings'). However, it does not discuss when to prefer GetInsiderOwnership or other insider siblings, so the guidance is clear but not fully exclusive.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's value lies in interpretation, and it delivers: it explains that Buy/Sell are open-market only while other types are compensation/derivative mechanics, decodes the 10b5-1 column, and clarifies that Owned After is split-restated. This prevents common misreadings of the data.

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

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

The description is long but information-dense, with the core action front-loaded in the first sentence. Every sentence earns its place by adding scope, column semantics, or a caveat; minor formatting improvements could make it punchier, but there is 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?

With no output schema, the description carries the burden of explaining return semantics, and it covers ordering, form source, column meanings, split adjustment, and filter reach. Combined with fully documented schema parameters, an agent has enough to invoke the tool correctly and interpret the 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%, so baseline is 3. The description adds practical meaning by explaining what transactionType values represent ('Buy'/'Sell' are open-market only; others are mechanics) and why date-range, transaction-type, and insider-name filters exist, going beyond bare schema format 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?

States a specific verb and resource — 'Get recent insider trading transactions for a stock from SEC Forms 4 and 5, newest first' — and distinguishes Form 3 as initial ownership rather than a transaction. This makes the tool's scope immediately recognizable and separable from sibling tools like GetInsiderOwnership and GetInsiderSentimentScores.

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

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

Gives clear context: the tool is for understanding insider buying/selling activity and can reach history beyond newest rows via filters. It also clarifies what Form 3 is not, but it does not explicitly name sibling alternatives or state when to prefer GetInsiderOwnership versus 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?

Goes well beyond the readOnlyHint annotation by explaining that the legacy Total Shares field sums mixed row types and is not a pure share-ownership measure, plus fallback pricing, possible zeros, and provisional combined-view behavior during the filing window. These caveats materially affect how an agent should interpret returned values.

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, all dense with necessary caveats. The main purpose is front-loaded, and each subsequent sentence adds interpretive value without 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?

Even without an output schema, the description names the key change dimensions: total reported quantity, published position value, and filer count. It also covers valuation behavior, fallback conditions, zero values, and filing-window nuances, making the tool safely usable by 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 provides 100% parameter coverage for ticker and maxPeriods, including defaults and clamping. The description reinforces the multi-quarter theme but does not add significant new parameter-level meaning beyond the schema.

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

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

States a specific verb and resource: retrieving the historical trend of aggregate reported 13F exposure for an exact stock or ETF across multiple quarters. The qualifiers 'aggregate' and 'exact stock or ETF listing' distinguish it from institution-portfolio or market-wide 13F sibling tools.

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

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

Clear context is provided: use this when you need aggregate 13F history for one listed ticker across multiple quarters. It does not explicitly name alternatives or exclusions, but the scope wording is precise enough to guide selection among similar 13F-related tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral details beyond these: dividends are excluded from returns, split ratios are handled with a fallback to exclude earlier closes when unusable, and the valuation uses raw closing prices. These are non-obvious behaviors that materially affect results and are not inferable from the schema or 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 verbose paragraph, but every sentence earns its place—purpose, mode selection, reconstruction/rebalancing details, return metrics, and split handling are all packed in. It is front-loaded with the core purpose. While it could be broken into bullet points for readability, it is not bloated and remains efficient for its 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 tool's complexity (backtest logic, snapshot reconstruction, split handling) and the absence of an output schema, the description does a thorough job. It specifies the exact return metrics (price return, CAGR, max drawdown, alpha), explains the date range logic, institution resolution, and benchmark default. An agent has enough information to invoke the tool correctly without ambiguity about inputs or expected outputs.

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 every parameter has a description. The tool description adds value by clarifying interactions: fromDate overrides windowYears, windowYears is clamped to 1-20, and institution accepts names/CIKs with resolution behavior (unique partials, aliases, ambiguous partials return candidates). This enriches the schema descriptions without being redundant.

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 the specific verb 'Backtest' and a precise object: how cloning an institutional filer's reported 13F portfolio would perform against a market benchmark. It clearly distinguishes this from the many other institution-related tools (e.g., GetInstitutionPortfolio, GetInstitutionQuarterlyActivity) by focusing on backtest performance, not holdings or activity. The first sentence alone fully defines the tool's 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 explains the two modes of operation (trailing window via windowYears, or explicit fromDate/toDate range) and notes that fromDate overrides windowYears when both are supplied. It also mentions the rebalancing on the SEC filing lag, giving context for how results are produced. However, it does not explicitly contrast with alternative tools (e.g., 'use this instead of X when...'), though given the unique purpose, this is a minor omission.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral detail: values 'normally use report-date closing prices, may fall back to filer values, and can be zero when unavailable.' This goes beyond the annotations by explaining data quirks the agent needs to anticipate.

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 with no redundancy. The main function is front-loaded, followed by ranking behavior, value caveats, and a usage tip. Every sentence earns its place.

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

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

The description covers input constraints, ranking logic, value fallback behavior, and the shared-position threshold. Since there is no output schema, it would be helpful to state the exact returned fields explicitly, but the description gives enough shape (stocks ranked by holder count and combined value) for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the minInstitutions behavior and institution count range, but adds little beyond what the schema already states for each parameter. No significant new parameter-level meaning is introduced.

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 ('Combine'), a clear resource ('2-25 institutions' 13F portfolios'), and the output behavior ('Ranks stocks by holder count, then combined value'). This distinguishes it from related siblings like GetInstitutionPortfolio (single institution) and CompareInstitutionPortfolios (comparison rather than consensus aggregation).

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 clearly indicates the use case: aggregating 2-25 institutions' holdings and finding shared positions via minInstitutions. It does not explicitly name alternatives or state when not to use the tool, but the focus on consensus across multiple filers provides clear context for selection among sibling tools.

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

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

Even with readOnlyHint=true, the description adds valuable behavioral disclosures: values may fall back to filer values, can be zero when unavailable, coverage is limited to tracked U.S.-listed common stocks and put/call positions, and position type must be inspected before treating options as ownership. These details materially inform correct interpretation of results.

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 earns its place: core purpose, output contents, value caveat, coverage limitation, and disambiguation guidance. It is dense but not bloated, and the key scoping information appears 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?

For a read-only lookup tool with no output schema, the description covers what is returned, how values behave, coverage restrictions, and prerequisite disambiguation. Combined with fully documented parameters, nothing essential is missing for an agent to call this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces maxResults defaults and mentions pagination indirectly via 'largest positions', but adds no new detail beyond what the schema already documents for offset, maxResults, reportDate, or institutionName.

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 verb ('View'), resource ('tracked stock positions of a specific institutional investor from an SEC 13F-HR filing'), and output contents. It distinguishes itself from siblings like GetInstitutionSummary, GetInstitutionConsensusHoldings, and GetInstitutionQuarterlyActivity by focusing specifically on portfolio positions from a 13F filing.

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 is for viewing 13F holdings, with an explicit prerequisite to use SearchInstitutions first when the name is ambiguous. It does not explicitly enumerate exclusions versus siblings, but the purpose is specific enough that an agent can determine when it applies.

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: it returns one markdown section per bucket, sorts by absolute Δ market-value descending, and clarifies that Δ Value includes price movement, not just trading. It also explains the diffing logic against the prior quarter, giving the agent a clear picture of the output and 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 two sentences, front-loaded with the verb and resource, and every clause contributes value. It efficiently conveys the core functionality, return format, sorting, and a usage example with no wasted words.

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

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

Given the tool's moderate complexity, the 100% schema coverage, and the read-only annotations, the description is fully complete. It explains the return format (markdown sections), sorting rationale, the meaning of Δ Value, and the applicable question it answers. No output schema exists, but the description sufficiently covers expected 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 four parameters with detailed descriptions (bucket values, default maxResults, date snapping, and institution name resolution). The description does not add new parameter-level semantics beyond what is already present in the schema, 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 specifies the verb ('Get') and resource ('institution's quarterly position-change activity'), and enumerates the exact buckets (Initiated / Increased / Reduced / Exited) and the temporal comparison (vs. immediately prior quarter). This distinctly separates it from sibling tools like GetInstitutionPortfolio and GetFundHoldings, which focus on current holdings rather than changes.

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 "what did this fund do this quarter?"' and explains how to filter with the `bucket` parameter. However, it does not explicitly name alternatives or state when NOT to use this tool, such as when a user needs a current holdings snapshot rather than change activity.

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

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

Annotations already declare readOnlyHint and non-destructive behavior, and the description adds substantial behavioral context: outputs a markdown table, sorts by portfolio percentage, collapses unclassified stocks, falls back from report-date prices to filer values, and may return zeros. 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 information-dense sentences, each earning its place. The core purpose is front-loaded, followed by output format, price-source caveats, and name-resolution guidance, with no filler or repetition.

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

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

With no output schema, the description fully covers return format, ordering, unclassified rows, and data caveats. It also covers defaults, grouping, date snapping, and name resolution, giving an agent everything needed 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 coverage is 100%, but the description adds valuable meaning beyond the schema: groupBy semantics, reportDate defaulting and off-quarter snapping, and how institutionName resolution handles unique vs ambiguous partials. This gives an agent operational guidance the schema alone does not 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?

States a specific verb and resource: 'Get an institution's 13F portfolio allocation' for a report quarter, with explicit grouping by industry or sector. It also distinguishes itself by describing the sorted markdown table output and unclassified-row behavior, which separates it from similar portfolio-related 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?

Provides clear context: defaults to latest report, supports fine-grained industry or sector rollup, and returns candidates for ambiguous partial names. It explicitly directs users to SearchInstitutions for exact CIK matching, but it does not contrast itself with closely related tools like GetInstitutionPortfolio or GetInstitutionConsensusHoldings.

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

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

The description adds meaningful behavior beyond the readOnly/destructive annotations: it clarifies the metric is not total firm AUM, states possible fallback to filer values, notes zero can represent unavailable valuations, and explains the ambiguous-name behavior. This gives agents important expectations about output values and name resolution.

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 efficient, front-loading the core purpose and output fields, then adding valuation caveats and name-resolution guidance. Every sentence contributes useful information, though the long first sentence is somewhat heavy for a quick scan.

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

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

Without an output schema, the description compensates by enumerating the specific returned metrics and caveats about price sources and zero values. It also covers the key caller concern of name ambiguity. Minor gaps such as error behavior or pagination are not critical for a summary-header 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 the parameters are already fully documented. The description adds some context around name matching ('ambiguous partials return candidates') and implies the output uses report-date prices, but it does not materially extend the schema's parameter documentation.

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

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

The description names a specific verb ('Get') and resource ('portfolio summary header for an institutional 13F filer'), then enumerates the exact contents: tracked 13F value, position count, concentration, turnover, and report dates. This clearly distinguishes it from sibling tools like GetInstitutionPortfolio or GetInstitutionQuarterlyActivity.

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 a concrete usage directive: resolve exact CIKs with SearchInstitutions, and warns that ambiguous partial names return candidates rather than auto-selecting. It does not explicitly contrast with sibling tools or state when not to use it, but the focused resource definition makes the intended use clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds behavioral context by enumerating the specific data fields returned (legal/business names, SEC file number, etc.), which gives the agent a better sense of what the response contains. It does not discuss error handling or rate limits, but this is a simple read operation.

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

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

Two sentences: the first packs the scope and all key fields in a list, the second gives a pointer to the search tool. No redundant words, no repetition of schema content, and the most important detail (Form ADV profile by CRD number) 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?

For a single-parameter read-only tool with no output schema, the description is highly complete. It specifies the input (CRD number), the exact domain (Form ADV), the list of fields returned, and how to obtain the necessary input via SearchInvestmentAdvisers. The only minor omission is error handling, but this is not essential for a simple getter and the annotations cover safety concerns.

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 parameter with type and description (100% coverage), but the tool description adds semantic detail by specifying it is for 'SEC-registered' advisers and that it is the 'Organization' CRD number, distinguishing from other possible identifiers. It also explains how to find the CRD value via the sibling tool, enriching the parameter meaning.

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 precise resource, 'full Form ADV profile', and identifiers it by 'Organization CRD number'. It clearly distinguishes from the sibling SearchInvestmentAdvisers by explicitly noting that CRD numbers can be found with 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 gives explicit guidance on when to use this versus the alternative: 'Find CRD numbers with SearchInvestmentAdvisers' implies you need a CRD number to use this tool and should use the search tool if you lack one. No exclusions are stated, but the prerequisite and an alternative are clearly named.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is given. The description adds valuable behavioral detail: it returns metadata and access paths, not the binary contents, and explicitly lists the response fields including the distinction between PDF and image-slideshow paths. This goes beyond annotations by explaining what the response contains and what it does not.

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

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

The description is a single, well-structured paragraph that front-loads the purpose and then details the return fields. It avoids redundancy and each clause adds information, but it is slightly longer than necessary and uses a semicolon-heavy structure. Still, it is efficient and easy to parse.

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

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

Given there is no output schema, the description compensates by listing all returned metadata fields and the two possible path types. It also clarifies that binary content is not embedded, which prevents an agent from expecting it. The prerequisite for the id is explicitly stated. This is complete for an agent to call 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 single parameter eventId is fully described in the schema with the same source guidance ('from ListInvestorEvents or GetEarningsCallEvent'). Since schema description coverage is 100%, the baseline is 3; the description does not add additional semantic meaning beyond what the schema already provides.

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

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

The description clearly states it 'Get[s] metadata and access links for a captured investor-event slide deck by event id,' specifying the resource and action. It distinguishes itself from sibling tools like GetInvestorEventTranscript by detailing the exact fields returned (deck metadata, PDF vs. image-slideshow kind, page count, etc.) and by noting that binary content is not embedded, making its purpose unambiguous.

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

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

The description provides clear context on how to obtain the required event id ('Get the event id from ListInvestorEvents or GetEarningsCallEvent'), which serves as a prerequisite. It implies this tool is the one for slide-deck metadata, distinct from transcript tools, though it does not explicitly list alternatives or exclusions. This is clear contextual guidance without explicit 'when not to use' phrasing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context about speaker resolution: 'every speaker turn in order, attributed to the real person... when the resolution is trusted; unverified voices show as a role label... or a neutral speaker number.' This explains the output's trustworthiness and fallback behavior, which is beyond the annotation. A 4 is appropriate because it enriches understanding without redundancy.

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

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

The description is compact and front-loaded: it starts with the core function, then details output attributes, then gives usage context. Each clause carries useful information—no filler. It is slightly dense due to the speaker-resolution details, but that is directly relevant to the tool's purpose. Overall, it is well-structured for its length.

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

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

For a read-only tool with one required parameter and well-documented schema, the description covers the output format (speaker turns, attribution), the source of the id, and the scope (non-earnings events). It does not discuss error cases or edge behavior, but those are not critical given the read-only nature and existing pagination notes in the schema. The tool is sufficiently contextualized among its siblings.

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%: each parameter (eventId, limit, offset) has a description, including the clamping range for limit and paging purpose for offset. The description only adds a sourcing hint for eventId ('Get the event id from ListInvestorEvents'), which already appears in the schema's eventId description. Since the schema does the heavy lifting, the description adds little extra meaning, so baseline 3 is correct.

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'), a clear resource ('speaker-labelled transcript of a specific investor event'), and the means of identification ('by its event id'). It explicitly contrasts with earnings calls, distinguishing it from the sibling GetEarningsCallTranscript, so an agent can immediately tell them apart without reading schemas.

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

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

The description gives explicit guidance: 'Use this for conferences and other non-earnings events, which have no fiscal quarter to key on,' which tells when to use this tool and implies when not to (earnings calls). It also directs the agent to obtain the event id from ListInvestorEvents, providing a clear prerequisite. This is nearly complete usage guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely valuable behavioral context beyond annotations: the partial-coverage caveat — 'an empty answer may be a coverage gap rather than corporate silence; the response says which case applies' — plus 'scraped from the company's IR website' hinting at an external dependency. This materially improves agent interpretation of empty results.

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 and scope, then return format, then usage context, then the coverage caveat. Every sentence earns its place, though it is slightly verbose — the coverage disclosure could be tightened. Overall efficient and well-ordered.

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 fills the gap by specifying returned fields (headline, publish date, summary, link) and ordering (reverse-chronological). It also covers the empty-answer ambiguity. For a 4-parameter read tool with one required param, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so all four parameters (ticker, since, offset, maxResults) are already documented in the schema, which sets the baseline at 3. The description focuses on return format rather than parameter syntax and does not add meaning beyond the schema, which is acceptable given full 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 states a specific verb ('Get'), resource ('investor-relations press releases for a stock, scraped from the company's IR website'), and explicitly differentiates from third-party news. This distinguishes it from siblings like GetEarningsBrief and GetEarningsCallTranscript by content type, so an agent can select it confidently without opening schemas.

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

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

'Use this to see a company's latest official announcements straight from its IR page, distinct from third-party news' gives clear context for when the tool is appropriate, distinguishing official IR releases from third-party coverage. It stops short of naming explicit sibling alternatives or stating when not to use it, but the intended 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable interpretive context: that missing underwriters/risk factors distinguish pending/rejected extractions, and that all data is 'verified against the filing text and never estimated.' This goes beyond the structured annotations without contradicting them.

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

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

The description is a single dense sentence with a long semicolon-separated list. It front-loads the main action but would benefit from bullet points or shorter sentences for readability. Every item is informative, but the structure is not optimized for quick comprehension.

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

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

There is no output schema, so the description correctly carries the burden of explaining return values. It inventories all major data groups (lifecycle, offering, prospectus, risk factors, financials, filing chain) and even clarifies interpretation of missing fields. The tool is simple (one input), so this seems sufficiently complete.

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