DEHY — SEC & Market Intelligence

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 mentions only that results are 'newest first', but does not disclose read-only nature, authentication requirements, rate limits, or error behavior. This is minimally informative.

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

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

Single sentence, no filler words, front-loaded with key purpose and ordering. 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?

The description hints at return fields (filer, subject company, ownership %) but lacks details about pagination, empty results, or any other context. For a simple list tool with no output schema, this is adequate but not thorough.

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

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

Schema description coverage is 100% (the only parameter 'limit' is fully described with min/max). The description adds 'Max rows (≤50)' which is largely redundant but provides a human-readable summary. No additional semantic value beyond the schema.

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

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

The description clearly states it retrieves recent Schedule 13D/13G activist stakes and specifies data fields (filer, subject company, ownership %). However, it lacks an explicit verb like 'list' or 'retrieve', and the title is null, which slightly reduces clarity.

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 no guidance on when to use this tool versus alternatives like 'recent_insider_filings'. It does not mention any prerequisites or exclusions.

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

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

With no annotations, the description fully bears the burden. It discloses that the math runs in a deterministic engine grounded in SEC-filed financials, builds the unlevered free cash flow bridge each year, computes terminal value two ways, and that every input is cited and not guessed. It also details return values including implied value per share, upside, assumptions with provenance, and a sensitivity range.

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 lengthy but well-structured: it starts with the main purpose, then methodology, return values, override parameters, and example phrases. Every sentence adds value; however, it could be slightly more concise. Still, it is clear and 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 the complexity of a DCF model and no output schema, the description thoroughly explains what the tool returns: implied value per share under both terminal methods, implied upside, enterprise/equity value, assumptions with provenance, and a WACC×growth sensitivity range. It covers all essential aspects for an agent to understand and use the tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value by explaining that defaults are derived from the company's own history (EBIT margin, tax rate, D&A%, capex%). It also groups overridable parameters and provides meaningful context beyond the schema's brief descriptions.

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

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

The description clearly states the tool builds a DCF valuation for one company by ticker, with specific verbs like 'build', 'runs', 'computes'. It details the methodology (unlevered free cash flow bridge, two terminal value methods) and distinguishes itself from siblings like comps_valuation or reverse_dcf by focusing on a full DCF model with cited inputs.

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 use cases: 'Use for "value X", "build a DCF for X", "what is X worth"' and cautions that it is a scenario under stated assumptions, not a price target. While it does not explicitly mention when not to use vs. siblings, the examples give clear 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?

Discloses that the hawkish/dovish label is a heuristic and not a forecast, which is a key behavioral trait. The description lists all returned fields (rate decision, policy rate, language lean, date). Without annotations, it carries full burden and does well, but could further clarify update frequency or data recency.

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

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

Single sentence with clear structure: lists output fields and usage context. No filler words; every word adds value.

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

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

Describes what the tool returns (rate decision, policy rate, language lean, date) and its scope (Fed, ECB, BoE). Minor ambiguity: whether it returns one central bank's statement or all three simultaneously is implied but not fully explicit. Without output schema, the description adequately covers the key 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?

No parameters exist, so schema coverage is 100%. The description does not need to add parameter meaning, and the baseline of 4 is appropriate for zero-parameter tools.

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 identifies the tool as providing the latest monetary-policy statement from specific central banks (Fed, ECB, BoE), including the rate decision, policy rate, language lean heuristic, and date. This verb-resource combination is distinct from all sibling tools which cover different financial data (e.g., activist_filings, cluster_buys).

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

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

Provides explicit use cases: 'what did the Fed/ECB just do' or 'did any central bank shift'. While it doesn't explicitly state when not to use, the context is clear and siblings offer unrelated functionality, so no ambiguity about alternatives.

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

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

