Compound Interesting — market intelligence

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

With no annotations, the description carries the burden and does well: it discloses the output contents (cross-signal consensus, dimensions with direction/provenance, risk flags) and notes it's a single record. It doesn't discuss error behavior or authentication, but for a simple get operation, this is adequate.

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

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

The description is two sentences, front-loaded with the core value proposition in the first sentence and usage guidance in the second. Every word earns its place; no redundancy or fluff.

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

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

Given a single parameter and no output schema, the description sufficiently covers the tool's behavior and returns. It explains the record's contents and provides usage context. No additional information seems necessary for effective use.

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

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

Schema coverage is 100% since the only parameter 'ticker' has a clear description with an example. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description clearly states what the tool does: returns a comprehensive record for a ticker, including consensus, contributing dimensions, and risk flags. It explicitly distinguishes itself from siblings by positioning as 'everything the platform knows' and 'Start here', making it the go-to tool for company-specific questions.

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 with 'Start here for any question about a specific company', indicating when to use this tool. However, it does not explicitly mention when not to use it or name alternatives, though the sibling list implies other more specialized tools exist.

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

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

With no annotations, the description carries full transparency burden. It discloses the tracked actors and the per-dimension breakdown, but does not explicitly mention read-only behavior, edge cases, or output format details. For a simple get tool, this is adequate but not rich.

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

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

The description is a single sentence that covers the core purpose without unnecessary detail. However, the structure with 'Whether...' is somewhat awkward and not perfectly front-loaded, though it remains concise and readable.

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

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

Given the absence of an output schema and annotations, the description should explain return values more concretely. It mentions a verdict and per-dimension breakdown but does not specify data types or the structure of the breakdown. For a one-parameter tool, this is functional but could be more complete.

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

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

The input schema fully documents the ticker parameter with a clear description, so the schema coverage is 100%. The tool description does not add any additional meaning beyond the schema, resulting in a baseline score of 3.

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

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

The description clearly states the tool provides a consensus verdict for one ticker, listing the actors involved (insiders, Congress, institutions, the model) and noting a per-dimension breakdown. It distinguishes from rank_consensus by focusing on 'one ticker', but lacks an explicit verb like 'returns' or 'gets', making the purpose slightly less direct.

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 single-ticker usage via 'one ticker' but does not explicitly state when to use this tool versus alternatives such as rank_consensus or get_composite. No exclusions or alternative tool mentions are provided, leaving usage guidance implicit.

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

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

With no annotations, the description discloses key behaviors: no API key required, returns only the demo ticker regardless of input. It adds useful auth context but doesn't mention rate limits or exact return format, which is acceptable for a demo tool.

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

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

Two concise sentences front-load the core value and point to the real tool. Every phrase earns its place with no redundancy.

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

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

For a zero-parameter demo tool with no output schema, the description is complete: it explains why to use it, what it returns, and how to get real data. It fully prepares an agent for invocation.

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

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

Zero parameters means baseline is 4. The phrase 'regardless of input' is slightly confusing given the empty schema, but overall it correctly conveys that no ticker selection is possible. No further parameter documentation 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 tool provides a single fixed demo ticker and explicitly differentiates it from the real get_composite tool. The purpose is unambiguous: inspect data shape without an API key.

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

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

It gives explicit when-to-use context (before signing up) and points to the alternative get_composite for real tickers. This fully answers the usage question.

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

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

With no annotations, the description carries the burden. It discloses a critical behavioral nuance: the tool only covers ~51 perps out of ~5,400 tickers, and negative coverage means absence, not a zero value. This is valuable beyond what the schema shows, though it omits other behaviors like data freshness or return format.

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 tightly written sentences deliver the core purpose and a crucial caveat. No filler words, no redundant information, and the most important caveat 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 low-complexity tool with one parameter and no output schema, the description adequately covers the essential behavior and the most critical edge case (coverage vs zero). It could be improved by describing the return shape, but the current content is likely sufficient for correct invocation.

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

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

Schema provides full coverage for the single 'ticker' parameter with a clear example. The description adds context that the ticker must be one of the ~51 perpetual names, but this is more about tool scope than parameter syntax, so it adds modest value above schema.

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

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

Clearly states it returns funding and open interest for a single name on the perpetual venue. The phrase 'single name' distinguishes it from sibling list_equity_perp, and the venue specification separates it from other get_* 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?

Provides important usage context: most tickers are not listed, and a 'not listed' response should be interpreted as no venue coverage rather than flat/zero positioning. This helps the agent decide when to use the tool and how to interpret results, though it doesn't 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?

