Resolve tickers or CIK numbers to SEC EDGAR company identifiers and retrieve company facts and quarterly filings for regulatory and financial research.
SEC EDGAR company facts, quarterly filings, and CIK lookup under Lowe v. SEC Publisher's Exclusion.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | Ten-digit SEC Central Index Key (e.g. '0000320193') | |
| ticker | No | Stock ticker symbol (e.g. 'AAPL', 'MSFT') |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The inclusion of the phrase 'under Lowe v. SEC Publisher's Exclusion' provides significant contextual behavioral information. This legal framing informs the agent about the specific limitations or scope of the data it will return, going beyond the 'readOnly' annotation.
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, focused sentence that effectively lists the three primary use cases (facts, filings, CIK lookup). It is highly efficient, though slightly dense due to the inclusion of a legal reference.
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 definition is highly functional, and the annotations cover the safety profile. However, it does not specify the nature or depth of the returned data (e.g., 'returns a JSON object containing quarterly metrics'). This lack of output detail limits completeness, even with the 100% parameter coverage.
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 coverage is 100%, meaning all parameters are well-defined structurally. The description adds general context (that these parameters are used for CIK and ticker lookup) but does not add unique semantic meaning to the specific parameters beyond what the schema already details.
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 uses a specific verb ('lookup') and clearly identifies the resource (SEC EDGAR company facts and filings). It is highly specific to its domain, which helps distinguish it from general financial search tools in the context of the sibling tools provided.
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 defines what the tool does, it offers no guidance on when it should be used over alternatives. The AI must infer if general SEC lookup is appropriate versus the highly specialized tools in the sibling list (e.g., `cfpb_complaints` or `fdic_bank_health`).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.