With no annotations provided, the description carries the full burden. It discloses the core logic (2+ distinct insiders, open market, 21-day window, return fields). However, it does not specify whether the window is rolling or fixed, nor does it mention data freshness or limitations. This is adequate for a simple tool but leaves 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 extremely concise: two sentences, no fluff, key information front-loaded (purpose and condition). 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's simplicity (one optional parameter, no output schema), the description is mostly complete. It explains the signal logic and return fields. However, it could mention that results are from the last 21 days continuously, but this is a minor omission. No critical information 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 covers the single optional parameter 'limit' with description 'Max rows (≤50)'. The tool description repeats this fact but adds no additional meaning beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description specifies a concrete action: returning issuers where 2+ distinct insiders bought on the open market in the last 21 days. It clearly distinguishes this from sibling tools by defining the cluster-buying signal and listing return fields (ticker, number of buyers, total dollars).

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 implicitly communicates when to use this tool (when interested in multiple insider buying on a name), but it does not explicitly state when not to use it or suggest alternative tools like 'net_insider_flow' or 'recent_insider_filings'. The context is clear but lacks exclusionary 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, the description carries the burden. It describes the data returned (revenue, EPS, etc.) and implies read-only behavior. It does not discuss authorization or rate limits, but for a read tool, this is fairly transparent.

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

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

The description is a single, well-structured sentence that front-loads the key information. Every word is useful, and it is concise without being terse.

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, but the description lists the major metrics returned. For a fundamentals tool, this is reasonably complete, though the exact structure (e.g., tabular vs. JSON) is not specified.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by listing the metrics and mentioning 'multi-year,' which aligns with the years parameter, but it does not add significant detail beyond the schema.

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

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

The description clearly states it provides multi-year annual financial statements for one company by ticker, listing specific metrics (revenue, margins, etc.). This distinguishes it from siblings like company_snapshot which likely offers a summary rather than detailed statements.

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 for fundamentals questions,' providing clear context on when to use. It does not explicitly mention alternatives or when not to use, but the guidance is sufficient.

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

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

No annotations are provided, so the description must cover behavioral traits. It implies a read operation but does not explicitly state that the tool is non-destructive or read-only. It also lacks information on authentication requirements, rate limits, or any side effects. The description focuses only on the output data, not on behavior.

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

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

The description is a single sentence that is concise, front-loaded with the core purpose ('Snapshot for one company by ticker'), and contains no redundant or unnecessary information. It efficiently communicates the tool's function and key outputs.

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 snapshot tool with one parameter and no output schema, the description is fairly complete. It lists the key data points returned, which provides sufficient context for an agent to understand the output. However, it could be slightly improved by mentioning the return format or the source of the data, but it is adequate given the simplicity.

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

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

The input schema has 100% description coverage for the single parameter 'ticker', which is well-documented in the schema ('Stock ticker, e.g. NVDA.'). The tool description adds context about the output but does not add additional meaning to the parameter beyond what the schema provides. 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 provides a snapshot for one company by ticker, listing specific data points (price, DEHY index, market cap, revenue, net margin). It uses a specific verb ('snapshot') and resource ('one company'), and the listed data points distinguish it from sibling tools like 'company_financials' or 'top_conviction_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 does not provide any guidance on when to use this tool versus its siblings. It only describes the output but gives no context on when to choose 'company_snapshot' over, for example, 'company_financials' or 'recent_insider_filings'. No exclusions or alternatives are mentioned.

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

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

With no annotations, the description takes full responsibility. It discloses key behaviors: uses SIC industry peers, computes EV/Sales and EV/EBITDA with conditions (EV/EBITDA only when peer median is in a 'sane band'), and that P/E is informational only. This provides good transparency, though it lacks details on data freshness or limitations.

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

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

The description is slightly long (4 sentences) but each sentence adds value: primary purpose, method, multiple selection criteria, and usage examples. It is front-loaded and information-dense, earning a high score for structure.

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

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

Given the tool's complexity (multi-step valuation) and lack of output schema, the description adequately explains inputs, process, and implied output (value-per-share range). It could be more explicit about output format, but overall it is complete enough for an agent to decide usage.

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

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

The single parameter 'ticker' is fully described in the schema (100% coverage). The description adds no additional parameter-level semantics beyond the schema's 'Stock ticker, e.g. NVDA.' 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 defines the tool as performing comps valuation for a single company by ticker, including specific verbs ('pulls', 'computes', 'applies') and resources ('largest same-industry peers', 'SEC filings + current price'). It distinguishes itself from siblings like build_dcf by focusing on relative valuation rather than DCF.

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 lists use cases ('comps for X', 'how does X trade vs peers', 'value X on multiples', 'relative valuation') and clarifies it's not a price target. However, it does not mention when not to use it or compare to sibling tools beyond implicit 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 provided, and description lacks behavioral details such as data freshness, update frequency, or limitations. 'Recent' is vague and insufficient.

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

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