With no annotations, the description carries full behavioral disclosure. It reveals that the tool requires paid keys, is slower because it is computed on demand, and returns primary documents with filing provenance. It does not detail exact response format or error handling, but for a simple read-style tool, this is adequate behavioral context.

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

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

The description is two sentences, front-loaded with the core purpose, then adding usage and constraints. Every sentence earns its place with no redundant or extraneous words.

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

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

For a tool with a single parameter, no output schema, and no annotations, the description is remarkably complete. It covers what the tool returns (evidence documents and their filing), why to use it (to cite claims), and key caveats (paid keys, slower). An agent can confidently decide when and how to invoke 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 input schema already fully documents the single ticker parameter (100% coverage). The description adds no additional parameter-specific semantics, only implying that the ticker is the input via 'a ticker's signals.' This meets the baseline for high schema coverage without adding extra value.

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

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

The description clearly identifies the tool's purpose: retrieving source documents behind a ticker's signals. It specifies the types of documents (insider Form 4s, Congressional disclosures, institutional holdings, macro series) and states that each item includes the filing it came from, distinguishing it from sibling tools that likely provide signals rather than evidence.

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 the tool: 'Use this to cite a claim rather than assert it.' It also provides constraints (paid keys only, slower, computed on demand). However, it does not name alternative sibling tools directly, so it stops short of fully explicit when-not-to-use guidance.

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

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

With no annotations provided, the description carries the burden of explaining behavior. It discloses the sample period (last 5 years), the outputs (mean, std, percentiles, histogram, drawdown dates), and the critical unit convention (fractions like 0.0821 = 8.21%). It doesn't mention edge cases, but the provided details are substantive.

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, each earning its place: the first lists content and timeframe, the second gives usage guidance, the third clarifies units. It is front-loaded with the most important information and contains no redundancy.

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

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

Since there is no output schema, the description must explain return values, and it does so comprehensively: mean, standard deviation, percentiles, histogram, and worst drawdowns with dates. For a single-parameter tool, this is complete enough 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?

The input schema already fully documents the only parameter (ticker with an example). The description reiterates that the analysis is per ticker ('FOR THIS NAME') but adds no new syntactic or semantic details beyond the schema. Baseline 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the tool's function: it provides the historical distribution of 5-day and 1-month returns for a ticker. It lists specific outputs (mean, standard deviation, percentiles, histogram, worst drawdowns) and emphasizes the per-name context, distinguishing it from general market 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 explicitly says to use it 'to say whether a move is unusual FOR THIS NAME rather than in the abstract,' providing clear guidance on when this tool is appropriate. This effectively contrasts with alternatives that might assess moves generically.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. It adds context that the rating is a judgement, not a recommendation, and mentions the reasoning output. However, it does not disclose details like read-only behavior, error handling, or data freshness, though the 'get' verb and simple input imply a safe 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?

The description is two sentences, front-loaded with the core purpose, and each sentence adds value. The first sentence explains what the tool returns, and the second clarifies an important caveat about the nature of the rating. 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 simple single-parameter get tool with no output schema, the description adequately explains the return content (rating and reasoning) and provides a conceptual caveat. It is complete enough for the tool's simplicity, though it lacks explicit alternative tool guidance.

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

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

The only parameter (ticker) is already fully described in the schema with an example, and schema description coverage is 100%. The description adds no additional parameter semantics beyond what the 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 clearly states the tool returns the platform's own buy/hold/sell rating for a ticker, along with reasoning. It uses a specific verb ('get') and resource ('house rating') and distinguishes from sibling tools (e.g., consensus, composite) by emphasizing 'platform's own'.

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 this tool is for the platform's proprietary rating, which helps differentiate from consensus or composite tools, but it does not explicitly state when to use it over alternatives or when not to use it. Usage context is only implicit.

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

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

With no annotations, the description carries the burden of disclosing behavior. It adds context by explaining that 'macro' is the market-regime read, 'energy' is the macro energy balance, and 'crypto' is crypto positioning and funding, which goes beyond the schema. However, it does not mention whether this is a read-only operation, return format, or any side effects, leaving some behavioral gaps.

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 every sentence earns its place: first establishes scope, second explains the parameter values, third gives usage context. It is front-loaded 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?

