Read SEC filings, reported financial facts and sampled filing comparisons with original sources.
Scored across 4 tools
Each tool targets a distinct capability: discovery (list_filings), content retrieval (read_filing_section), numeric data (filing_facts), and diffing (compare_filing). The descriptions explicitly cross-reference each other (filing id comes from list_filings), leaving little room for misselection.
Three of four names follow a verb_noun pattern (list_filings, read_filing_section, compare_filing), while filing_facts is noun_noun. The deviation is minor and the intent is still immediately readable.
Four tools is on the lean side but each covers a genuinely separate need in a narrow read-only domain, so nothing feels padded or redundant. Slightly thin for the surface area an agent might want, but reasonable.
The read-only lifecycle is well covered: find filings, read sections, extract XBRL facts, and diff against the prior period. Gaps remain around cross-company or full-text search and retrieving a filing beyond the 20,000-character section cap, but core workflows are reachable.
Use when someone asks what changed between a filing and the one before it, such as this year's 10-K against last year's. Compares the 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, and reports when no prior filing is available. 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 | |
| counting | No | |
| docs_url | Yes | |
| sections | No | |
| furniture | No | |
| comparable | No | |
| reportDate | No | |
| http_status | No | |
| retry_after | No | |
| samples_only | No | |
| total_sections | No | |
| diffRulesVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavioral context the annotations don't: 'sampled comparison, not a complete redline', the output shape ('full sentence-change counts and bounded examples for up to eight sections'), and the empty case ('reports when no prior filing is available'). This is genuinely non-obvious behavior that an agent needs before deciding to rely on the output.
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: trigger, behavior, and caveat. The usage trigger is front-loaded, and every sentence adds information without repetition.
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 the description needn't detail return values, yet it still summarizes the return ('sentence-change counts and bounded examples for up to eight sections'). Combined with the no-prior-filing case and the sampling caveat, an agent has everything needed to call and interpret the tool.
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?
Only one parameter, filing_id, and the schema gives no description (coverage 0%). The description names the concept of a filing and its comparison target but doesn't explain the ID format (^\d{1,10}-\d{18}$) or that the preceding filing is resolved automatically. With one param and no schema text, the description provides minimal but acceptable guidance.
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 (compare) and resource (filing vs preceding filing), with a concrete example (this year's 10-K against last year's). It also scopes the comparison to the same company and form, which clearly distinguishes it from siblings like filing_facts or read_filing_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?
The opening clause gives a clear when-to-use trigger ('Use when someone asks what changed...'). It does not explicitly state when NOT to use it or name sibling alternatives, so it falls just short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when someone asks for the reported numbers in one filing, such as revenue, net income or total assets. Returns XBRL facts tagged to that filing's accession, for the API's ten supported concepts: up to 200 reported values with units and periods. It does not return all periods for a company and it does not give 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 readOnly/idempotent/open-world, so the bar is lower. The description adds real substance beyond them: results are XBRL facts tied to the accession, scoped to ten supported concepts, capped at 200 values with units and periods. It does not cover auth requirements or failure modes, but the coverage is solid.
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, use-case front-loaded, and the null-result boundaries are tacked on efficiently. The 'does not give investment advice' clause is filler that does not help tool selection, keeping it short of a 5.
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?
With annotations covering safety semantics and an output schema covering return structure, the description supplies the remaining essentials: what is returned (XBRL facts), the concept ceiling, and the value cap. The one real gap is filing_id format guidance, which neither the schema (0% coverage) nor the description addresses.
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%, so the description must compensate. It hints at the cap ('up to 200 reported values') and that facts are tied to the accession, but never explains the filing_id format/pattern or the limit default of 50 and its 1-200 range. Partial compensation only.
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 concrete verb+resource (return XBRL facts tagged to a filing accession) and states scope ('in one filing'). It differentiates implicitly from compare_filing and list_filings, but never names a sibling tool, so an agent still has to infer which one to pick for section text versus numbers.
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?
'Use when someone asks for the reported numbers in one filing, such as revenue, net income or total assets' gives a clear triggering context with concrete examples. It also states two exclusions (not all periods for a company; not investment advice), though the second is a compliance boundary rather than a genuine routing alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when someone asks for a company's recent SEC filings, such as its latest 10-K, 10-Q or 8-K, by ticker or CIK. Works for any company in the SEC's ticker list. Returns up to 20 filings from the company's recent EDGAR window, each with a filing id, form type, dates, accession number and original SEC link.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | ||
| limit | No | ||
| ticker | Yes | A ticker in EDGAR spelling (BRK-B), or a CIK such as 320193. |
| 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 readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds the 'recent EDGAR window' scoping trait, which is genuine behavioral context, but the enumerated return fields largely duplicate the existing output schema rather than disclosing new traits like auth or rate-limit 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?
Three sentences, front-loaded with the usage trigger and then the return shape; each sentence carries information. The return-field enumeration is somewhat redundant against the output schema, which costs it the top score.
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?
With an output schema present, the definition need not explain return values, yet it still covers the use case, identifier options and result cap. The main gap is that it omits any mention of the 'limit' parameter's default or interplay with the 20-filing ceiling.
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 only 33%, so the description is expected to compensate. It clarifies that the identifier can be a ticker or CIK and implies the form-type filter via examples, but it never mentions the 'limit' parameter or the full enum (20-F, 40-F, /A variants), leaving gaps the schema only partially fills.
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 ('list/ask for') and resource ('a company's recent SEC filings') with concrete examples (10-K, 10-Q, 8-K), so the agent knows exactly what comes back. It does not explicitly contrast itself with siblings like read_filing_section or filing_facts, so it stops short of full sibling differentiation.
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?
'Use when someone asks for a company's recent SEC filings ... by ticker or CIK' is an explicit trigger condition, giving the agent a clear activation context. There is no when-not guidance or naming of the alternative tools (read_filing_section, filing_facts) for deeper lookups, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when someone asks what a filing says in one section, such as risk factors or the business description, or wants the list of sections in a filing. The filing id is one that list_filings returns. Without a section it returns the section index with no text. With a section it returns the text, at most 20,000 characters, with the original length and a flag that marks a cut.
| 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?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context: omitting the section returns only the index with no text, and requesting one returns text capped at 20,000 characters with original length and a truncation flag. It does not mention rate limits, auth needs, or how the 20k cap interacts with max_characters.
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, front-loaded with the usage trigger and followed immediately by return-behavior details. No filler, no restatement of the name or title.
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?
With an output schema present, return values need not be described, yet the description still covers the meaningful output behaviors (truncation, index-vs-text). The only real gap is that max_characters is not surfaced as a tunable parameter, which an agent would need to know to request less than the full text.
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%, so the description must carry the load. It usefully explains the provenance of filing_id (from list_filings) and the behavioral meaning of omitting section, but max_characters is never named as an adjustable input despite the description hinting at a 20,000-character ceiling; the default of 12,000 is unmentioned.
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 states a concrete verb and resource ('read what a filing says in one section') plus a second mode (returning the section index), which is far more specific than the title. It references list_filings as the source of the filing id but does not distinguish this tool from filing_facts or compare_filing, so sibling differentiation is partial.
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?
'Use when someone asks what a filing says in one section, such as risk factors or the business description, or wants the list of sections' gives a clear triggering context and concrete examples. It lacks explicit when-not-to-use guidance or a named alternative among the siblings.
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_filing4 fields changedOutput schema / properties / countingAdded value: +{
+ "type": "string"
+}Output schema / properties / diffRulesVersionAdded value: +{
+ "type": "string"
+}Output schema / properties / furnitureAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "added": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "changed": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "removed": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "unchanged": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "added",
+ "removed",
+ "changed",
+ "unchanged"
+ ],
+ "type": "object"
+}Output schema / properties / sections / items / properties / furnitureAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "counts": {
+ "additionalProperties": false,
+ "properties": {
+ "added": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "changed": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "removed": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "unchanged": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "added",
+ "removed",
+ "changed",
+ "unchanged"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "counts"
+ ],
+ "type": "object"
+}list_filings2 fields changedInput schema / properties / ticker / descriptionAdded value: +"A ticker in EDGAR spelling (BRK-B), or a CIK such as 320193."Input schema / properties / ticker / patternPrevious value: -"^[A-Za-z0-9.-]{1,10}$"New value: +"^[A-Za-z0-9.-]{1,13}$"compare_filingfiling_factslist_filingsread_filing_sectionResearch U.S. public companies from their SEC filings: financials, XBRL facts and filing text.
SEC 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.
SEC filings and financials
Add one secure layer between your agents and this server.
