Read SEC filings, reported financial facts and sampled filing comparisons with original sources.
Scored across 4 tools
Each tool targets a distinct operation: discovering filings (list_filings), reading a specific section (read_filing_section), extracting XBRL facts (filing_facts), and comparing filings (compare_filing). No two tools overlap in purpose, and the descriptions clearly delineate their scope.
All tool names follow a consistent verb_noun pattern: compare_filing, filing_facts (noun_verb variant but still consistent), list_filings, read_filing_section. The deviation in filing_facts (noun_verb vs verb_noun) is minor and does not break predictability.
Four tools is slightly lean for the SEC filings domain, but each tool provides a distinct capability (listing, reading, extracting facts, comparing). The set is well-scoped and avoids redundancy, though additional tools for company lookup or full-text search could be beneficial.
The surface covers key operations: discovery, section reading, XBRL fact extraction, and comparison. However, it lacks tools for retrieving filing metadata (e.g., get_filing_details) or accessing full filing text without section names, which could be limiting in some workflows.
Compare an SEC filing with the preceding available reporting period of the same company and form. Returns full sentence-change counts and bounded examples for up to eight sections; reports when a prior filing is unavailable. It is a sampled comparison, not a complete redline.
| Name | Required | Description | Default |
|---|---|---|---|
| filing_id | Yes |
| Name | Required | Description |
|---|---|---|
| id | No | |
| form | No | |
| error | No | |
| prior | No | |
| usage | No | |
| reason | No | |
| status | Yes | |
| ticker | No | |
| totals | No | |
| api_url | No | |
| company | No | |
| current | No | |
| message | No | |
| docs_url | Yes | |
| sections | No | |
| comparable | No | |
| reportDate | No | |
| http_status | No | |
| retry_after | No | |
| samples_only | No | |
| total_sections | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/non-destructive, but the description adds genuinely new behavior: results are a sampled comparison rather than a complete redline, examples are bounded to eight sections, and the tool reports when no prior filing exists. The 'preceding available' wording also explains why idempotentHint is false.
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?
Three tight sentences, front-loaded with the operation and its scope, then the output shape, then the key limitation. No filler.
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?
An output schema exists, so return values need not be detailed, yet the description still outlines counts and bounded examples. It also covers the no-prior-filing edge case and the sampling caveat; only the filing_id semantics remain unaddressed.
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 0% for the single filing_id parameter and the description says nothing about it. The regex pattern in the schema makes the ID format self-evident, so this is a survivable gap, but the description contributes no meaning 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?
The description names a specific verb (compare), resource (SEC filing), and precise comparison baseline (preceding available reporting period of the same company and form). This cleanly separates it from read_filing_section and filing_facts, which retrieve rather than diff.
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 defines the exact comparison context (same company, same form, preceding available period), which tells the agent when this tool is the right choice. It does not name a sibling alternative or state exclusions, but the scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read XBRL facts tagged to one filing's accession, covering the API's ten supported concepts. Returns up to 200 reported values with units and periods. It does not return all company periods or calculate investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| filing_id | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | |
| facts | No | |
| usage | No | |
| filing | No | |
| status | Yes | |
| api_url | No | |
| company | No | |
| message | No | |
| docs_url | Yes | |
| truncated | No | |
| http_status | No | |
| retry_after | No | |
| total_facts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description still adds genuine value by disclosing the ten-concept coverage cap and the 200-value return ceiling, though it says nothing about how the accession is obtained or about pagination for the capped result set.
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?
Three tight sentences with the core action and scope front-loaded, followed by output volume and exclusions. The investment-advice disclaimer is slightly off-topic but does usefully bound agent expectations.
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 read-only list tool with a full output schema, the description covers what is returned, the concept scope, and the volume ceiling, so return-format detail is correctly delegated to the output schema. The remaining gap is the origin of the accession and the unexplained limit argument.
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 0% and there are two parameters. The description clarifies that filing_id is a filing accession (the schema only gives a regex pattern), but the 'limit' parameter is never mentioned or explained—'up to 200 reported values' is a hard ceiling, not guidance on the limit argument or its default of 50.
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?
Names a specific verb and resource ('Read XBRL facts tagged to one filing's accession') and bounds the scope to ten supported concepts, which is far more precise than the bare name. It distinguishes itself from list_filings only indirectly through the 'does not return all company periods' exclusion, so it stops short of a 5.
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?
Usage is implied by the negative statements ('does not return all company periods') which nudges the agent toward a company-wide sibling, but it never names compare_filing, list_filings, or read_filing_section, nor states the condition that selects one. Adequate but the routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find recent SEC filings for a company ticker, with filing ids, form types, dates, accession numbers and original SEC links. Returns up to 20 filings from the company's recent EDGAR window.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | ||
| limit | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | |
| usage | No | |
| status | Yes | |
| api_url | No | |
| company | No | |
| filings | No | |
| message | No | |
| docs_url | Yes | |
| http_status | No | |
| retry_after | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description contributes genuine extra context by bounding the scope ('recent EDGAR window', up to 20 filings), though the field list it enumerates largely duplicates the output schema.
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 tight sentences, front-loaded with the core action and scope. The second sentence is somewhat redundant given an output schema exists, but nothing is padded.
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 three-parameter listing tool with an output schema and full annotation coverage, the description is adequate on scope but silent on the two optional filters and on ordering/pagination behavior within the 'recent window'. An agent could call it, but not optimally.
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 0% across three parameters, and the description does not compensate: it never explains that 'form' filters by the enum values or that 'limit' caps results (the 'up to 20' phrase describes the return, not the parameter). Only 'ticker' is loosely conveyed. The documented form types are output fields, not the filter, which risks confusion.
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 gives a specific verb and resource ('Find recent SEC filings for a company ticker') and enumerates what comes back, so the purpose is unambiguous. It does not, however, explicitly distinguish itself from siblings like read_filing_section or filing_facts, leaving the agent to infer the difference from names alone.
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?
There is no statement of when to use this versus the three sibling tools. The 'recent EDGAR window' phrasing implies a discovery/enumeration use case, but no alternatives or exclusions are named, so the agent gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a named section from an SEC filing id. Omitting section returns the section index without text. A section reply contains at most 20,000 characters, with its original length and an explicit truncation flag.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | ||
| filing_id | Yes | ||
| max_characters | No |
| Name | Required | Description |
|---|---|---|
| id | No | |
| meta | No | |
| error | No | |
| title | No | |
| usage | No | |
| status | Yes | |
| topics | No | |
| api_url | No | |
| message | No | |
| product | No | |
| docs_url | Yes | |
| sections | No | |
| sourceUrl | No | |
| index_only | No | |
| http_status | No | |
| retry_after | No | |
| parserVersion | No | |
| section_found | No | |
| sections_truncated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful behavioral detail beyond annotations: the 20,000-character cap, original length, and truncation flag. It doesn't mention auth requirements or latency, but the truncation disclosure is valuable for an agent. Annotations cover read-only and idempotency aspects.
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?
Three sentences, each front-loading essential behavior: what it reads, the omit-section behavior, and the size/truncation contract. No wasted 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?
Covers the key output behavior (section text vs index, truncation) despite an output schema existing. Enough for an agent to invoke correctly, though it could mention the filing_id format or error cases.
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 0%, so the description must carry the parameter burden. It explains section omission and the default max_characters implicitly via the 20,000 cap, and names the filing_id parameter. It doesn't explain the section naming pattern or the max_characters minimum, but adds useful semantics.
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?
States a specific verb (read) and resource (named section from an SEC filing id). Distinguishes clearly from sibling tools like filing_facts and compare_filing by scoping it to reading a single named section.
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?
Describes the omit-section behavior, which is implicit usage guidance, but doesn't state when to use this tool versus filing_facts or compare_filing. There's no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_filingfiling_factslist_filingsread_filing_sectionSEC Financial Statement & Notes data sets — dimensional facts + note text.
Search SEC filings, read 10-K/8-K, query XBRL facts, track Form 4 insider trades.
Read-only financial facts from SEC/EU/KR filings: tickers, periods, report lines, =CaData() grids.
Primary-source SEC filing intelligence and financial/disclosure reconciliation for AI agents.
Add one secure layer between your agents and this server.