For a simple one-parameter tool with no output schema, the description is largely complete: it explains what the tool measures and when to use it. It could benefit from stating output format or typical values, but this is not critical for choosing and invoking 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 0% and the only parameter 'name' is an enum with no descriptions. The description fully defines each enum value in plain language ('macro' = market-regime read, 'energy' = macro energy balance, 'crypto' = crypto positioning and funding), providing essential semantics that the schema lacks.

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 this is a whole-market gauge rather than per-company, and enumerates the three specific signal types ('macro', 'energy', 'crypto') with their meanings. This distinguishes it from sibling tools like get_equity_perp or get_composite.

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 these for the backdrop a single name is trading against,' which provides clear when-to-use guidance. It also contrasts with per-company tools, though it does not name specific alternatives or state 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?

With no annotations, the description carries the behavioral disclosure burden. It adds a valuable interpretive guardrail: 'Committee overlap is reported as oversight, never as an accusation.' It also notes the disclosure links, providing context about the output. However, it does not cover pagination or rate limits, but these are less critical for a read-only list.

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 delivers the core function, the second adds an essential interpretive nuance. Every word earns its place without fluff or repetition.

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

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

For a list tool with four optional parameters and no output schema, the description covers the key aspects: data source, sort order, disclosure links, and a reporting caveat. It is comprehensive enough for an agent to understand the tool's purpose and output shape, though it doesn't elaborate on pagination mechanics.

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

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

Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds no additional parameter-level detail, meeting the baseline 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 identifies the resource ('Disclosed House and Senate trades'), the verb (list/disclose), the ordering ('newest first'), and a key feature ('each linked to its disclosure'). It distinguishes itself from siblings like list_insider_trades by specifying the congressional 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 implies usage for congressional trade data, but it does not explicitly state when to choose this tool over alternatives or mention any exclusions. Sibling list_insider_trades is not referenced, so the guidance is implicit rather than explicit.

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

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

With no annotations provided, the description carries full disclosure burden. It explains what data is included (funding rate, open interest, notional ranking), the behavioral implication of high positive funding ('crowded, squeeze-fragile'), and the important caveat that the mark price is a venue mark, NOT the stock price. This goes far beyond a basic list description.

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, each with a distinct purpose: what it is, when to use it, and how to interpret the data. It is front-loaded with the resource definition and contains 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?

Despite having no annotations and no output schema, the description fully equips an agent to select and invoke this tool: it names the data fields, the venue scope, the ranking, the market-hours context, and a critical data caveat. For a one-parameter list endpoint, this is complete.

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

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

Schema coverage is 100% for the only parameter (limit), with the schema description 'How many names to return' fully explaining it. The tool description adds no additional parameter-level detail, which meets the baseline of 3 but does not exceed it.

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

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

The description uses a specific verb ('list') and identifies the exact resource: funding rate and open interest for ~51 US single names on a 24/7 perpetual futures venue, ranked by notional. This clearly distinguishes it from the sibling tool get_equity_perp (which likely returns a single name) and other list 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?

It explicitly states 'This is the ONLY source here that moves outside US market hours, so it is what to check overnight and at weekends,' giving a clear when-to-use directive and distinguishing it from all sibling tools for that use case. The wording implies other tools are not suitable for overnight/weekend 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?

With no annotations, the description carries the transparency burden. It discloses that results are sorted newest-first and include a link to the filing, providing some behavioral detail. However, it omits any mention of pagination behavior, rate limits, or that this is a read-only operation, though 'list' implies reading.

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 concise single sentence that front-loads the tool's purpose and key attributes (source, ordering, filing linkage). It contains 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?

Given the simplicity of the tool and that all parameters are documented in the schema, the description provides enough context about what the tool returns and how it orders results. Since there is no output schema, it could have briefly described the record structure, but the core purpose is adequately covered. This is slightly above minimal viability.

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 fully describes all four parameters (limit, since, cursor, ticker) with clear descriptions, so the description does not need to add parameter semantics. The tool description itself does not mention parameters, but baseline 3 applies due to high schema coverage.

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

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

The description clearly states that the tool lists corporate insider trades sourced from SEC filings, with explicit ordering (newest first) and linkage to the originating filing. This distinguishes it from sibling tools like list_congress_trades, which target a different subject (congressional trades).

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

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

The description implies usage—when insider trading data is needed—but does not explicitly mention alternatives or when not to use this tool. It lacks guidance such as 'use this instead of list_congress_trades for corporate insiders'. Thus, usage is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a critical caveat: net figures reflect hedges and cannot be read as a directional view. This is valuable, but it does not cover pagination behavior, data scope, or other potential side effects.

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

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

The description is concise: two sentences. The first states the core purpose and ordering, the second adds an essential interpretative caveat. No redundant or unnecessary words are present.

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

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

