coverageCorpus coverage: which SEC datasets exist, 10-K backfill progress by quarter (2015→now), and — given a ticker — which fiscal years are on file for it. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | Optional stock ticker to check company-specific 10-K coverage |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that the tool is free and describes the coverage information returned, but it does not state whether the operation is read-only, what the response structure looks like, or any limitations beyond optional ticker 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, information-dense sentence that packs relevant details (datasets, backfill progress, fiscal years, free) without unnecessary fluff. It is front-loaded with the core concept 'Corpus coverage'.
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 and no annotations, the description is reasonably complete for a simple metadata tool, clearly listing the covered information. However, it does not describe the exact return format or how output may differ with and without the optional ticker, leaving some ambiguity for an 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?
The schema fully documents the only parameter 'ticker' with description and examples. The description adds minimal extra meaning beyond saying 'given a ticker', which largely duplicates the schema. Baseline 3 is appropriate because schema coverage is 100%.
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 providing corpus coverage details: which SEC datasets exist, 10-K backfill progress, and per-ticker fiscal year availability. It distinguishes itself from sibling data-retrieval tools by focusing on coverage/metadata, though it lacks an explicit action verb.
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?
It implies usage through 'given a ticker' and describes the scope, but it does not explicitly state when to use this tool versus alternatives like find_data or sec_filing_section. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct data area or action: coverage vs find_data vs request_data are clearly separate (metadata, search, and suggestion box), and the three holdings tools (holdings_changes, manager_holdings, security_holders) each address a different question (changes, portfolio, owners). No two tools have ambiguous boundaries.
All tool names use consistent lowercase snake_case (coverage, find_data, fx_rate, request_data, etc.). While some are verb phrases and others are noun phrases, the naming style is uniform and predictable, making it easy to guess tool purposes.
Twelve tools is a well-scoped size for a financial data API server. Each tool covers a distinct data domain, and there is no excessive redundancy or crowding. The count is within the ideal 3-15 range.
The tool set covers a broad range of financial data needs: SEC filings, holdings, insider activity, IPO, macro, and FX. Minor gaps exist (e.g., no direct company fundamentals or full filing text), but the request_data tool provides a path to fill missing datasets, so agents are not at a dead end.