ko-mcp-worker

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

No annotations are provided, and the description only mentions what trades are shown, not behavioral traits like pagination (via page/limit params), rate limits, or authorization needs. This is insufficient for a tool with no annotations.

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

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

Two sentences are highly efficient and front-loaded with the primary purpose. No unnecessary words.

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

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

No output schema is provided, so the description should fully explain return values. It mentions fields but lacks detail on structure, pagination, and error handling. Adequate but not comprehensive for a tool with moderate complexity.

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

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

Schema coverage is low (33%), with only member having a description. The description adds value by suggesting slug formats and referencing get_congress_trades for finding slugs, but does not document page and limit 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?

Description clearly states it gets trading history for a specific Congress member, with transaction details. However, it does not explicitly differentiate from sibling get_congress_trades, which might also return similar data for multiple members.

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

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

Usage is implied for getting individual member history, but no explicit guidance on when to use this vs alternatives like get_congress_trades or search. No exclusions or prerequisites 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 is the sole source of behavioral cues. It mentions that data comes from mandatory disclosures, implying reliability and public availability. However, it does not disclose whether the tool is read-only, pagination behavior, rate limits, or what actions (if any) are destructive. Basic transparency is achieved, but gaps remain.

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) and front-loads the main action. There is no redundant information. The structure is clear and efficient, though a third sentence explaining common filters could be added without harming conciseness.

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

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

Given the tool has 8 parameters and no output schema, the description is too minimal. It fails to cover all parameters (e.g., search, sort, pagination) and does not describe the return format (e.g., list of trades with fields). The missing date range parameter is a notable gap. More detail is needed for complete contextual understanding.

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 75% (parameters with descriptions), but the description adds meaning by stating that filtering is possible by chamber, party, state, date range, or ticker. However, the mention of 'date range' is misleading since no such parameter exists in the schema. This error reduces the value, and no additional detail is provided for other parameters like sort or pagination.

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 stock trades of Congress members. It specifies the source (mandatory financial disclosures) and mentions filtering by chamber, party, state, date range, or ticker. However, the claim of date range filtering is inaccurate as the input schema contains no date range parameter, slightly reducing 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 (e.g., get_insider_trades for corporate insiders). It does not state when not to use it or mention any prerequisites. This lack of context forces the AI to infer usage, which may lead to incorrect tool selection.

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

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

With no annotations provided, the description carries the full burden. It discloses the data source (SEC 13F filings, latest quarter) and return values (total USD, QoQ change, per-ETF breakdown), implying a read-only operation. No contradictions or hidden behaviors.

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

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

Two sentences with no extraneous words. The first sentence states the purpose and data source, the second lists return values. Every sentence earns its place.

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

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

Given no input parameters and no output schema, the description covers the essential aspects: what is retrieved, data source, and key outputs. It is complete enough for a summary tool, though the per-ETF breakdown structure could be slightly more explicit (e.g., format of holders, USD, QoQ).

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, and schema description coverage is 100% (by absence). The description adds meaning by detailing the return structure (total institutional USD, QoQ change, per-ETF breakdown), which is not in the empty schema. Baseline for 0 params is 4, and this is well-addressed.

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 the verb 'Get', the exact resource 'market-wide summary of institutional exposure to US spot crypto ETFs', and clearly distinguishes from sibling tools like 'get_crypto_holder' and 'get_crypto_holders' by emphasizing 'market-wide' and 'institutional exposure'.

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 obtaining institutional exposure data from SEC 13F filings, but does not explicitly state when to use this tool versus alternatives (e.g., 'get_crypto_holder' for individual holder details). No exclusions or prerequisites 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?

No annotations provided, so description carries full burden. It details return fields (shares, USD, QoQ change, action, rank) and source (latest filed quarter), making the tool's behavior quite transparent for a read operation.

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

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

Two concise sentences front-load the main purpose and output, with no redundant information. Every sentence earns its place.

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

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

For a simple retrieval tool with one parameter and no output schema, the description is complete: it covers purpose, input hint, output content, and prerequisite tool 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?

Schema has 100% coverage for the single parameter, describing it as CIK or name. Description adds value by explaining how to obtain the CIK, but doesn't significantly expand beyond schema's description.

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

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