There is no output schema and no annotations, so the description must supply context. It explains the meaning of net figures but lacks usage guidance and does not clarify what constitutes 'large holders' or the return structure. Adequate for a simple list tool, but gaps remain.

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

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

The schema provides descriptions for all four parameters (limit, since, cursor, ticker), covering 100% of the parameter meaning. The tool description does not add parameter-specific information, but the baseline of 3 is appropriate given full schema coverage.

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

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

The description clearly states the tool lists positioning of large holders, ordered newest first. It uses a specific verb phrase and resource, making the purpose clear. However, it does not explicitly differentiate from sibling list tools like list_insider_trades or list_congress_trades.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any contexts, exclusions, or alternative tool suggestions. It simply states what the tool does, leaving the agent to infer appropriate usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context about the output (ranked names) and intended use, but does not explicitly state whether this is a read-only operation or disclose any side effects or data sources. It provides some transparency but leaves gaps.

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

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

The description is two sentences, front-loaded with the primary purpose, and contains zero waste. Every sentence contributes either to purpose clarification or usage guidance.

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

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

The tool has four optional parameters and no output schema, but the description clearly states the output is a ranked list of names. Combined with the schema, this is sufficient for an agent to understand what the tool returns and when to use it, though a bit more detail on the meaning of 'consensus strength' would be helpful.

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

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

The input schema covers 100% of parameters with descriptions, so the schema already documents all four parameters. The description does not add parameter-specific details, but the baseline of 3 is appropriate since the schema provides sufficient semantic 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 clearly states that the tool ranks names by consensus strength, using a specific verb ('ranked') and resource ('tickers'). It distinguishes itself from siblings like get_consensus by indicating that it is for finding candidates rather than checking one you already have in mind.

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

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

The description provides explicit when-to-use guidance: 'Use this to find candidates rather than to check one you already have in mind.' This clearly indicates the intended use case and excludes the alternative use case, though it does not explicitly name an alternative 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?

With no annotations provided, the description carries the full burden. It implies a read-only operation by saying 'Filter... and return', but does not explicitly state safety, rate limits, or other behavioral constraints. It adds some context by framing the tool as a 'bulk discovery' tool, but lacks depth about output format or operational details beyond what the schema implies.

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 sentence states the core function and output; the second provides usage context and an explicit alternative. Every word earns its place, and it is front-loaded with the most important 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 9-parameter filter tool with no output schema, the description provides essential context: it is a bulk discovery tool for screening the whole universe, returns matching tickers with scores, and differentiates from rank_consensus. It does not explain return value structure in detail, but 'with their scores' gives a minimal sense. The schema handles parameters, so this is reasonably complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the baseline is 3 even without additional param info in the description. The description does not explain any parameters, but it doesn't need to given the schema covers them. It adds minimal semantic value by mentioning 'scores' and 'matching tickers', which loosely maps to the output but not to specific parameters.

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

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

The description opens with a specific verb and resource: 'Filter the whole equity universe and return matching tickers with their scores.' This clearly states the tool's function and distinguishes it from siblings like rank_consensus by positioning it as 'The bulk discovery tool' for questions like 'which companies have X'.

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

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

The description explicitly tells when to use this tool ('for questions of the form which companies have X') and contrasts it with an alternative ('To rank by cross-signal agreement instead, use rank_consensus'). This provides clear usage guidance and sibling differentiation.

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

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

No annotations are provided, so the description carries the full burden. It adds a useful qualifier that results are limited to 'tickers the platform covers,' which hints at coverage constraints. However, it does not disclose return format, failure behavior, or other behavioral nuances, leaving significant gaps for a no-annotation tool.

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

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

Two sentences, front-loaded with the primary action, and no extraneous information. Every word contributes to understanding the tool's purpose and usage.

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

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

Given the tool's simplicity (one param, no output schema), the description adequately explains what it does and when to use it. It states that it resolves to 'tickers the platform covers,' implying the output is a set of ticker symbols, which is sufficient for a search/ resolution tool. Minor gap is lack of detail on the exact output format or list behavior.

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

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

Schema coverage is 100% for the single parameter, with the schema already describing 'Company name or partial symbol.' The tool description essentially paraphrases this ('company name or partial symbol'), adding no new semantic detail, 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 uses a specific verb 'Resolve' with a clear resource: company name or partial symbol to tickers. It distinguishes itself from sibling tools, which are all getters and listers for specific data types; this is a lookup/resolution 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?

Provides explicit guidance: 'Use this first when the user names a company rather than a symbol.' This clearly indicates the primary use case but does not name specific alternative tools or explicit when-not-to-use conditions, though the conditional phrasing implies them.

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