SEC Filings & Earnings

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

No annotations are provided, so the description must carry the full burden. It mentions historical data and YoY growth, which is helpful, but does not disclose data latency, rate limits, authentication requirements, or potential side effects. Since it is a read-only tool, the lack of destructive behavior is implied, but more detail would improve 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 concise, with two sentences that front-load the purpose and then specify returns. Every sentence adds value, though the structure could be improved with bullet points or additional 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?

Without an output schema, the description fails to specify the return format (e.g., array, object, units). It also does not clarify whether at least one of cik or ticker is required, or how the tool handles multiple companies. This leaves ambiguity for an AI agent trying to 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 coverage is 100%, so the description does not need to add much. It lists some example concepts (revenue, net income, eps, assets) but not all (e.g., liabilities, equity). This adds marginal value beyond the schema, which already defines all concepts, default, and parameter 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 retrieves structured financial data from SEC XBRL filings and specifies the types of data returned (revenue, net income, EPS, assets, etc.). This clearly differentiates it from sibling tools like get_fda_data or get_insider_trades, which cover different domains.

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 SEC financial data but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or limitations. The context of sibling tools helps, but no direct 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 must cover behavioral traits. It describes the data types and search ability but omits important aspects like read-only nature, authentication requirements, rate limits, or result format. The data size numbers provide some scope context, but overall transparency is 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?

Two concise sentences that front-load the core purpose and provide key numbers and search capabilities. Every word adds value with 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 moderate complexity (4 parameters, no required params, no output schema), the description adequately covers the tool's purpose and key parameters. It does not explain output format or error handling, but these are somewhat expected for a data retrieval tool. The lack of annotations is partially compensated by the description's clarity.

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 mentions 'by drug name or company' which aligns with existing parameter descriptions but adds no additional meaning beyond what the schema already provides. The parameter 'type' has a default and description explaining the two options, which is adequate.

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 FDA drug recalls and adverse event reports from openFDA, specifies the search scope with numbers ('17,000+ recalls and 20M+ adverse events'), and indicates searchable fields (drug name or company). It differentiates well from sibling tools which are all financial in nature.

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

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

While the description doesn't explicitly state when to use this tool versus alternatives, the sibling tools are clearly financial (earnings, insider trades, filings), making the context unambiguous. An explicit when-not or exclusion statement would improve it further.

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 must disclose behavioral details but fails to mention limitations like historical range, real-time delay, pagination, or safety. It only states the data source and actors, leaving key traits unknown.

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 with no fluff, front-loading the main action and context. Every sentence serves a 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?

Despite good purpose clarity, the description lacks output format expectations and does not guide on parameter usage (e.g., ticker vs CIK). For a tool with 3 parameters and no output schema, more context is needed for 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 coverage is 100%, so the schema fully describes parameters. The description adds no additional meaning beyond the schema, achieving the baseline but not exceeding it.

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

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

The description clearly states the verb 'Get', the resource 'insider trading activity from SEC Form 4 filings', and specifies it shows buys/sells by executives/directors, distinguishing it from sibling tools like earnings or FDA 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 implies usage when insider trading data is needed, and the sibling tools cover different domains, but no explicit guidance on when not to use or alternatives 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?

With no annotations, the description must disclose behavior. It does not state required parameters (e.g., at least one of cik or ticker), any side effects, result format, or limitations. The read-only nature is implied but not explicit.

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 concise sentence that front-loads the core purpose. It could be slightly improved by separating the examples from the main verb, but it remains 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?

With no output schema, the description should hint at expected return fields or structure. It does not, nor does it clarify pagination or filtering. However, the tool is relatively simple, so the description is minimally adequate.

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

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

All three parameters are documented in the schema with descriptions (100% coverage). The description adds no additional semantic meaning beyond the schema; baseline 3 is appropriate.

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

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

The description clearly states it retrieves Form 8-K material event filings, listing specific examples like M&A announcements and CEO changes. This distinguishes it from sibling tools such as get_earnings_data (focused on earnings) and get_recent_filings (all filings).

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 through examples (e.g., M&A, CEO changes) but lacks explicit when-to-use or when-not-to-use guidance. No mention of alternatives or that other siblings handle different filing types, leaving the agent to infer.

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 should disclose behavioral traits. It states that filings are 'recent' but does not define the time window, pagination, rate limits, or authentication requirements. The read nature is implied but not explicit.

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 clear front-loading: the first states the core purpose, the second lists filter options. No fluff or redundant information.

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

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

The description covers the basic purpose and filterable forms but lacks context on the meaning of 'recent', result ordering, default limit, and return format. For a tool with no output schema, more context would improve usability.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by annotating form types with their associated event categories (e.g., '8-K events', '4 insider trades'), which helps agents select the correct form. Other parameters (cik, ticker, limit) are not enhanced.

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 SEC EDGAR filings for any public company and lists filterable form types. However, it does not differentiate from sibling tools like get_insider_trades or get_material_events, which cover specific form types.

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

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

No guidance is provided on when to use this tool versus its siblings. The description does not mention alternatives or exclusions, leaving the agent to infer usage 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.