The description clearly states it retrieves a single institution's crypto-ETF holdings per-ETF and rank, and distinguishes from sibling 'get_crypto_holders' which likely returns multiple institutions.

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

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

Explicitly mentions using a CIK number and how to find it via get_crypto_holders or search, providing clear context. Lacks explicit when-not-to-use compared to other siblings like get_crypto_exposure, but still helpful.

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 burden. It discloses the data source (13F filings), ranking criterion (total USD held), and optional filtering. However, it does not mention pagination behavior, rate limits, data freshness frequency, or whether results are read-only (inferred). Lacks some behavioral detail.

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, concise and front-loaded with the key action and scope. Every word earns its place, and there is no redundancy or unnecessary detail.

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

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

Given the tool's simplicity (list with optional filter, no output schema), the description is fairly complete. It specifies the data source, ranking, and optional filter. The only gap is the lack of mention of the output format or total result count, but for a list tool with pagination parameters, this is acceptable.

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 minimal value beyond schema: it provides an example for the 'product' parameter ('IBIT') but does not elaborate on 'page' or 'limit'. The parameter semantics are adequately covered by the schema.

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

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

The description clearly states the tool lists institutional investors holding US spot crypto ETFs, ranked by total USD held, from the latest quarter of SEC 13F filings. This specific verb+resource+scope distinguishes it from siblings like get_crypto_holder (singular) or get_institution_holdings (broader).

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 listing crypto ETF holders with optional filtering, but does not explicitly state when to use this tool versus alternatives like get_crypto_holder or get_institution_holdings. No exclusions or when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as rate limits, data freshness, update frequency, or any side effects. For a read-only data retrieval tool, this is a gap.

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, front-loaded sentence that lists key indicators and the filtering capability. No unnecessary words or repetition.

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

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

Given the low complexity (2 parameters, no output schema, no annotations), the description covers the tool's purpose and parameters adequately. However, it lacks detail on return values or limitations, which would be helpful without an output schema.

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

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

Schema coverage is 100% with detailed parameter descriptions. The description only adds 'Filter by category,' which is redundant with the schema. It does not provide additional meaning or usage context beyond the schema.

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

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

The description clearly states the tool gets U.S. economic indicators from BLS and lists specific indicators (CPI, PPI, Non-farm Payrolls, Unemployment Rate, JOLTS). The verb 'get' and resource 'U.S. economic indicators from BLS' are specific, distinguishing it from sibling tools like get_fed_rates.

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 explicitly state when to use this tool versus alternatives. While the listed indicators imply it's for BLS data, there is no guidance on exclusions or comparisons with siblings like get_fed_rates or get_financial_stress. The context is implicit but not fully 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?

No annotations are provided, so the description carries the full burden. It discloses the list of rates but omits behavioral traits such as authentication needs, rate limits, or the nature of data (e.g., real-time vs. historical). The existence of the 'days' parameter implies historical coverage, but this is not mentioned in the description. Minimal behavioral context is 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 extremely concise, consisting of two short sentences with no extraneous information. The key elements (tool action, outputs, and context) are front-loaded.

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

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

Given the simplicity of the tool (one optional parameter, no output schema), the description is partly adequate. However, it lacks information about the return format, whether the data is current or historical, and behavioral details. The description covers the basics but leaves gaps.

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

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

Schema description coverage is 100%, and the single parameter 'days' is well-documented in the schema. The tool description does not add additional meaning beyond the schema, so a 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 Federal Reserve interest rates and lists specific series (Fed Funds Rate, SOFR, Prime Rate, Discount Rate, Treasury yields). The purpose is clearly communicated, though there is potential overlap with the sibling tool 'get_treasury_yields', which slightly reduces distinctiveness.

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 mentions 'Key indicators for monetary policy', providing a usage context, but does not explicitly state when to use this tool versus alternatives like 'get_treasury_yields' or 'get_economic_indicators'. No when-not guidance is given.

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

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

No annotations are provided, so the description carries full burden. It adds context about the index being daily and the interpretation of values (above 0 = above-average stress). However, it does not disclose data freshness, rate limits, or whether the request is read-only. Basic transparency 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, no fluff. The verb and resource are front-loaded. 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?

