Earnings Feed

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

Annotations indicate readOnlyHint=true, which the description doesn't contradict (it uses 'Get', implying a read operation). The description adds minimal behavioral context beyond annotations—it specifies the input types (ticker or CIK) but doesn't disclose other traits like rate limits, authentication needs, or what specific company information is returned. With annotations covering safety, a 3 is appropriate as the description adds some value but lacks rich behavioral details.

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

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

The description is a single, efficient sentence that front-loads the purpose ('Get company information') and specifies the input methods. There's no wasted verbiage, repetition, or unnecessary details, making it highly concise and well-structured for quick understanding.

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 low complexity (2 parameters, no output schema, simple annotations), the description is adequate but has gaps. It covers the basic purpose and inputs, but lacks details on output format, error handling, or how it fits with sibling tools. Without an output schema, the description doesn't explain return values, which could be improved for completeness. It's minimally viable but not fully comprehensive.

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 both parameters (cik as 'SEC CIK number' and ticker as 'Stock ticker symbol'). The description adds marginal value by mentioning these parameters in natural language ('by ticker symbol or CIK number'), but doesn't provide additional semantics like format examples beyond the schema's 'e.g., 'AAPL''. Baseline 3 is correct since the schema does the heavy lifting.

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 action ('Get') and resource ('company information'), specifying it can be done by 'ticker symbol or CIK number'. It distinguishes itself from siblings like get_filing or get_insider_transactions by focusing on company data rather than filings or transactions. However, it doesn't explicitly differentiate from potential overlaps in sibling tools (e.g., if another tool also retrieves company info), so it's not a perfect 5.

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 by mentioning 'by ticker symbol or CIK number', suggesting it's for retrieving company details. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., when to prefer ticker over CIK, or if other tools might provide similar info). There's no mention of prerequisites, exclusions, or comparisons to sibling tools like get_recent_filings, leaving usage context vague.

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

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about what information is returned ('detailed information'), but doesn't specify format, rate limits, or authentication needs beyond what annotations provide.

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

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes all necessary contextual elements without redundancy.

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

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

For a simple read operation with one parameter and good annotations, the description provides adequate context about what the tool does. However, without an output schema, it could benefit from more detail about the structure of returned 'detailed information'.

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

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

Schema description coverage is 100%, so the schema already fully documents the single 'accession' parameter with examples. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Get detailed information') and resource ('about a specific SEC filing'), and it distinguishes from siblings by specifying the unique identifier ('by accession number') rather than company name or search criteria.

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 indicates when to use this tool (when you have a specific accession number) versus alternatives like 'search_filings' or 'get_recent_filings', but it doesn't explicitly name alternatives or provide exclusion guidance.

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

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

Annotations indicate readOnlyHint=true, which the description aligns with by using 'Get' (implying a read operation). The description adds no behavioral details beyond this, such as rate limits, authentication needs, or data freshness. With annotations covering safety, the description provides minimal extra context.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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?

Given the tool's complexity (6 parameters, no output schema) and rich annotations (readOnlyHint), the description is minimal but adequate. It covers the basic purpose but lacks details on output format, error handling, or usage context. With annotations providing safety info, it meets a baseline level of 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?

Schema description coverage is 100%, so parameters are fully documented in the schema. The description does not add any semantic details beyond what the schema provides, such as explaining parameter interactions or default behaviors. Baseline score of 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose: 'Get insider trading transactions for a company.' It specifies the verb ('Get') and resource ('insider trading transactions'), but does not differentiate from sibling tools like 'get_company' or 'get_filing' beyond the resource type. This makes it clear but not fully distinctive.

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 sibling tools like 'get_company' or 'get_filing', nor does it specify contexts or exclusions for usage. This leaves the agent without direction on 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?

Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the resource scope ('recent SEC filings') and optional filtering, but doesn't disclose behavioral traits like rate limits, authentication needs, pagination behavior (beyond the cursor parameter in schema), or what 'recent' means temporally. With annotations covering safety, this meets baseline expectations without contradictions.

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, efficient sentence that front-loads the core purpose ('Get recent SEC filings') and immediately adds optional filtering details. Every word earns its place with zero redundancy or wasted space, making it easy for an agent to parse quickly.

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

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

Given the tool's moderate complexity (5 parameters, no output schema), the description is minimally adequate. It covers the basic purpose and filtering scope, but lacks details on return format, error handling, or temporal bounds for 'recent'. With annotations providing safety context and schema covering parameters, it's complete enough for basic use but leaves gaps for advanced agent decision-making.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema itself. The description adds marginal value by mentioning filtering by 'company or form type', which aligns with 'cik', 'ticker', and 'forms' parameters, but doesn't provide additional semantics beyond what the schema already covers. This meets the baseline for high schema coverage.

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

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

The description clearly states the verb ('Get') and resource ('recent SEC filings'), and specifies optional filtering capabilities. It distinguishes from siblings like 'get_filing' (singular) and 'search_filings' (broader search) by focusing on recent filings with filtering. However, it doesn't explicitly contrast with 'get_insider_transactions' or 'get_company', leaving some sibling differentiation incomplete.

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 retrieving recent filings with optional filters, but provides no explicit guidance on when to use this tool versus alternatives like 'search_filings' or 'get_filing'. There's no mention of prerequisites, exclusions, or comparative scenarios, leaving the agent to infer appropriate contexts from tool names 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?

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds context about what can be searched (company name or ticker), but doesn't disclose behavioral traits like rate limits, authentication needs, or what happens with no results. With annotations covering safety, this is adequate but not rich.

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

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple search tool and front-loads the core functionality.

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 search tool with good annotations (readOnlyHint) and full schema coverage, the description is minimally adequate. However, without an output schema, it doesn't explain what results look like (e.g., list of filings with metadata), and it lacks sibling differentiation. Given the complexity is low, it's passable but has clear 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%, so the schema already fully documents all three parameters (query, forms, limit). The description mentions 'company name or ticker symbol' which aligns with the query parameter but adds no additional semantic context beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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 as searching SEC filings using company name or ticker symbol, which is a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'get_recent_filings' or 'get_filing', which also work with SEC filings but have different functions.

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 'get_recent_filings' (which might retrieve filings without search) or 'get_filing' (which might retrieve specific filings by ID). There's no mention of prerequisites, use cases, or exclusions.

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