edgrapi-skills

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

No annotations are provided, and the description does not disclose behavioral traits like idempotency, safe operation, rate limits, or any side effects beyond stating what data is returned.

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 with no redundant information, making it highly concise and easy to parse.

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 lookup tool with one parameter and no output schema, the description adequately lists returned fields. It could mention that the output is a single company profile, but overall sufficient.

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

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

Schema coverage is 100% for the ticker parameter, and the description adds minimal value by simply mentioning 'for a ticker'. Baseline of 3 is appropriate.

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

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

The description explicitly lists the data returned (CIK, legal name, SIC industry, fiscal-year end, exchanges, website) and the data source (SEC EDGAR submissions), distinguishing it from siblings like get_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 use for company profile lookup but provides no explicit guidance on when to use this tool versus alternatives such as get_filings or get_fundamentals.

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 exist, so the description must disclose behavior. It states output includes dates and links, but does not mention handling of invalid tickers, rate limits, or whether the operation is read-only. While adequate for a simple retrieval, deeper context is missing.

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?

A single, front-loaded sentence that efficiently conveys the tool's purpose and output. No superfluous 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?

Despite no output schema, the description specifies what is returned (filing/report dates and document links). It is sufficient for a simple listing tool. Mentioning only three forms may slightly limit perceived scope, but overall complete given the context.

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 minor context by listing example forms (10-K/10-Q/8-K) that map to the 'form' parameter, but does not significantly enhance understanding beyond the schema 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 recent SEC filings for a ticker, listing specific forms (10-K/10-Q/8-K) and output elements (dates and links). This distinguishes it from siblings like get_company or get_fundamentals, which serve different purposes.

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 recent filings are needed but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_sections for specific sections). 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, so description must carry burden. States data source (SEC EDGAR XBRL) and normalization, but does not disclose auth needs, error handling, or data freshness.

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-loading the output type. 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?

Explains output (three statements) and source well. With 3 parameters and no output schema, it is fairly complete, though could mention pagination or limit interpretation.

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 no new parameter details beyond what schema 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?

Clearly states it returns normalized income statement, balance sheet, and cash flow for a US ticker. Distinct from siblings like get_ratios or get_sections.

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?

Implicitly indicates when to use (full statements) vs siblings. Also notes it counts as one request, providing cost context, but lacks explicit when-not-to-use guidance.

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

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

With no annotations, the description carries full burden. It reveals the ratios are derived from SEC EDGAR fundamentals and excludes price-based ratios, which is useful. However, it omits behavioral details such as whether data is historical, if there are any access limits, or what the response format looks like.

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 convey the tool's purpose and key exclusion with no wasted words. Front-loaded with the primary contents.

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 (single parameter, no output schema), the description provides sufficient context about what ratios are returned and their source. It is nearly complete, though could mention the output format or that it returns a single object or list.

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 rephrases the ticker parameter ('US stock ticker, e.g. AAPL.') but adds no new meaning beyond what the input 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?

Description clearly states the tool computes specific financial ratios (margins, returns, leverage, liquidity) derived from SEC EDGAR fundamentals, and explicitly excludes price-based ratios like P/E, P/B. This distinguishes it from sibling tools like get_fundamentals which likely provide raw 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 the tool is for financial ratio analysis and mentions data source (SEC EDGAR), but does not explicitly state when to use it over siblings (e.g., get_fundamentals) or provide alternative suggestions. Context is clear but lacks 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?

Without annotations, the description discloses key behaviors: it always returns the latest filing, provides clean text, and lists available sections when 'item' is omitted. This is sufficient for a read-only data retrieval tool, though error handling or rate limits are not mentioned.

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 without any wasted words. It is front-loaded with the core purpose and immediately followed by a practical usage hint. 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 tool with 3 parameters and no output schema, the description is fairly complete. It explains the data source (latest 10-K/10-Q), output format (clean text), and a key interaction pattern. The only minor gap is not specifying the exact return format (e.g., plain text versus JSON envelope), but the phrase 'as clean text' is informative.

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?

With 100% schema coverage, the baseline is 3. The description adds value by explaining the effect of omitting 'item' (listing sections) and framing the tool's purpose (clean text for RAG). This extra context justifies a 4.

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

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

The description clearly states what the tool does: retrieves narrative sections from the latest 10-K/10-Q as clean text. It specifies the types of sections (Risk Factors, MD&A, Business) and the use case (LLM/RAG equity research). It distinguishes itself from sibling tools like get_company, get_filings, get_fundamentals, and get_ratios by focusing on specific narrative content.

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 guides usage by stating 'Built for LLM/RAG equity research' and provides a concrete tip: 'Omit item to list the available sections first.' While it does not explicitly compare with alternatives, the context of sibling tools makes differentiation clear.

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