Tool complexity is low (one parameter, no nested objects). The description explains the index's meaning but does not describe the return format or structure. Without an output schema, this is a gap.

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

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

Schema description coverage is 100% for the single parameter 'days'. The description adds no additional meaning beyond the schema's own description ('Number of days of history (default 365)'). Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Get' and the resource 'OFR Financial Stress Index', explaining it as a daily indicator of stress in global financial markets. This distinguishes it from sibling tools that cover stocks, crypto, treasury yields, etc.

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

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

No explicit guidance on when to use this tool versus alternatives. The name implies financial stress context, but there is no when-to-use or when-not-to-use information. Usage is implied but not clarified.

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 discloses that the tool retrieves pre-sale filings, signaling upcoming insider sales, and notes its complementarity to Form 4. It does not cover permissions, rate limits, or data freshness, but the core behavioral trait (read-only retrieval) is clear.

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 concisely state the purpose and context. There is no wasted text, and the key information is front-loaded.

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

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

The description provides enough context for an AI agent to understand what the tool returns (Form 144 filings) and how it fits into the ecosystem (complements Form 4). Without an output schema, it does not detail return structure, but the purpose is clear. Adequate for a straightforward retrieval tool.

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

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

Schema description coverage is 100% with clear descriptions for limit, ticker, and insider_cik. The tool description does not add additional semantics beyond the schema, so a 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?

Description clearly states the tool retrieves SEC Form 144 filings, specifies the resource (notices of proposed sale by insiders), and contrasts with Form 4, distinguishing it from siblings like get_insider_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 explains that Form 144 provides pre-trade intent, complementing post-trade Form 4, which guides when to use this tool. However, it does not explicitly list alternatives or when not to use it.

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

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

With no annotations provided, the description carries the full burden. It indicates a read operation ('Get'), which implies it is non-destructive, but it does not disclose any additional behavioral traits such as data freshness, rate limits, or authorization requirements. It provides minimal 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?

Two sentences with no wasted words. The first sentence states the action, and the second adds interpretative value. It is front-loaded and concise.

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

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

The description covers the purpose and interpretative context but lacks details about the output format or structure. Without an output schema, this omission is notable. For a simple tool with two parameters, it is mostly complete but could be improved by briefly describing the return data shape.

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

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

Both parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description adds no additional parameter-specific meaning beyond the schema, but the interpretive context (high FTD indicating naked short selling) provides overall value, though not directly for parameters.

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

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

The description clearly states it retrieves SEC FTD data for a stock, using a specific verb ('Get') and resource ('SEC Failures-to-Deliver data'). It distinguishes itself from sibling tools, which are about other financial data types, making its purpose unique and clear.

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

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

The description implies usage context by noting that high FTD quantities may indicate naked short selling or settlement issues, but it does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. Given no direct alternatives for FTD data, it is adequate but not 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?

No annotations are provided, so the description must cover behavioral traits. It indicates a read-only retrieval operation but does not disclose potential issues like invalid ticker handling, data freshness, rate limits, or side effects. The description is sufficient for basic safety but lacks depth.

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 (39 words), front-loaded with the action, and contains no unnecessary information. 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 no output schema, the description provides good context on the source and purpose of the data. It could mention the return format or pagination, but the tool is simple enough that the context is largely complete for an agent to understand usage.

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

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

The input schema has 100% parameter description coverage, with clear descriptions for ticker, limit, and executive_cik. The tool description adds minimal extra semantics beyond the SEC Form 4 context. Baseline of 3 is appropriate as the schema already handles parameter documentation.

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

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

The description clearly states the verb 'Get', the resource 'insider/executive stock trades (SEC Form 4)', and the action 'for a company'. It explains what types of insiders are included (CEO, CFO, directors) and the signal value. This distinguishes it from siblings like get_form144_notices and list_insider_traders.

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

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

The description implies use for insider trading signals but does not explicitly state when to use this tool versus alternatives. No 'when not to use' guidance or exclusion criteria are provided, leaving the agent to infer context from the sibling tool names.

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 mentions returning top positions with share counts, values, and QoQ changes, but lacks details on data freshness, permissions, rate limits, or whether multiple filings are possible. 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, no fluff, front-loaded with the main purpose. 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?