Single sentence is concise and front-loaded with key information. No wasted words, though could be structured with bullet points for readability.

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?

Description partially explains return values but lacks details on ordering, date, transaction type specifics, or data source. Without output schema, more completeness would be beneficial.

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

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

The only parameter (limit) is well-documented in the schema with min, max, and description. The tool description does not add extra meaning for parameters but clarifies return fields (representative, ticker, buy/sell, amount range) which are not in input schema.

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

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

Description clearly states tool returns recent U.S. Congress member stock trades with specific fields (representative, ticker, buy/sell, amount range). It is distinct from sibling tools as none directly cover 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?

No guidance on when to use this tool versus alternatives. No explicit conditions or prerequisites for invocation.

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, so description carries full weight. Explains score is NOT a credit rating, anchored to rating-agency thresholds. Lists components including event flags. Could add data freshness, but overall transparent.

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

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

Single sentence packed with information; efficient but dense. Could be structured with bullet points, but 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?

Without output schema, description covers all key output components. Lacks details on data frequency or update timing, but sufficient for agent to understand tool's capabilities.

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?

Single parameter 'ticker' with schema covering 100%. Description doesn't add beyond schema (example given), but schema already clear. Baseline 3 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?

Description specifies exact output: DEHY Credit Health score, sub-scores, raw metrics, event flags, maturity wall, and recent debt issuance. Differentiates from siblings by focusing on credit profile, distinct from financials or regime 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?

