Edgrapi — SEC EDGAR Financials

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 EDGAR) but lacks disclosure on read-only nature, rate limits, or authentication requirements.

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?

One sentence covering key output fields efficiently. Could be broken into sub-elements but remains concise and 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?

No output schema; description lists output fields but lacks details on response format, error conditions, or pagination. Adequate for a simple get tool but not fully 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 covers 100% of the single parameter 'ticker' with a clear example. Description adds no additional parameter information beyond schema, but baseline is 3 due to 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?

Description clearly states the tool retrieves specific company profile data (CIK, legal name, SIC industry, fiscal-year end, exchanges, website) for a ticker from SEC EDGAR. Distinguishes from sibling tools like get_filings or get_fundamentals.

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 vs alternatives. While sibling tools are listed, the description does not provide context or conditions for 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 should disclose behavioral traits. It mentions 'Recent' but does not define what 'recent' means (e.g., last 30 days). It does not state whether the tool is read-only, destructive, or has rate limits. The absence of such details leaves the agent uncertain about behavior.

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

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

The description is a single, well-structured sentence that conveys all essential information without unnecessary words. It is appropriately sized and front-loaded with the core purpose.

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

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

Given the simple nature of the tool (retrieving filings), the description covers the basics but lacks details on pagination, what 'recent' means, or the exact return format. Since there is no output schema, additional description of the response structure would improve completeness.

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

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

The input schema has 100% description coverage for all three parameters. The description adds context beyond the schema by stating that filings are 'recent', specifying form types, and mentioning the return includes dates and document links. This enhances understanding without repeating schema info.

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 recent SEC filings) and the resource (filings for a ticker), specifies the form types (10-K/10-Q/8-K) and what is returned (dates and links). It distinguishes this tool from siblings like get_company, get_fundamentals, etc., which focus on different 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 use when fetching SEC filings, but does not provide explicit guidance on when to use alternatives or when not to use this tool. It lacks exclusion criteria or context for preferring this over 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 carries the full burden. It discloses the data source (SEC EDGAR XBRL), normalization, and cost. However, it does not explicitly state that the operation is read-only or describe any side effects, though this is implied.

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: the first clearly states the purpose, and the second provides cost context. It is front-loaded with key information and contains 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 no output schema, the description explains the source, normalization, and cost. It mentions the three statement types, which is informative. However, it does not describe the output format or that periods default to annual, which would be helpful for 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?

All parameters have descriptions in the input schema, so the baseline is 3. The description adds no additional detail about individual parameters beyond what the schema provides, thus it neither enhances nor detracts.

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

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

The description clearly specifies that the tool retrieves normalized income statement, balance sheet, and cash flow for US-listed tickers from SEC EDGAR XBRL. This distinguishes it from siblings like get_company (company info), get_filings (filings list), get_ratios (ratios), and get_sections (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?

The description implies the tool is for obtaining financial statements, but it does not explicitly state when to use it over alternatives or when not to use it. The mention of counting as one request on the Edgrapi plan hints at cost but provides no guidance 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?

No annotations are provided, so the description carries the full burden. It states the tool computes ratios from EDGAR fundamentals, indicating a read-only operation. However, it does not disclose response format, pagination, or potential latency. The description is 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?

Description is a single sentence that efficiently conveys the tool's purpose, included ratios, exclusion, and data source. 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?

Given the simple parameter (ticker) and no output schema, the description lists ratio categories but does not specify output format, whether multiple years are returned, or how to interpret values. For a financial tool, more detail on returned structure would improve completeness.

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

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

The only parameter is 'ticker', with a schema description of 'US stock ticker, e.g. 'AAPL'.' The tool description does not add additional meaning or constraints beyond the schema. With 100% schema coverage, 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?

Description clearly states the tool returns margins, returns (ROE/ROA), leverage, and liquidity ratios, and explicitly excludes price-based ratios like P/E and P/B. This distinguishes it from sibling tools like get_fundamentals, which likely return 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?

Description mentions ratios are 'derived from SEC EDGAR fundamentals' and excludes price-based ratios, which implies it should be used when computed ratios are needed. However, it does not explicitly compare to siblings or state when not to use. The guideline is implied rather than 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?

Despite no annotations, the description states that sections come from the 'latest' filing and returns 'clean text,' giving basic behavioral insight. It does not disclose limitations such as data freshness, caching, or error handling, leaving gaps for an agent.

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 three sentences: purpose, examples, and a usage hint. It is front-loaded with the core function, uses no filler, and each sentence contributes meaningfully.

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 straightforward retrieval tool with no output schema, the description covers the main usage and the important note about listing sections. It lacks mention of error cases (e.g., invalid ticker) but is otherwise sufficient for typical use.

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

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

Schema description coverage is 100%, and the parameter descriptions are already detailed (e.g., noting the default for 'form', examples for 'item'). The tool description adds context about research usage but does not significantly enhance parameter-level 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?

Description clearly states the tool retrieves narrative sections from 10-K/10-Q filings, listing specific items like Risk Factors, MD&A, and Business. It distinguishes from sibling tools (e.g., get_filings, get_fundamentals) by focusing on narrative text for equity research.

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 indicates the tool is 'Built for LLM/RAG equity research' and advises to 'Omit 'item' to list the available sections first,' providing clear usage guidance. However, it lacks explicit exclusions or alternatives beyond the implicit sibling distinctions.

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