With 3 parameters and no output schema, the description explains the return content (top positions, share counts, values, QoQ changes) and the institution resolution. It is fairly complete for a query tool of moderate 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%, but the description adds value by explaining that the 'institution' parameter accepts CIK, slug, or name and resolves automatically. This goes beyond the schema's minimal description.

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

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

The description clearly states the tool retrieves current stock holdings of an institutional investor from SEC 13F filings, listing top positions with share counts, values, and quarter-over-quarter changes. It uses specific verbs and resource, and distinguishes from siblings like 'get_stock_holders' and 'list_institutions'.

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

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

The description specifies the data source (latest SEC 13F filing) and the types of investors (hedge fund, mutual fund, pension fund). It does not explicitly exclude usage scenarios or mention alternatives, but the purpose is clear enough for appropriate selection.

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

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

No annotations are provided, so the description must convey all behavioral traits. It describes the output (buying vs selling counts, net changes, value flows) but lacks details on data freshness, rate limits, or any side effects. It is adequate but not exhaustive.

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 states the primary action and scope, the second elaborates on output and use case. Every sentence adds value with no fluff, making it highly concise and well-structured.

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

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

The description sufficiently explains the tool's purpose and output for its moderate complexity, given that parameters are well-documented in the schema. However, it does not specify the return format or whether results are aggregated, which could enhance 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 input schema has 100% coverage with descriptions for both parameters. The tool description adds no extra meaning beyond the schema, meeting the baseline for a well-documented 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 specifies a clear verb ('Get') and resource ('institutional buying/selling activity trend for a stock over multiple quarters'). It distinguishes from siblings like get_institution_holdings by focusing on activity trends rather than static holdings.

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

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

The description mentions usefulness for detecting accumulation or distribution patterns, providing context for when to use it. However, it does not explicitly state when not to use it or suggest alternatives among the many sibling tools.

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

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

No annotations are provided, so the description must fully convey behavior. It mentions the data source (SEC 10-K/10-Q) but lacks details on rate limits, data freshness, response format, or whether it is read-only. Listing example metrics helps, but the behavior is not fully 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, clear sentence that efficiently conveys the tool's purpose and key outputs. It is concise but could benefit from a bit more structure (e.g., listing parameters or use cases).

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 output schema, the description should more thoroughly explain return values. It mentions some metrics but does not specify data structure, units, or pagination. Adequate for a data retrieval tool but not 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% with descriptive names and descriptions. The description adds meaning by specifying the data source, listing example financial metrics, and implying period types beyond just the enum values.

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

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

The description clearly states the tool retrieves quarterly or annual financial statements, listing specific metrics (revenue, net income, EPS, etc.) from SEC filings, which distinguishes it from sibling tools focused on congress, crypto, or other financial data.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. While the sibling names suggest clear distinctions, no direct comparison or usage context is given.

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

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

No annotations provided, so description carries full burden. It mentions data source (SEC 13F) and outputs (QoQ changes) but does not disclose rate limits, pagination, or read-only nature. 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 concise sentences. First states main function, second adds valuable detail. No fluff, 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?

With no output schema and no annotations, description covers core purpose and data source but lacks details on return structure, pagination, or error handling. Adequate for a simple read tool.

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

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

Schema describes all 3 parameters fully. Description adds no additional parameter-level context beyond what schema provides, such as format or constraints.

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?

Clear verb 'get' and specific resource 'top institutional holders' from SEC 13F filings. Distinguishes from siblings by mentioning hedge funds, mutual funds, and quarter-over-quarter 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?

Implies use for querying stock institutional holders but lacks explicit guidance on when to use versus alternatives (e.g., get_institution_holdings) and does not state exclusions or prerequisites.

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

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

No annotations provided, so the description must carry the full burden. It mentions default behavior (summary) and the option for full series, but does not disclose error handling, rate limits, or data source. A score of 3 is appropriate for moderate transparency.

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

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

The description is extremely concise with two sentences. The first sentence states purpose, the second provides usage guidance. No unnecessary words.

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

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

Given no output schema, the description hints at return structure via 'OHLC' but does not detail the format. For a simple price retrieval tool, this is largely sufficient. The sibling tools list shows many related tools, so this description clearly sets it apart.

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

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