Explicit use cases provided ('how healthy is X's credit', 'who has a refinancing cliff', 'has X issued debt recently'). Lacks when-not-to-use or alternatives among siblings, but guidance is clear.

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

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

No annotations provided, so description bears full burden. States it is a 'read' operation (non-destructive) and describes data types returned. However, does not disclose authentication needs, rate limits, or response format beyond listing components.

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

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

Single sentence with clear enumeration of data items and usage intents. No wasted words, front-loaded with purpose.

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

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

Given no parameters or output schema, description adequately covers what the tool returns and when to use it. Could mention update frequency but 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?

Input schema has zero parameters, so description adds no parameter info. Baseline for 0 params is 4, and no additional detail 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 specifies the tool retrieves credit-regime data including ICE BofA credit-spread OAS by rating, Treasury yield curve, and slope with inversion flag. It distinguishes itself from sibling tools which cover unrelated topics like activist filings or central bank stance.

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

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

Explicitly states use cases such as 'where are credit spreads / are they tight or wide' and 'is the curve inverted'. Clarifies it provides levels and ranges, not forecasts, implying it is not for predictive purposes. No explicit exclusions but context is clear.

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

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

With no annotations, the description thoroughly discloses the tool's behavior: it explains the COT Index scale (0-100 over 3-year window), thresholds for crowded positions, and includes commercial index, 4-week change, and divergence flag. There is no contradiction with annotations as none are provided.

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

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

The description is concise (4 sentences) and front-loaded with key metrics and purpose. Each sentence adds value: listing asset classes, explaining metrics with thresholds, stating usage intent, and noting the optional filter. No superfluous text.

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

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

The description covers the main return fields and their interpretation, making it complete for a snapshot tool. However, it does not mention data frequency, freshness, or whether the output is a single point or time series. Given the simplicity (one optional param, no output schema), these omissions are minor.

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 assetClass is fully described in the schema (enum with description). The description adds 'Optional asset-class filter' and hints at asset classes in the text, but does not provide additional semantic details beyond what the schema already offers. Given 100% schema coverage, baseline of 3 is appropriate.

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

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

The description clearly states the tool provides CFTC Commitments-of-Traders positioning data across FX, commodities, rates, and equities, listing specific metrics like COT Index and commercial COT Index. It distinguishes itself from sibling tools like positioning_brief by detailing the cross-asset scope and unique metrics.

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

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

The description explicitly states when to use the tool ('what positioning is stretched / crowded / diverging') and clarifies it is 'not a forecast.' However, it does not explicitly mention when not to use it or differentiate from the sibling tool positioning_brief, which may offer a similar function.

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 must fully disclose behavioral traits. It mentions the data source (8-K Item 5.02) but does not state that this is a read-only query, nor does it address potential quirks like empty results, pagination, or rate limits. The behavior is only partially transparent.

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-constructed sentence that front-loads the core purpose. Every word adds value; 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?

Given the tool has one optional parameter and no output schema, the description is adequate but not complete. It explains the data content but omits default behavior, sorting, or date range. An agent would need to infer or test these aspects.

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 a single 'limit' parameter documented. The description does not add meaning beyond the schema; it lists the data fields but does not elaborate on how the parameter affects the results. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves recent C-suite changes from 8-K Item 5.02, specifying key fields (ticker, role, change type). This is a specific verb-resource-scope combination that clearly distinguishes it from sibling tools, none of which focus on executive 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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or situations where it would be inappropriate. Agents are left to infer usage from the purpose alone.

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 must fully disclose behavioral traits. It explains the data source (13F filings) and output fields, but fails to mention whether the operation is read-only, any authentication needs, rate limits, or data freshness. The lack of such details leaves the agent with incomplete behavioral expectations.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and key details (funds and output). Every word contributes value, with no redundancy or extraneous information.

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

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

Given the lack of an output schema, the description provides minimal context: it lists the output fields (firm, holding, value) but does not clarify whether the tool returns a single aggregated position or one per fund. The mention of 'Marquee hedge funds' single largest' is ambiguous. Additional details about output format or cardinality would improve completeness.

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

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

The tool has no parameters, so the schema coverage is 100% (empty). The description adds no parameter information, but none is needed. The baseline score for zero parameters is 4, and the description does not detract from this.

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 defines what the tool does: it returns the single largest disclosed U.S. equity position from specific marquee hedge funds (Berkshire, Pershing Square, etc.) based on their latest 13F filings. The verb 'returns' and explicit listing of funds and outputs (firm, holding, value) make the purpose highly specific and distinguishable from sibling tools like 'cluster_buys' or 'top_conviction_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 that the tool should be used when one wants the top position from these specific hedge funds, but it does not provide explicit guidance on when to use it versus alternatives. No exclusions, conditions, or when-not scenarios are mentioned, leaving the agent to infer usage context.

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

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

No annotations are provided, so the description carries full burden. It explains the mechanics (models offer, combines earnings, subtracts after-tax interest, reports EPS change) and labels it a 'base-case scenario, not advice'. However, it lacks details on assumptions (e.g., tax rate, debt cost) and data sources, 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 four sentences: first states purpose, second details mechanics, third gives use cases, fourth is a disclaimer. It is front-loaded, efficient, and contains no filler, earning 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?

No output schema exists, so the description should explain return values. It states 'reports whether the acquirer’s EPS goes UP or DOWN' but does not specify that numerical values or additional data (e.g., accretion/dilution %) are returned. With 5 parameters and moderate complexity, it is adequate 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?

Schema coverage is 100%, so baseline is 3. The description mentions 'premium, cash/stock mix' and synergies implicitly but does not add new meaning beyond the schema descriptions. It does not elaborate on parameter format or constraints, so no 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 states it models M&A accretion/dilution for a public acquirer buying a public target, specifying inputs (premium, cash/stock mix) and output (EPS up/down). It provides example use cases like 'model A buying B' and distinguishes from advice, making the purpose specific and actionable.

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 for ‘model A buying B’, ‘is X acquiring Y accretive’, ‘what if A acquires B’' and adds a disclaimer ('not advice'). While no alternatives or when-not-to-use are mentioned, the tool is unique among siblings, so the usage context is clear.

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

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

No annotations are provided, so the description carries full burden. It explains the calculation (open-market buys minus sells) but lacks details on edge cases (e.g., no trades in window), update frequency, or data source. Adequate but not comprehensive.

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 key information. No unnecessary words; every part is essential. Excellent conciseness for the 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?

The tool has one simple parameter and no output schema. The description covers purpose and usage well. However, missing details about output format or behavior when no trades occur. Slightly incomplete but adequate for simple use.

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

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

The single parameter 'days' is fully described in the input schema (lookback window 7–120). The description mentions 'over a window of days' but adds no new meaning beyond the schema. Schema coverage is 100%, so baseline of 3 is appropriate.

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

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

The description clearly states the tool computes 'daily net insider dollar flow' over a lookback window, and the purpose is understandable. However, it does not explicitly distinguish from sibling tools beyond the specific focus on net flow.

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 for 'are insiders net buying or selling lately'.' This directly tells when to use the tool. No exclusion or comparison with siblings is given, but the guidance is clear and actionable.

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

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

No annotations are provided, but the description adequately conveys behavioral traits: it is a read-only brief providing context without trade recommendations. The phrase 'never a buy/sell call' clearly indicates it does not generate trading 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 description is two sentences with no wasted words. It front-loads the core purpose and usage guidelines efficiently.

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

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

Given no parameters or output schema, the description covers the essential scope: what the brief contains (crowded, diverging, swings, policy) and its intended use. It could be considered complete for a simple informational 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 tool has zero parameters, so the input schema already covers everything. The description adds no additional parameter information, which is acceptable per the rubric (baseline 4 for zero params).

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

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

The description clearly states the tool provides a cross-asset Positioning & Policy desk brief covering positioning extremes, divergences, swings, and central-bank policy. It uses specific verbs like 'crowded' and 'diverging' and contrasts with sibling tools like 'cross_asset_positioning' by being a desk brief.

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 given: 'Use for give me the macro/positioning read or what should a currencies/commodities desk watch right now.' It also clarifies limitations: 'Crowding context, never a buy/sell call.' This tells the agent when and how to invoke the tool.

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

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

No annotations provided, so description carries full burden. It mentions ordering (newest first) and that it covers open-market trades across all issuers, but lacks details on data freshness, pagination, or rate limits. Adequate but not thorough.

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 short sentences, no redundant words. Key information is front-loaded: what the tool returns and when to use it. Highly efficient.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the return data fields and primary use case. It is complete enough for an agent to understand, though it could mention data lag or update frequency.

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 the limit parameter described in the schema. The description adds no additional meaning beyond the schema's 'Max rows (≤50)'. 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 description clearly states it returns the most recent open-market insider trades with specific fields (ticker, buy/sell, dollar value, role, conviction score). It distinguishes from sibling tools by focusing on 'recent' and 'open-market' across all issuers.

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 for what are insiders doing right now', providing clear use context. However, it does not mention when to avoid this tool or suggest alternatives among siblings like net_insider_flow or top_conviction_trades.

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 explains the conceptual behavior (reverse-engineers market expectations vs. company history) but lacks specifics on data sources, calculation details, or output structure. The 'not a price target' warning adds some transparency.

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

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

Three sentences, efficiently front-loaded with a clear action verb and concept. Uses bold and example queries to aid readability. Every sentence adds value, 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 the tool's complexity and lack of output schema, the description should explain what the output contains (e.g., implied growth rate, historical comparison). It mentions comparing implied figure to historical delivery but doesn't specify format or additional outputs. Annotations are missing, so completeness is only moderate.

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% (both parameters have descriptions). The description adds context that the default solve is for growth (mentioning 'growth (or FCF margin)') which aligns with the 'solveFor' enum default behavior, but doesn't provide additional semantics beyond what the schema already offers.

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: solving for the implied growth or FCF margin that the market prices in. It distinguishes itself from a standard DCF by focusing on what's already priced, not fair value. Example queries like 'what's priced into X' reinforce the purpose.

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

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

The description provides explicit use cases ('what's priced into X', 'what growth is the market assuming', 'is X's valuation realistic') and a clear when-not ('not a price target'). It implicitly distinguishes from sibling tool 'build_dcf' by contrasting forward vs. reverse approach, though it doesn't name alternatives directly.

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. The description discloses the key behavioral trait of ranking by conviction score rather than recency and mentions the DEHY scoring. However, it does not discuss data freshness, authorization needs, or whether it is read-only.

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

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

The description is two sentences long, front-loaded with the core purpose, followed by a usage suggestion. Every sentence adds value 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 simplicity (1 optional parameter, no output schema, no nested objects), the description covers the core purpose and sorting behavior. It could briefly explain DEHY or output format, but it is largely sufficient for an agent to decide when to use it.

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

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

The schema has 1 parameter (limit) with a description that covers its purpose. Schema description coverage is 100%, so baseline is 3. The tool description adds no additional 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 uses specific verb 'Highest DEHY-scored insider trades' and resource 'insider trades' with clear scope 'last 14 days (ranked by conviction score, not recency)'. It distinguishes from sibling tools like 'recent_insider_filings' by emphasizing ranking by conviction rather than recency.

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 use cases: 'Use for "best insider signals" or "highest-conviction buys".' However, it does not explicitly state when not to use this tool or mention alternatives like 'recent_insider_filings' for time-based queries.

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