The schema already covers all 4 parameters with descriptions (100% coverage), so the description adds limited additional meaning. It contextualizes the 'series' parameter for backtesting/charting, but overall does not significantly enhance understanding beyond the schema. Baseline is 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 'Get historical daily stock prices (OHLC)', which is a specific verb-resource pair. It distinguishes itself from sibling tools like get_stock_activity and get_stock_financials by focusing on price data.

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

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

The description explains when to use the summary vs. full series ('Returns a summary by default; set series=true to get the full daily price series for backtesting / charting'). It does not explicitly mention when not to use it or compare to alternatives, but the context implies this tool is for price history.

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 describes what data is returned but does not disclose behavioral traits such as data freshness, rate limits, or any side effects. The description is straightforward but minimal for a 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 a single sentence that front-loads the purpose and lists example data points. Every word adds value, with no fluff or repetition.

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

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

For a simple tool with one parameter, the description is fairly complete, listing the kinds of data returned. It could mention that no output schema is provided, but the examples compensate. The sibling tools are related but not competitors, so the description stands alone.

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' already has a clear description in the schema (100% coverage). The description adds example tickers, which is helpful but not necessary. Baseline 3 is appropriate as the schema does most of the work.

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 retrieves a company's profile and lists specific metrics (sector, market cap, P/E ratio, etc.). However, it does not differentiate from sibling tools like get_stock_financials or get_stock_price, which might have overlapping data.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for a broad overview, but it lacks context like 'Use this for a snapshot of key financials; for detailed financial statements, use get_stock_financials instead.'

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 for behavioral disclosure. It only states it returns 'daily yields' but does not mention data source, update frequency, API limits, or any side effects. For a data retrieval tool, this is insufficient beyond the bare purpose.

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

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

Two sentences with no redundant words. The purpose is stated upfront, followed by context. Ideal length for a simple tool.

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

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

The tool has one parameter, no output schema, and no annotations. The description covers the purpose and parameter sufficiently. However, it could mention the output format or typical use cases to be more complete. Overall, it is adequate for the tool's 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?

Schema description coverage is 100% (the 'days' parameter is well described). The description adds context about data content (maturities) but not about the parameter itself. Given high schema coverage, a 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 explicitly states 'Get U.S. Treasury yield curve data — daily yields for maturities from 1-month to 30-year.' It uses a specific verb and resource, and clearly distinguishes from sibling tools like get_fed_rates and get_economic_indicators.

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

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

The phrase 'Essential for understanding interest rate environment and yield curve shape' implies usage context, but there is no explicit guidance on when to use this tool versus alternatives or when not to use it. With many sibling tools, more explicit usage boundaries would be helpful.

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 must disclose behavior. It lacks details on pagination, data freshness, rate limits, or any side effects. Merely states it lists recent trades, insufficient for a read tool with pagination parameters.

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

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

Two efficient sentences, front-loaded with core purpose. No filler or redundancy.

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

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

Lacks explanation of return format, pagination defaults, or what 'recently' means. With 4 parameters and no output schema, more context is needed for a complete understanding.

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 50%; description adds value for 'role' parameter but does not explain 'page', 'limit', or 'search'. Partially compensates for low 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?

Clearly states action (list) and resource (executives/insiders who have recently traded). Distinguishes from siblings like get_insider_trades by focusing on listing traders rather than individual 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?

Provides explicit use case: 'useful for finding notable insider buying/selling activity'. However, does not specify when to avoid using the tool or mention alternative tools like get_insider_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 only mentions listing, search, and pagination, but lacks details on rate limits, authentication, data freshness, sorting of 'top', or response 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 sentences, front-loaded with key information, no 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?

Given the lack of annotations and output schema, the description is too brief. It omits behavioral details like what 'top' means, pagination behavior, and typical return structure, leaving gaps for the agent.

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

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

Schema coverage is 100%, and the description adds minimal value by restating that search is by name (already in schema). The description provides no additional constraints or format guidance beyond the schema.

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

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

The description clearly states the tool lists top institutional investors from the SEC 13F database, using the specific verb 'List' and identifying the resource and context. It implicitly distinguishes from sibling tools like get_institution_holdings and list_insider_traders.

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

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

Usage is implied by the description and sibling tool names, but there is no explicit guidance on when to use this tool versus alternatives like get_institution_holdings or search.

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 burden of disclosure. It effectively communicates that the tool searches across multiple categories and returns identifiers. While it does not explicitly state read-only nature or result format, the purpose is clear and sufficient for a search tool.

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

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

The description consists of two concise sentences with no wasted words. It is front-loaded with the core action and followed by usage context.

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

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

Given the tool's simplicity (2 parameters, no output schema, no nested objects) and the richness of the schema, the description is complete. It adequately explains what the tool does and when to use it.

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

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

The input schema has 100% coverage with descriptions for both parameters. The description adds context about the tool's purpose but does not supplement parameter semantics beyond what the schema already provides.

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

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

The description clearly identifies the tool as a search across institutions, stocks, and insider traders in the ko.io SEC database. It distinguishes itself from sibling tools by specifying that it is used to find CIK numbers, tickers, or slugs.

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

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

The description explicitly states when to use this tool ('Use this first when you have a name but need the CIK number, ticker, or slug'), providing clear guidance compared to sibling tools that require those identifiers.

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 discloses that it returns a link, not the file itself, and optionally an excerpt of ~6000 chars. It explicitly states 'Never returns the whole file', providing clear 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?

Two concise sentences: first states action and result, second clarifies limitation. 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?

No output schema, so description should explain return values. It does (link and optional excerpt). It doesn't mention error handling or link format, but is adequate for a simple tool with many siblings.

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

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

Schema coverage is 100%, so description doesn't need to add much. However, it adds value by explaining the link behavior and the excerpt option, enhancing understanding beyond the schema.

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

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

The description clearly states the tool gets a source document from an SEC filing, returns a link and optionally an excerpt, and distinguishes from siblings like sec_get_filing_index by specifying it retrieves a single document rather than listing.

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 when to use (to get a source document) and when not (for full content, open link or request section). It lacks explicit alternative tool names but is sufficient for 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?

With no annotations, the description carries full burden. It states the tool enumerates files, which is a read operation, but does not explicitly confirm read-only, mention prerequisites, or describe any side effects. Adequate for a simple list 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 exceptionally concise: one sentence for the core functionality and one sentence for usage guidance. Front-loaded with the key verb and resource, 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 simplicity of the tool (2 params, no output schema), the description is mostly complete. It tells what it returns (list of files) and directs to the next tool. Could optionally mention the output format or expected file names.

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

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

Schema covers both parameters with descriptions (CIK and accession_no). The description adds context about being for a single filing but does not add new semantic meaning beyond what the schema already provides. Baseline score of 3 applies.

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

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

The description clearly states the tool enumerates every file in a single SEC filing, listing file types like primary document, exhibits, images, XBRL, and the full .txt submission. It distinguishes itself by naming the sibling tool sec_get_filing_document for the next step.

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

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

The description explicitly says to pass a file name from here to sec_get_filing_document, providing clear sequential usage context. It implies when to use but does not explicitly state when not to use or mention alternatives.

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

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

No annotations provided, so description carries full burden. It discloses ordering (most recent first), output type (accession numbers), and data source (EDGAR). Missing details like rate limits or pagination behavior, but for a list 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?

Two focused sentences. The first conveys core functionality and ordering. The second provides actionable guidance on CIK and output usage. No waste, but the second sentence could be integrated.

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

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

With 5 schema-described parameters and no output schema, the description adequately explains what the tool returns (accession numbers) and how to use them with sibling tools. It also directs users to find CIK elsewhere. For a list tool, this is sufficiently complete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining the purpose of the output (accession numbers for other tools) and hints at CIK usage, but does not add significant new semantic meaning to individual parameters beyond the schema.

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

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

The description clearly states the tool lists SEC filings from EDGAR, ordered most recent first, and returns accession numbers. It distinguishes itself from sibling tools by mentioning that the returned accession numbers are for use with sec_get_filing_index and sec_get_filing_document.

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

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

Explicit guidance on providing the CIK and where to find it (use search or get_stock_profile). Implicitly indicates when to use this tool (to get a list of filings) versus siblings (to retrieve indexes/documents). No explicit when-not-to-use, but context is clear.

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