FiledProof

Server Details

Primary-source SEC filing intelligence for AI agents, with exact evidence and provenance.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.8% over 22 days
Last Tested: 2026-10-02 22:55
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-09-25 14:20 across 13 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with explicit cross-references to guide selection. For example, build_disclosure_lineage is for persisted historical evolution, build_timeline for simple chronology, compare_filings for exact pair diff, and check_disclosure_changes for prioritized new changes—no ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., build_disclosure_lineage, compare_filings, resolve_issuer). The verbs are distinct and convey the action, and the nouns are domain-specific, making the pattern highly predictable.

Tool Count5/5

13 tools is well-scoped for the SEC filing analysis domain, covering identity resolution, listing, searching, comparing, verifying, monitoring, building timelines/matrices, and financial fact reconciliation. Each tool earns its place without redundancy.

Completeness5/5

The tool surface comprehensively covers the domain: resolve_issuer for identity, list_filings for inventory, search_evidence for passage retrieval, verify_claim for claims, compare_filings for diffs, check_disclosure_changes/check_material_filing_changes for monitoring, build_* tools for artifacts, and reconcile_financial_fact for financial validation—no obvious gaps.

Available Tools

13 tools

filedproof.build_disclosure_lineageBuild historical disclosure lineageA

Read-onlyIdempotent

Inspect

Build or reuse a persisted disclosure history for one issuer and topic, with deterministic per-filing fingerprints and same-form transition edges backed by exact SEC evidence. Use this when historical evolution or repeat reuse matters. Use filedproof.compare_filings for a one-off exact filing pair, filedproof.build_timeline for simple chronology without reusable transition state, or filedproof.build_disclosure_matrix when the objective is comparison across multiple companies. Structural change is not a materiality judgment.

ParametersJSON Schema

Name	Required	Description
`item`	No	Optional SEC filing item such as 1A or 7.
`forms`	No	SEC forms to include. Defaults to 10-K and 10-Q. Same-form transitions are linked independently.
`limit`	No	Maximum topic-relevant change evidence records retained per transition.
`topic`	Yes	Public-company disclosure topic whose filing-to-filing history should be accumulated, such as AI regulation, cybersecurity, or supply-chain concentration.
`filings`	No	Maximum filings to inspect in this invocation. Previously persisted lineage can contain more accumulated history.
`history`	No	Use bounded historical SEC submission archives when the durable catalog does not already provide enough history.
`section`	No	Optional exact normalized section heading.
`identifier`	Yes	Ticker, CIK, or exact SEC company name.
`comparisonLimit`	No	Maximum changed blocks inspected in each same-form structural comparison.
`fingerprintLimit`	No	Maximum relevant evidence records used to fingerprint one filing.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide idempotent, read-only, and non-destructive hints. The description adds valuable behavioral context beyond those: lineage is persisted/reusable, fingerprints are deterministic, transitions are backed by exact SEC evidence, and structural change alone is not a materiality judgment. These details materially shape how an agent should interpret results.

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

Conciseness5/5

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

Four sentences with no filler: the core action and outcome are front-loaded, followed by crisp usage guidance and a caveat preventing misinterpretation. Every sentence earns its place.

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

Completeness5/5

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

Given the tool's complexity (10 parameters, output schema, many siblings), the description is remarkably complete. It explains what is built, when to use it, which alternatives to choose, and a key interpretive limitation. The output schema covers return-value details, so nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already explains every parameter. The description reinforces the overall purpose around 'one issuer and topic' but does not add parameter-specific semantics beyond the schema. Baseline 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb and resource: 'Build or reuse a persisted disclosure history for one issuer and topic,' and adds concrete details like deterministic per-filing fingerprints and same-form transition edges. This makes the tool's function clear and easily distinguishable from siblings such as build_disclosure_matrix and build_timeline.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('when historical evolution or repeat reuse matters') and names specific alternatives for other scenarios: compare_filings for one-off pairs, build_timeline for simple chronology, and build_disclosure_matrix for cross-company comparison. This is exemplary routing guidance.

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

filedproof.build_disclosure_matrixBuild cross-company disclosure matrixA

Read-onlyIdempotent

Inspect

Align one disclosure topic across two to six public companies using each company's source-backed historical disclosure lineage. Use this when cross-company comparison is the objective and the caller needs current evidence plus latest same-form transition evidence on a common basis without independently retrieving, parsing, aligning, and re-comparing every filing history. Use filedproof.build_disclosure_lineage for one issuer, not this tool; use filedproof.check_disclosure_changes when monitoring newly filed changes for one issuer. The matrix is an evidence substrate, not a ranking or materiality judgment.

ParametersJSON Schema

Name	Required	Description
`item`	No	Optional SEC filing item such as 1A or 7.
`forms`	No	SEC forms to align. Defaults to 10-K for stronger cross-company comparability.
`limit`	No	Maximum topic-relevant change evidence retained in each underlying lineage transition.
`topic`	Yes	Disclosure topic to align across companies, such as cybersecurity, AI infrastructure, or supply-chain concentration.
`filings`	No	Maximum filings per company used to build or reuse the underlying disclosure lineage.
`history`	No	Whether to use bounded historical SEC submission archives when needed.
`section`	No	Optional exact normalized section heading.
`identifiers`	Yes	Two to six public-company identifiers to align on the same filing-grounded disclosure topic.
`comparisonLimit`	No	Maximum number of changed blocks to inspect in each filing comparison.
`maxArchiveFiles`	No	Maximum number of historical SEC submission archive files to inspect when history is enabled.
`fingerprintLimit`	No	Maximum number of relevant evidence records used to fingerprint one filing.
`currentEvidenceLimit`	No	Maximum current-filing evidence records returned per company and form.
`transitionEvidenceLimit`	No	Maximum evidence records returned for each latest same-form transition.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's burden is lower. It adds useful behavioral context beyond annotations by clarifying that the result is 'an evidence substrate, not a ranking or materiality judgment' and that evidence is 'source-backed' and 'filing-grounded,' which prevents misinterpretation of 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.

Conciseness5/5

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

The description is composed of four purposeful, front-loaded sentences: first the core action, then when to use, then explicit alternatives, then a critical output caveat. Every sentence earns its place with no redundancy or filler.

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

Completeness5/5

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

Given the tool's complexity, the fully documented 13-parameter schema, and the presence of an output schema, the description provides all necessary high-level context: core purpose, scope, when to use, what not to use it for, and how to interpret the result. No essential guidance is missing for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema provides detailed descriptions for all 13 parameters, including ranges, defaults, and meaning (e.g., 'forms', 'identifiers', 'topic'). The description adds no parameter-specific semantic detail, but the baseline of 3 is appropriate because the schema already carries the full burden.

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

Purpose5/5

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

The description states a specific verb ('align') and resource ('one disclosure topic across two to six public companies'), and explicitly distinguishes itself from siblings by naming build_disclosure_lineage and check_disclosure_changes. An agent can identify this tool's unique cross-company, common-basis scope without inspecting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'Use this when cross-company comparison is the objective' and when the caller needs current evidence plus latest same-form transition evidence. It also names alternatives and exclusions for one-issuer lineage and change monitoring, leaving no ambiguity about tool selection.

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

filedproof.build_evidence_packBuild answer-ready evidence packA

Read-onlyIdempotent

Inspect

Package the strongest relevant SEC evidence for an upstream AI agent, preserving source URLs, locators, search scope, coverage, and explicit non-inference rules. Use this when the research question is already known and the caller wants a compact evidence bundle ready for downstream reasoning. Use filedproof.search_evidence for broader retrieval, filedproof.verify_claim for an explicit support-or-contradiction verdict, or filedproof.build_timeline for chronological organization.

ParametersJSON Schema

Name	Required	Description
`q`	Yes	Research question or disclosure topic.
`item`	No	Optional SEC filing item, such as 1A or 7.
`forms`	No	SEC forms to search. Defaults to 10-K and 10-Q.
`limit`	No	Maximum number of operation-specific evidence or result records to return.
`filings`	No	Maximum number of filings to inspect for this invocation.
`history`	No	Whether to use bounded historical SEC submission archives when needed.
`section`	No	Optional exact normalized section heading.
`identifier`	Yes	Ticker, CIK, or exact SEC company name.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it preserves source URLs, locators, search scope, coverage, and explicit non-inference rules, and it produces a compact bundle for downstream reasoning. It doesn't describe pagination or exact output shape, but the output schema exists and the annotations carry the safety burden, so a 4 is appropriate.

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

Conciseness5/5

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

The description is three sentences with zero waste. The core purpose is front-loaded, the usage condition is stated, and the sibling alternatives are listed compactly. Every sentence earns its place.

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

Completeness4/5

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

For a read-only, idempotent tool with 100% schema coverage and an output schema, the description is nearly complete. It explains what the tool produces, when to use it, and how it differs from siblings. The only minor gap is that it doesn't describe the exact structure of the evidence pack, but the output schema covers that.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 8 parameters. The description adds context about the overall purpose (packaging evidence) but doesn't add per-parameter meaning beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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

Purpose5/5

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

The description states a specific verb ('Package'), a clear resource ('strongest relevant SEC evidence'), and the intended consumer ('upstream AI agent'). It also explicitly names sibling tools (search_evidence, verify_claim, build_timeline) and distinguishes this tool from them, so an agent can tell them apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'when the research question is already known and the caller wants a compact evidence bundle ready for downstream reasoning.' It also names alternatives and their purposes: search_evidence for broader retrieval, verify_claim for support-or-contradiction verdicts, build_timeline for chronological organization. This is clear routing guidance.

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

filedproof.build_timelineBuild disclosure evidence timelineA

Read-onlyIdempotent

Inspect

Organize topic-relevant filing evidence chronologically across a bounded set of SEC filings. Use this when sequence over time is the primary need. Use filedproof.build_disclosure_lineage when you need persisted same-form evolution and reusable transition state, filedproof.compare_filings for exactly two known accessions, or filedproof.check_disclosure_changes for prioritized monitoring of newly filed changes. The timeline does not invent semantic change or materiality.

ParametersJSON Schema

Name	Required	Description
`q`	Yes	Research question or disclosure topic.
`item`	No	Optional SEC filing item, such as 1A or 7.
`forms`	No	SEC forms to search. Defaults to 10-K and 10-Q.
`limit`	No	Maximum number of operation-specific evidence or result records to return.
`filings`	No	Maximum number of filings to inspect for this invocation.
`history`	No	Whether to use bounded historical SEC submission archives when needed.
`section`	No	Optional exact normalized section heading.
`identifier`	Yes	Ticker, CIK, or exact SEC company name.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds the caveat that 'the timeline does not invent semantic change or materiality,' which is useful behavioral context. However, it doesn't disclose how the bounded set is determined or return format details, but with strong annotations, the bar is lowered; 3 is fair.

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

Conciseness5/5

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

The description is concise and front-loaded with the primary purpose, then quickly moves to alternative selection. Every sentence adds value with no fluff.

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

Completeness4/5

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

Given the tool's complexity and the presence of an output schema, the description covers the core purpose and usage guidance effectively. It might lack explicit mention of how the bounded set is restricted (e.g., by forms and filings parameters), but the schema covers that. Overall, it is complete enough for an agent to use correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are well-documented. The description adds the concept that 'bounded set' relates to filings and forms but doesn't need to explain each parameter. Baseline 3 is appropriate because the schema does the heavy lifting.

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

Purpose5/5

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

The description explicitly states it organizes evidence chronologically across a bounded set of SEC filings, which is specific and distinguishes it from siblings like build_disclosure_lineage and compare_filings. The purpose is clear and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use guidance ('when sequence over time is the primary need') and explicitly names alternative tools with their use cases, including build_disclosure_lineage, compare_filings, and check_disclosure_changes. This gives clear direction on selection.

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

filedproof.check_disclosure_changesPrioritize new SEC disclosure changesA

Read-onlyIdempotent

Inspect

Configured 1.00 USD specialist operation when runtime commerce is active. Use this for one issuer when the caller needs changes in newly filed disclosures prioritized against the prior filing of the same form, with compact before/after evidence from SEC filings and retry-safe checkpoint state. Supply a freeform topic, or profile=financial_risk for the bounded liquidity, debt, dilution/equity-issuance, and changed-risk report. The report separates documented filing changes from deterministic category/attention interpretation. Use filedproof.check_material_filing_changes for a fast low-cost same-form 10-K or 10-Q comparison, filedproof.compare_filings for a free raw structural diff between known accessions, or filedproof.list_filings first when coverage is uncertain. Attention is not a legal, accounting, economic, or investment materiality judgment, and pre-payment validation rejects invalid or non-comparable work before a charge.

ParametersJSON Schema

Name	Required	Description
`item`	No	Optional SEC filing item such as 1A or 7.
`forms`	No	SEC forms to monitor. Defaults to 10-K and 10-Q.
`limit`	No	Maximum topic-relevant change evidence records per filing comparison.
`topic`	No	Disclosure topic to monitor, such as AI capital spending, China risk, or cybersecurity. Provide topic or profile, not both.
`history`	No	Whether to use bounded historical SEC submission archives when needed.
`profile`	No	Bounded report profile. financial_risk checks liquidity/capital resources, debt/borrowings/covenants/maturities, dilution/equity-issuance disclosures, and changed risk disclosures together. Provide profile or topic, not both.
`identifier`	Yes	Ticker, CIK, or exact SEC company name.
`maxNewFilings`	No	Maximum newly detected filings to process in one check.
`sinceAccession`	No	Checkpoint accession returned by the previous paid check. Omit for the first snapshot.
`comparisonLimit`	No	Maximum number of changed blocks to inspect in each filing comparison.
`maxArchiveFiles`	No	Maximum historical SEC submission archive files to inspect when history is enabled.

Output Schema

ParametersJSON Schema

Name	Required	Description
`mode`	Yes
`forms`	Yes
`scope`	Yes
`topic`	Yes
`events`	Yes
`issuer`	Yes
`status`	Yes
`purpose`	Yes
`truncated`	Yes
`checkpoint`	Yes
`changeCount`	Yes
`limitations`	No
`agentGuidance`	Yes
`reportProfile`	No
`schemaVersion`	Yes
`changeDetected`	Yes
`attentionCounts`	Yes
`haltedOnFailure`	Yes
`latestAvailable`	Yes
`priorCheckpoint`	Yes
`overallAttention`	Yes
`newFilingsDetected`	Yes
`remainingNewFilings`	Yes
`highPriorityChangeCount`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the bar is lower, but the description still adds meaningful context: it is a paid 1.00 USD specialist operation, pre-payment validation rejects invalid or non-comparable work before charging, it uses retry-safe checkpoint state, separates documented changes from interpretation, and includes a clear caveat that attention is not a materiality judgment. No contradiction with annotations.

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

Conciseness4/5

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

The description is dense and front-loaded with the core use case and cost/behavior context, and every sentence carries purpose. It is longer than average, but given the tool's complexity and sibling differentiation requirements, the length is justified. The opening phrasing about 'runtime commerce' is slightly awkward but not redundant.

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

Completeness5/5

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

For a complex 11-parameter tool with an output schema and rich annotations, the description is comprehensive: it covers primary purpose, valid inputs, alternative tools, payment and validation behavior, checkpoint retry semantics, and the limits of the tool's interpretation. Nothing essential for an agent to select or invoke it correctly appears missing.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all parameters; the baseline is 3. The description adds genuine value by explaining the financial_risk profile in detail (liquidity, debt, dilution/equity-issuance, changed-risk report), clarifying topic vs profile exclusivity, and referencing the checkpoint/sinceAccession mechanism in behavioral terms.

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

Purpose5/5

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

The description states a specific verb+resource: prioritize changes in newly filed disclosures against the prior filing of the same form for one issuer, with compact before/after evidence. It also explicitly names sibling tools it is not, such as check_material_filing_changes and compare_filings, making the tool's distinct role clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says when to use this tool ('newly filed disclosures prioritized against the prior filing of the same form', 'one issuer') and gives explicit alternatives: check_material_filing_changes for fast low-cost same-form comparisons, compare_filings for raw structural diffs, and list_filings when coverage is uncertain. This is strong, unambiguous routing guidance.

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

filedproof.check_material_filing_changesCheck meaningful changes between SEC filingsA

Read-onlyIdempotent

Inspect

Configured 0.10 USD fast specialist operation when runtime commerce is active. Compare two same-form 10-K or 10-Q filings and return source-grounded meaningful changes, explainable decision-relevance triage, low-signal/no-change sections, confidence, limitations, and routing guidance when deeper disclosure verification is warranted. Supply both accessions for an exact pair, or omit both and choose form so FiledProof deterministically selects the latest comparable pair. This is not a legal materiality or investment-significance determination.

ParametersJSON Schema

Name	Required	Description	Default
`form`	No	Comparable SEC form. Defaults to 10-K and must match both explicit filings when accessions are supplied.	10-K
`item`	No	Optional SEC filing item such as 1A or 7.
`focus`	No	Optional bounded decision-relevance focus. Defaults to all maintained change categories.	all
`limit`	No	Maximum meaningful change objects to return.
`history`	No	Allow bounded historical SEC submission lookup when automatic pair resolution needs it.
`identifier`	Yes	Ticker, CIK, or exact SEC company name.
`laterAccession`	No	Optional later SEC accession. Supply together with earlierAccession for an exact pair.
`earlierAccession`	No	Optional earlier SEC accession. Supply together with laterAccession for an exact pair.

Output Schema

ParametersJSON Schema

Name	Required	Description
`issuer`	Yes
`changes`	Yes
`sources`	Yes
`summary`	Yes
`evidence`	No
`operation`	Yes
`confidence`	Yes
`laterFiling`	Yes
`limitations`	Yes
`earlierFiling`	Yes
`schemaVersion`	Yes
`lowSignalChanges`	No
`recommendedNextStep`	No
`unchangedOrLowSignalSections`	No

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context: a 0.10 USD fast specialist operation when runtime commerce is active, deterministic pair selection, and a clear disclaimer that this is not a legal materiality determination. This goes beyond what annotations alone provide.

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

Conciseness4/5

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

The description is four sentences and front-loads the operation and cost context. It is efficient, but the cost/runtime-commerce sentence is somewhat tangential and could be clearer or placed elsewhere. Overall, it earns its place without being bloated.

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

Completeness4/5

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

Given the output schema exists, the description does not need to explain return values. It covers the operation, pair selection, scope limitations, and output categories. It is complete enough for an agent to invoke correctly, though explicit sibling differentiation would improve selection confidence.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter semantics by explaining the exact-pair accession requirement and the alternative of omitting both accessions to let the tool deterministically select the latest comparable pair. This is beyond what the schema states.

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

Purpose4/5

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

The description clearly states the tool compares two same-form 10-K or 10-Q filings and returns meaningful changes, with a specific verb and resource. It does not explicitly distinguish itself from sibling tools like compare_filings or check_disclosure_changes, so it falls 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete usage instructions: supply both accessions for an exact pair, or omit both and let FiledProof select the latest comparable pair. It also notes this is not a legal materiality or investment-significance determination, but it does not name alternatives or explicitly state when to prefer this tool over siblings.

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

filedproof.compare_filingsCompare two SEC filingsA

Read-onlyIdempotent

Inspect

Compare two known filings from the same issuer and return source-backed added and removed disclosure blocks. Use this low-level operation when you already know the exact left and right accessions and only need a structural diff. Use filedproof.build_disclosure_lineage for multi-filing historical evolution, filedproof.build_timeline for topical chronology, or filedproof.check_disclosure_changes when you need prioritized new-change triage and recurring checkpoint semantics. Structural change is not semantic interpretation or a materiality judgment.

ParametersJSON Schema

Name	Required	Description
`item`	No	Optional filing item such as 1A or 7.
`left`	Yes	Left SEC accession number.
`limit`	No	Maximum number of operation-specific evidence or result records to return.
`right`	Yes	Right SEC accession number.
`identifier`	Yes	Ticker, CIK, or exact SEC company name.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, lowering the burden on the description. The description adds useful behavioral context by clarifying that results are source-backed, structural only, and not semantic or materiality assessments, which helps set expectations beyond the schema.

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

Conciseness5/5

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

The description is well-structured and front-loaded: a concise definition appears first, followed by explicit usage guidance and a clear limitation. Every sentence contributes value, and the alternatives are listed without rambling.

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

Completeness5/5

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

For a structural comparison tool with a full input schema, output schema, and rich annotations, the description is complete. It covers the required preconditions, output scope, relational guidance to siblings, and an important caveat about interpretative limits.

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

Parameters3/5

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

Input schema coverage is 100%, so the schema fully documents all parameters and the description does not need to repeat them. The description adds modest semantic framing by emphasizing known accessions and same-issuer scope, but it does not add meaning beyond what the schema already conveys.

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

Purpose5/5

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

The description states a specific verb-plus-resource pair: 'Compare two known filings from the same issuer' and clearly defines the output as 'source-backed added and removed disclosure blocks.' It also distinguishes itself as a low-level structural-diff operation, unlike its semantic siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: when you already know the exact left and right accessions and only need a structural diff. It names three alternatives and the exact conditions for choosing them, and further clarifies that this is not semantic interpretation or materiality judgment.

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

filedproof.list_filingsList SEC filingsA

Read-onlyIdempotent

Inspect

List recent or bounded historical SEC filings with canonical source metadata and explicit coverage limits. Use this when you need form, filing-date, or accession inventory, when choosing an exact pair for filedproof.compare_filings, or when confirming coverage before filedproof.check_disclosure_changes. For passage-level research, use filedproof.search_evidence instead.

ParametersJSON Schema

Name	Required	Description
`forms`	No	SEC filing form types to include, such as 10-K, 10-Q, or 8-K.
`limit`	No	Maximum number of operation-specific evidence or result records to return.
`history`	No	Whether to use bounded historical SEC submission archives when needed.
`identifier`	Yes	Ticker, CIK, or exact SEC company name.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing 'explicit coverage limits' and 'bounded historical SEC submission archives' via the history parameter, which tells the agent that results may be limited and historical depth is bounded. It doesn't describe pagination or exact return shape, but the output schema exists and the annotations cover the safety profile, so a 4 is appropriate.

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

Conciseness5/5

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

Three sentences with zero waste. The core purpose is front-loaded, followed by explicit use cases and a sibling alternative. Every sentence earns its place.

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

Completeness5/5

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

Complete for a read-only list tool. The description covers what it returns (canonical source metadata), when to use it, and when not to use it. The output schema exists, annotations cover safety, and the parameter schema is fully documented. Nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters (forms, limit, history, identifier). The description adds context about 'canonical source metadata' and 'coverage limits' but doesn't add significant meaning beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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

Purpose5/5

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

The description states a specific verb ('List') and resource ('SEC filings') with clear scope: 'recent or bounded historical SEC filings with canonical source metadata and explicit coverage limits.' It also distinguishes itself from siblings by naming what it is not for ('For passage-level research, use filedproof.search_evidence instead'). This is a clear, specific purpose that an agent can act on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'when you need form, filing-date, or accession inventory, when choosing an exact pair for filedproof.compare_filings, or when confirming coverage before filedproof.check_disclosure_changes.' It also names the alternative for passage-level research (filedproof.search_evidence). This is exemplary usage guidance with both positive and negative conditions.

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

filedproof.preflight_financial_factCheck financial fact applicabilityA

Read-onlyIdempotent

Inspect

Free eligibility check for filedproof.reconcile_financial_fact. Use this before the $1 specialist operation when issuer identity, filing selection, supported metric, fiscal-period dates, annual-versus-quarter context, required SEC Company Facts contexts, or an optional SEC-filed 8-K earnings-release number comparison may be uncertain. It validates applicability without revealing the filing value, comparison source value, later revision values, evidence, or arithmetic. For general filing lookup or narrative research, use filedproof.resolve_issuer, filedproof.list_filings, or filedproof.search_evidence instead.

ParametersJSON Schema

Name	Required	Description	Default
`cik`	No	Legacy/direct SEC CIK input. Prefer identifier when starting from a ticker or company name.
`metric`	Yes	Financial metric to reconcile: revenue, net income, or operating cash flow.
`as_of_date`	No	Optional historical cutoff. The selected anchor filing must have been filed on or before this date; later values never replace the primary answer.
`identifier`	No	Issuer ticker, exact company name, CIK, or CIK-prefixed identifier. FiledProof resolves this to the durable SEC CIK before research and payment.
`period_end`	Yes	Requested fiscal-period end date.
`period_type`	No	Whether the requested value is one standalone fiscal quarter or the full fiscal year.	standalone_fiscal_quarter
`period_start`	Yes	Requested fiscal-period start date.
`anchor_accession`	No	Optional 10-Q/10-K accession, including amendments. If omitted, FiledProof selects the earliest compatible filing for the requested period.
`comparison_value`	No	Actual-unit integer value claimed from the SEC-filed earnings-release exhibit. FiledProof must find this value in metric context before the comparison is eligible.
`comparison_exhibit`	No	Optional exact EX-99 exhibit filename or safe relative path when an 8-K contains multiple candidate earnings-release exhibits.
`comparison_accession`	No	Optional SEC 8-K/8-K/A accession containing an earnings-release exhibit to compare with the filing-anchored GAAP fact. Provide comparison_value with it.
`include_subsequent_revisions`	No	When true, report later different values for the same SEC concept, unit, and period separately from the primary anchored value.

Output Schema

ParametersJSON Schema

Name	Required	Description
`price`	Yes
`checks`	Yes
`reason`	No
`status`	Yes
`eligible`	Yes
`operation`	Yes
`schemaVersion`	Yes
`paymentMethods`	Yes
`canonicalRequest`	Yes
`disclosureBoundary`	Yes

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds meaningful behavior beyond those: it 'validates applicability without revealing the filing value, comparison source value, later revision values, evidence, or arithmetic.' This tells the agent the tool intentionally withholds sensitive outputs, which is critical for setting expectations. It also states the operation is free, a useful cost signal. No contradiction with annotations.

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

Conciseness5/5

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

Three sentences, each earning its place: the first defines the tool, the second details when to use it and what it withholds, the third routes to alternatives. It is front-loaded with the core purpose and uses a compact list to avoid vague prose. No filler or repetition.

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

Completeness4/5

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

For a tool with 12 parameters and an output schema, the description covers the essential operational context: relationship to the paid reconcile operation, the uncertainty triggers, the privacy behavior, and sibling routing. It doesn't explicitly state what the eligibility result looks like, but the output schema already covers return values. A slight gap is not defining 'eligibility' precisely (e.g., what a true/false result means for downstream calls), which would push it to a 5.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3 per the rubric. The description indirectly references the parameter categories ('issuer identity, filing selection, supported metric, fiscal-period dates, annual-versus-quarter context, required SEC Company Facts contexts, or an optional SEC-filed 8-K earnings-release number comparison') which map to identifier/cik, anchor_accession, metric, period_start/end, period_type, and comparison_* fields. However, it adds no concrete semantics beyond what the schema already documents for individual parameters.

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

Purpose5/5

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

States a specific verb and resource: it is a 'Free eligibility check for filedproof.reconcile_financial_fact', which clearly identifies it as a prerequisite validation step for a named specialist operation. It also distinguishes itself from siblings by naming alternative tools (resolve_issuer, list_filings, search_evidence) for different use cases. An agent can tell exactly what this tool is for without needing to open other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent when to invoke it: 'Use this before the $1 specialist operation when ... may be uncertain', and enumerates the specific uncertainty dimensions (issuer identity, filing selection, metric, dates, period type, SEC contexts, 8-K comparison). It also gives clear exclusions: 'For general filing lookup or narrative research, use ... instead.' This is model guidance for tool selection.

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

filedproof.reconcile_financial_factReconcile one SEC financial factA

Read-onlyIdempotent

Inspect

$1.00 USD specialist operation when commerce is active. Use this for one supported quarterly or fiscal-year revenue, net income, or operating cash flow fact. Optionally provide comparison_accession plus comparison_value to verify that number against an SEC-filed 8-K earnings-release exhibit and assess GAAP/non-GAAP, period, currency, and scope comparability. Arithmetic bridges are returned only when visible source rows reproduce exactly; otherwise the reason remains unresolved. Use filedproof.preflight_financial_fact first when eligibility is uncertain, filedproof.verify_claim for a narrative factual proposition, or filedproof.search_evidence for general filing research. Unsupported or ambiguous requests abstain before payment.

ParametersJSON Schema

Name	Required	Description	Default
`cik`	No	Legacy/direct SEC CIK input. Prefer identifier when starting from a ticker or company name.
`metric`	Yes	Financial metric to reconcile: revenue, net income, or operating cash flow.
`as_of_date`	No	Optional historical cutoff. The selected anchor filing must have been filed on or before this date; later values never replace the primary answer.
`identifier`	No	Issuer ticker, exact company name, CIK, or CIK-prefixed identifier. FiledProof resolves this to the durable SEC CIK before research and payment.
`period_end`	Yes	Requested fiscal-period end date.
`period_type`	No	Whether the requested value is one standalone fiscal quarter or the full fiscal year.	standalone_fiscal_quarter
`period_start`	Yes	Requested fiscal-period start date.
`anchor_accession`	No	Optional 10-Q/10-K accession, including amendments. If omitted, FiledProof selects the earliest compatible filing for the requested period.
`comparison_value`	No	Actual-unit integer value claimed from the SEC-filed earnings-release exhibit. FiledProof must find this value in metric context before the comparison is eligible.
`comparison_exhibit`	No	Optional exact EX-99 exhibit filename or safe relative path when an 8-K contains multiple candidate earnings-release exhibits.
`comparison_accession`	No	Optional SEC 8-K/8-K/A accession containing an earnings-release exhibit to compare with the filing-anchored GAAP fact. Provide comparison_value with it.
`include_subsequent_revisions`	No	When true, report later different values for the same SEC concept, unit, and period separately from the primary anchored value.

Output Schema

ParametersJSON Schema

Name	Required	Description
`asOf`	Yes
`scale`	No
`scope`	Yes
`units`	No
`value`	Yes
`issuer`	Yes
`period`	Yes
`source`	Yes
`status`	Yes
`currency`	Yes
`evidence`	Yes
`resultId`	Yes
`operation`	Yes
`derivation`	Yes
`validation`	Yes
`limitations`	Yes
`resultBasis`	Yes
`anchorFiling`	Yes
`schemaVersion`	Yes
`resolvedMetric`	Yes
`canonicalRequest`	Yes
`originalReported`	Yes
`revisionAssessment`	Yes
`unresolvedQuestions`	Yes
`numberReconciliation`	No
`subsequentReportedValues`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnly, openWorld, idempotent), the description discloses the $1.00 USD cost when commerce is active, the condition that arithmetic bridges appear only when visible source rows reproduce exactly, and that unsupported requests abstain before payment. These are meaningful behavioral details not present in annotations.

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

Conciseness5/5

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

Five sentences, front-loaded with purpose and cost, then usage, limitation, and alternatives. Every sentence carries essential information with no filler or redundant restatement.

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

Completeness5/5

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

Given the tool's complexity (12 params, output schema), the description covers purpose, usage, limitations, cost, and alternatives. An output schema exists, so return values need not be described. Nothing essential for correct selection or invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds context for comparison_accession and comparison_value and mentions anchor filing selection, but it does not materially change parameter understanding beyond the schema's own descriptions.

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

Purpose5/5

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

States the specific verb 'Reconcile' with resource 'one SEC financial fact' and defines supported metrics (revenue, net income, operating cash flow) and period types. Explicitly distinguishes from siblings by naming preflight, verify_claim, and search_evidence as alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance ('Use this for one supported...'), when-to-use alternatives ('Use filedproof.preflight_financial_fact first when eligibility is uncertain...'), and describes the optional comparison flow. Also states the abstention rule for unsupported or ambiguous requests.

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

filedproof.resolve_issuerResolve public company issuerA

Read-onlyIdempotent

Inspect

Resolve a ticker, CIK, or exact company name to one SEC issuer. Use this first when issuer identity is uncertain or before passing a CIK or accession into another FiledProof tool. Do not use it to list filings or search disclosure text; use filedproof.list_filings or filedproof.search_evidence after identity is resolved.

ParametersJSON Schema

Name	Required	Description	Default
`identifier`	Yes	Ticker, CIK, or exact SEC company name.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds the behavioral nuance that resolution maps to a single SEC issuer ('to one SEC issuer') and clarifies the scope of acceptable inputs. It does not contradict any annotation and the additional context is concise and meaningful.

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

Conciseness5/5

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

Three sentences, each earning its place: the first defines the operation, the second states when to use it, and the third explicitly routes the agent to alternatives for other tasks. The most important distinction is front-loaded, and there is no redundant phrasing.

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

Completeness5/5

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

For a single-parameter, read-only, idempotent resolver with a fully described schema and an output schema present, the description covers everything an agent needs: what it does, when to use it, what not to use it for, and where to go next. The sibling list and annotations complete the remaining context, so nothing critical is missing.

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

Parameters3/5

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

Schema description coverage is 100%, and the single parameter 'identifier' is already documented as 'Ticker, CIK, or exact SEC company name.' The tool description repeats those same identifier types, adding little beyond the schema. There is no additional parameter-level detail like formatting or normalization examples, so the baseline of 3 is appropriate.

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

Purpose5/5

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

The description begins with a specific verb and resource: 'Resolve a ticker, CIK, or exact company name to one SEC issuer.' It clearly distinguishes this tool from siblings by explicitly stating it is not for listing filings or searching disclosure text, and names the sibling tools that handle those cases. The purpose is unambiguous and contrasts well with the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'Use this first when issuer identity is uncertain or before passing a CIK or accession into another FiledProof tool.' It also provides a clear exclusion: 'Do not use it to list filings or search disclosure text; use filedproof.list_filings or filedproof.search_evidence after identity is resolved.' This fully equips an agent to choose between this and alternatives.

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

filedproof.search_evidenceSearch filing evidenceA

Read-onlyIdempotent

Inspect

Find relevant primary-source passages across a bounded set of SEC filings. Use this for open-ended filing research when you want evidence records with provenance but do not need a claim verdict or a curated answer bundle. Use filedproof.verify_claim for one explicit factual proposition, filedproof.build_evidence_pack for a compact answer-ready bundle, or filedproof.build_timeline when chronology is the main objective. Relevance is not a truth verdict.

ParametersJSON Schema

Name	Required	Description
`q`	Yes	Research question or disclosure topic.
`item`	No	Optional SEC filing item, such as 1A or 7.
`forms`	No	SEC forms to search. Defaults to 10-K and 10-Q.
`limit`	No	Maximum number of operation-specific evidence or result records to return.
`filings`	No	Maximum number of filings to inspect for this invocation.
`history`	No	Whether to use bounded historical SEC submission archives when needed.
`section`	No	Optional exact normalized section heading.
`identifier`	Yes	Ticker, CIK, or exact SEC company name.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear without the description. The description adds useful context: the search is over a 'bounded set' of filings and that relevance is not a truth judgment. It does not contradict any annotation, and the extra caveat enriches behavioral understanding beyond what annotations alone provide.

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

Conciseness5/5

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

The description is four sentences with zero waste. The core purpose is front-loaded in the first sentence, followed by same-sentence scoping, then a compact list of alternatives, and a final one-line caveat. Every sentence earns its place, and there is no redundant rephrasing of the tool name or title.

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

Completeness5/5

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

Given an output schema exists (so return format is handled separately) and the schema fully documents all 8 parameters, the description covers the remaining operational context: purpose, scope (bounded set), what it does NOT return, and routing to siblings. Nothing an agent needs to decide when to call it or how to frame a query is missing.

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

Parameters3/5

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

Schema description coverage is 100% – every one of the 8 parameters has a detailed description in the schema (e.g., 'Research question or disclosure topic', 'Optional SEC filing item, such as 1A or 7'). The tool description itself adds no per-parameter meaning; it only frames the overall operation. Per the high-coverage baseline, a 3 is appropriate; the description does not need to repeat what the schema already documents.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Find relevant primary-source passages across a bounded set of SEC filings.' It immediately differentiates itself from siblings by stating it returns 'evidence records with provenance' but not a claim verdict or curated bundle, and it names three alternative tools with distinct purposes. This makes the tool's intent unambiguous and distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is explicit and actionable: it lists exactly when to use this tool versus filedproof.verify_claim, filedproof.build_evidence_pack, and filedproof.build_timeline. It also adds a critical caveat, 'Relevance is not a truth verdict,' which prevents misinterpretation. No agent needs to infer when to call it.

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

filedproof.verify_claimVerify a claim against SEC filingsA

Read-onlyIdempotent

Inspect

Conservatively assess one explicit factual claim against official SEC filing evidence and return support, contradiction, mixed, partial, or insufficient-evidence stance signals. Use this when the caller already has a proposition to test. Use filedproof.search_evidence for open-ended research, filedproof.reconcile_financial_fact for one supported standalone-quarter revenue, net-income, or operating-cash-flow value, or filedproof.check_disclosure_changes for new disclosure-change monitoring. A filing establishes what the company reported, not independent real-world truth.

ParametersJSON Schema

Name	Required	Description
`item`	No	Optional SEC filing item such as 1A or 7.
`claim`	Yes	The factual claim to assess against the company's SEC filings.
`forms`	No	SEC forms to search. Defaults to 10-K, 10-Q, and 8-K.
`limit`	No	Maximum number of operation-specific evidence or result records to return.
`filings`	No	Maximum number of filings to inspect for this invocation.
`history`	No	Whether to use bounded historical SEC submission archives when needed.
`section`	No	Optional exact normalized section heading.
`identifier`	Yes	Ticker, CIK, or exact SEC company name.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context about the conservative assessment approach and the epistemic limitation (a filing is what the company reported, not independent real-world truth). This goes beyond the annotations, though it doesn't detail specifics like rate limits or caching.

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

Conciseness5/5

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

The description is compact but information-dense. It front-loads the primary purpose and stance signals, then provides sibling distinctions in a single sentence, and ends with a crucial epistemic caveat. Every sentence earns its place, with no redundancy.

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

Completeness5/5

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

The tool is complex (8 params, output schema, 11 siblings), but the description covers all essential aspects: the claim to test, the evidence basis, the possible stance outputs, usage context, and sibling differentiations. With an output schema present, the description doesn't need to explain return values. Nothing critical is missing for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so all 8 parameters are individually documented. The description adds meaning by framing the core parameter 'claim' as an 'explicit factual claim' to test, which reinforces its purpose, though it doesn't add syntax or format details beyond what the schema provides. With full schema coverage, the baseline is 3, and the added framing justifies a 4.

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

Purpose5/5

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

The description states a specific verb ('assess'), a specific resource ('explicit factual claim against official SEC filing evidence'), and enumerates the exact stance signals returned. It also distinguishes the tool from several siblings by naming them and their purposes, making the tool's unique role clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the condition for use ('when the caller already has a proposition to test') and provides direct alternatives for other scenarios (open-ended research, reconciling standalone financial facts, and monitoring disclosure changes). This gives clear when-to-use and when-not-to-use guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 25, 2026
- Addedfiledproof.check_material_filing_changes

2 tool updatesSep 24, 2026

Changedfiledproof.preflight_financial_fact6 fields changed

addedInput schema / properties / comparison_accession

Added value: +{
+  "description": "Optional SEC 8-K/8-K/A accession containing an earnings-release exhibit to compare with the filing-anchored GAAP fact. Provide comparison_value with it.",
+  "pattern": "^\\d{10}-\\d{2}-\\d{6}$",
+  "type": "string"
+}

addedInput schema / properties / comparison_exhibit

Added value: +{
+  "description": "Optional exact EX-99 exhibit filename or safe relative path when an 8-K contains multiple candidate earnings-release exhibits.",
+  "maxLength": 240,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / comparison_value

Added value: +{
+  "description": "Actual-unit integer value claimed from the SEC-filed earnings-release exhibit. FiledProof must find this value in metric context before the comparison is eligible.",
+  "pattern": "^-?\\d+$",
+  "type": "string"
+}

addedOutput schema / properties / checks / properties / comparisonRequested
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / checks / properties / comparisonSourceAvailable
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / properties / checks / required

Previous value: -[
-  "issuerValid",
-  "anchorFilingValid",
-  "metricSupported",
-  "requestedPeriodPlausible",
-  "requiredContextDataAvailable"
-]New value: +[
+  "issuerValid",
+  "anchorFilingValid",
+  "metricSupported",
+  "requestedPeriodPlausible",
+  "comparisonRequested",
+  "comparisonSourceAvailable",
+  "requiredContextDataAvailable"
+]

Changedfiledproof.reconcile_financial_fact4 fields changed

addedInput schema / properties / comparison_accession

Added value: +{
+  "description": "Optional SEC 8-K/8-K/A accession containing an earnings-release exhibit to compare with the filing-anchored GAAP fact. Provide comparison_value with it.",
+  "pattern": "^\\d{10}-\\d{2}-\\d{6}$",
+  "type": "string"
+}

addedInput schema / properties / comparison_exhibit

Added value: +{
+  "description": "Optional exact EX-99 exhibit filename or safe relative path when an 8-K contains multiple candidate earnings-release exhibits.",
+  "maxLength": 240,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / comparison_value

Added value: +{
+  "description": "Actual-unit integer value claimed from the SEC-filed earnings-release exhibit. FiledProof must find this value in metric context before the comparison is eligible.",
+  "pattern": "^-?\\d+$",
+  "type": "string"
+}

addedOutput schema / properties / numberReconciliation

Added value: +{
+  "type": [
+    "object",
+    "null"
+  ]
+}

1 tool updateSep 24, 2026

Changedfiledproof.check_disclosure_changes6 fields changed

addedInput schema / oneOf

Added value: +[
+  {
+    "required": [
+      "topic"
+    ]
+  },
+  {
+    "required": [
+      "profile"
+    ]
+  }
+]

addedInput schema / properties / profile

Added value: +{
+  "description": "Bounded report profile. financial_risk checks liquidity/capital resources, debt/borrowings/covenants/maturities, dilution/equity-issuance disclosures, and changed risk disclosures together. Provide profile or topic, not both.",
+  "enum": [
+    "financial_risk"
+  ],
+  "type": "string"
+}

changedInput schema / properties / topic / description

Previous value: -"Disclosure topic to monitor, such as AI capital spending, China risk, or cybersecurity."New value: +"Disclosure topic to monitor, such as AI capital spending, China risk, or cybersecurity. Provide topic or profile, not both."

changedInput schema / required

Previous value: -[
-  "identifier",
-  "topic"
-]New value: +[
+  "identifier"
+]

changedOutput schema / properties / events / items / properties / change / oneOf

Previous value: -[
-  {
-    "type": "null"
-  },
-  {
-    "additionalProperties": true,
-    "properties": {
-      "attentionCounts": {
-        "additionalProperties": false,
-        "properties": {
-          "high": {
-            "minimum": 0,
-            "type": "integer"
-          },
-          "low": {
-            "minimum": 0,
-            "type": "integer"
-          },
-          "medium": {
-            "minimum": 0,
-            "type": "integer"
-          }
-        },
-        "required": [
-          "high",
-          "medium",
-          "low"
-        ],
-        "type": "object"
-      },
-      "changeCount": {
-        "minimum": 0,
-        "type": "integer"
-      },
-      "changed": {
-        "type": "boolean"
-      },
-      "changes": {
-        "items": {
-          "additionalProperties": true,
-          "properties": {
-            "after": {
-              "additionalProperties": true,
-              "type": [
-                "object",
-                "null"
-              ]
-            },
-            "attention": {
-              "additionalProperties": true,
-              "properties": {
-                "level": {
-                  "enum": [
-                    "high",
-                    "medium",
-                    "low"
-                  ],
-                  "type": "string"
-                },
-                "score": {
-                  "type": "number"
-                }
-              },
-              "required": [
-                "level",
-                "score"
-              ],
-              "type": "object"
-            },
-            "before": {
-              "additionalProperties": true,
-              "type": [
-                "object",
-                "null"
-              ]
-            },
-            "category": {
-              "minLength": 1,
-              "type": "string"
-            },
-            "confidence": {
-              "enum": [
-                "high",
-                "medium",
-                "low"
-              ],
-              "type": "string"
-            },
-            "kind": {
-              "enum": [
-                "addition",
-                "removal",
-                "revised_disclosure",
-                "moved_equivalent"
-              ],
-              "type": "string"
-            },
-            "signals": {
-              "items": {
-                "type": "string"
-              },
-              "type": "array"
-            }
-          },
-          "required": [
-            "kind",
-            "category",
-            "attention",
-            "confidence",
-            "signals",
-            "before",
-            "after"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "highPriorityChangeCount": {
-        "minimum": 0,
-        "type": "integer"
-      },
-      "limitations": {
-        "items": {
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "overallAttention": {
-        "enum": [
-          "high",
-          "medium",
-          "low",
-          "none"
-        ],
-        "type": "string"
-      },
-      "schemaVersion": {
-        "const": "disclosure-change.v1"
-      }
-    },
-    "required": [
-      "schemaVersion",
-      "changed",
-      "changes"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "type": "null"
+  },
+  {
+    "additionalProperties": true,
+    "properties": {
+      "attentionCounts": {
+        "additionalProperties": false,
+        "properties": {
+          "high": {
+            "minimum": 0,
+            "type": "integer"
+          },
+          "low": {
+            "minimum": 0,
+            "type": "integer"
+          },
+          "medium": {
+            "minimum": 0,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "high",
+          "medium",
+          "low"
+        ],
+        "type": "object"
+      },
+      "changeCount": {
+        "minimum": 0,
+        "type": "integer"
+      },
+      "changed": {
+        "type": "boolean"
+      },
+      "changes": {
+        "items": {
+          "additionalProperties": true,
+          "properties": {
+            "after": {
+              "additionalProperties": true,
+              "type": [
+                "object",
+                "null"
+              ]
+            },
+            "attention": {
+              "additionalProperties": true,
+              "properties": {
+                "level": {
+                  "enum": [
+                    "high",
+                    "medium",
+                    "low"
+                  ],
+                  "type": "string"
+                },
+                "score": {
+                  "type": "number"
+                }
+              },
+              "required": [
+                "level",
+                "score"
+              ],
+              "type": "object"
+            },
+            "before": {
+              "additionalProperties": true,
+              "type": [
+                "object",
+                "null"
+              ]
+            },
+            "category": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "classification": {
+              "additionalProperties": true,
+              "type": "object"
+            },
+            "confidence": {
+              "enum": [
+                "high",
+                "medium",
+                "low"
+              ],
+              "type": "string"
+            },
+            "coverageCategories": {
+              "items": {
+                "type": "string"
+              },
+              "type": "array"
+            },
+            "kind": {
+              "enum": [
+                "addition",
+                "removal",
+                "revised_disclosure",
+                "moved_equivalent"
+              ],
+              "type": "string"
+            },
+            "numericAnchors": {
+              "additionalProperties": true,
+              "type": "object"
+            },
+            "reportingContext": {
+              "additionalProperties": true,
+              "type": [
+                "object",
+                "null"
+              ]
+            },
+            "signals": {
+              "items": {
+                "oneOf": [
+                  {
+                    "type": "string"
+                  },
+                  {
+                    "additionalProperties": true,
+                    "type": "object"
+                  }
+                ]
+              },
+              "type": "array"
+            }
+          },
+          "required": [
+            "kind",
+            "category",
+            "attention",
+            "confidence",
+            "signals",
+            "before",
+            "after"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "coverage": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "highPriorityChangeCount": {
+        "minimum": 0,
+        "type": "integer"
+      },
+      "limitations": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "overallAttention": {
+        "enum": [
+          "high",
+          "medium",
+          "low",
+          "none"
+        ],
+        "type": "string"
+      },
+      "reportProfile": {
+        "type": "string"
+      },
+      "schemaVersion": {
+        "const": "disclosure-change.v1"
+      }
+    },
+    "required": [
+      "schemaVersion",
+      "changed",
+      "changes"
+    ],
+    "type": "object"
+  }
+]

addedOutput schema / properties / reportProfile

Added value: +{
+  "enum": [
+    "financial_risk",
+    null
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

2 tool updatesSep 24, 2026

Changedfiledproof.preflight_financial_fact10 fields changed

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "identifier"
+    ]
+  },
+  {
+    "required": [
+      "cik"
+    ]
+  }
+]

changedInput schema / properties / anchor_accession / description

Previous value: -"One non-amended 10-Q or 10-K accession that anchors the requested fiscal quarter."New value: +"Optional 10-Q/10-K accession, including amendments. If omitted, FiledProof selects the earliest compatible filing for the requested period."

addedInput schema / properties / as_of_date

Added value: +{
+  "description": "Optional historical cutoff. The selected anchor filing must have been filed on or before this date; later values never replace the primary answer.",
+  "format": "date",
+  "type": "string"
+}

changedInput schema / properties / cik / description

Previous value: -"SEC Central Index Key for one issuer."New value: +"Legacy/direct SEC CIK input. Prefer identifier when starting from a ticker or company name."

addedInput schema / properties / identifier

Added value: +{
+  "description": "Issuer ticker, exact company name, CIK, or CIK-prefixed identifier. FiledProof resolves this to the durable SEC CIK before research and payment.",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / include_subsequent_revisions

Added value: +{
+  "default": true,
+  "description": "When true, report later different values for the same SEC concept, unit, and period separately from the primary anchored value.",
+  "type": "boolean"
+}

changedInput schema / properties / period_end / description

Previous value: -"Standalone fiscal-quarter end date."New value: +"Requested fiscal-period end date."

changedInput schema / properties / period_start / description

Previous value: -"Standalone fiscal-quarter start date."New value: +"Requested fiscal-period start date."

addedInput schema / properties / period_type

Added value: +{
+  "default": "standalone_fiscal_quarter",
+  "description": "Whether the requested value is one standalone fiscal quarter or the full fiscal year.",
+  "enum": [
+    "standalone_fiscal_quarter",
+    "fiscal_year"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "cik",
-  "anchor_accession",
-  "metric",
-  "period_start",
-  "period_end"
-]New value: +[
+  "metric",
+  "period_start",
+  "period_end"
+]

Changedfiledproof.reconcile_financial_fact19 fields changed

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "identifier"
+    ]
+  },
+  {
+    "required": [
+      "cik"
+    ]
+  }
+]

changedInput schema / properties / anchor_accession / description

Previous value: -"One non-amended 10-Q or 10-K accession that anchors the requested fiscal quarter."New value: +"Optional 10-Q/10-K accession, including amendments. If omitted, FiledProof selects the earliest compatible filing for the requested period."

addedInput schema / properties / as_of_date

Added value: +{
+  "description": "Optional historical cutoff. The selected anchor filing must have been filed on or before this date; later values never replace the primary answer.",
+  "format": "date",
+  "type": "string"
+}

changedInput schema / properties / cik / description

Previous value: -"SEC Central Index Key for one issuer."New value: +"Legacy/direct SEC CIK input. Prefer identifier when starting from a ticker or company name."

addedInput schema / properties / identifier

Added value: +{
+  "description": "Issuer ticker, exact company name, CIK, or CIK-prefixed identifier. FiledProof resolves this to the durable SEC CIK before research and payment.",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / include_subsequent_revisions

Added value: +{
+  "default": true,
+  "description": "When true, report later different values for the same SEC concept, unit, and period separately from the primary anchored value.",
+  "type": "boolean"
+}

changedInput schema / properties / period_end / description

Previous value: -"Standalone fiscal-quarter end date."New value: +"Requested fiscal-period end date."

changedInput schema / properties / period_start / description

Previous value: -"Standalone fiscal-quarter start date."New value: +"Requested fiscal-period start date."

addedInput schema / properties / period_type

Added value: +{
+  "default": "standalone_fiscal_quarter",
+  "description": "Whether the requested value is one standalone fiscal quarter or the full fiscal year.",
+  "enum": [
+    "standalone_fiscal_quarter",
+    "fiscal_year"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "cik",
-  "anchor_accession",
-  "metric",
-  "period_start",
-  "period_end"
-]New value: +[
+  "metric",
+  "period_start",
+  "period_end"
+]

addedOutput schema / properties / asOf
```
Added value: +{
+  "type": "object"
+}
```
addedOutput schema / properties / issuer
```
Added value: +{
+  "type": "object"
+}
```

addedOutput schema / properties / originalReported

Added value: +{
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / revisionAssessment
```
Added value: +{
+  "type": "object"
+}
```

addedOutput schema / properties / scale

Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}

addedOutput schema / properties / subsequentReportedValues
```
Added value: +{
+  "type": "array"
+}
```

addedOutput schema / properties / units

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / unresolvedQuestions

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "schemaVersion",
-  "operation",
-  "resultId",
-  "status",
-  "canonicalRequest",
-  "resolvedMetric",
-  "period",
-  "scope",
-  "source",
-  "anchorFiling",
-  "value",
-  "currency",
-  "resultBasis",
-  "derivation",
-  "evidence",
-  "validation",
-  "limitations"
-]New value: +[
+  "schemaVersion",
+  "operation",
+  "resultId",
+  "status",
+  "canonicalRequest",
+  "issuer",
+  "resolvedMetric",
+  "period",
+  "asOf",
+  "scope",
+  "source",
+  "anchorFiling",
+  "value",
+  "currency",
+  "resultBasis",
+  "derivation",
+  "evidence",
+  "originalReported",
+  "subsequentReportedValues",
+  "revisionAssessment",
+  "validation",
+  "limitations",
+  "unresolvedQuestions"
+]

1 tool updateSep 15, 2026

Changedfiledproof.check_disclosure_changes1 field changed

changedOutput schema / $id

Previous value: -"https://filedproof.com/schemas/monitor-check.v1"New value: +"https://filedproof.davisvillelabs.com/schemas/monitor-check.v1"

12 tool updatesSep 13, 2026

Changedfiledproof.build_disclosure_lineage1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured FiledProof result with operation-specific evidence, provenance, coverage, and uncertainty fields.",
+  "type": "object"
+}

Changedfiledproof.build_disclosure_matrix5 fields changed

addedInput schema / properties / comparisonLimit / description

Added value: +"Maximum number of changed blocks to inspect in each filing comparison."

addedInput schema / properties / fingerprintLimit / description

Added value: +"Maximum number of relevant evidence records used to fingerprint one filing."

addedInput schema / properties / history / description

Added value: +"Whether to use bounded historical SEC submission archives when needed."

addedInput schema / properties / maxArchiveFiles / description

Added value: +"Maximum number of historical SEC submission archive files to inspect when history is enabled."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured FiledProof result with operation-specific evidence, provenance, coverage, and uncertainty fields.",
+  "type": "object"
+}

Changedfiledproof.build_evidence_pack4 fields changed

addedInput schema / properties / filings / description

Added value: +"Maximum number of filings to inspect for this invocation."

addedInput schema / properties / history / description

Added value: +"Whether to use bounded historical SEC submission archives when needed."

addedInput schema / properties / limit / description

Added value: +"Maximum number of operation-specific evidence or result records to return."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured FiledProof result with operation-specific evidence, provenance, coverage, and uncertainty fields.",
+  "type": "object"
+}

Changedfiledproof.build_timeline4 fields changed

addedInput schema / properties / filings / description

Added value: +"Maximum number of filings to inspect for this invocation."

addedInput schema / properties / history / description

Added value: +"Whether to use bounded historical SEC submission archives when needed."

addedInput schema / properties / limit / description

Added value: +"Maximum number of operation-specific evidence or result records to return."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured FiledProof result with operation-specific evidence, provenance, coverage, and uncertainty fields.",
+  "type": "object"
+}

Changedfiledproof.check_disclosure_changes2 fields changed

addedInput schema / properties / comparisonLimit / description

Added value: +"Maximum number of changed blocks to inspect in each filing comparison."

addedInput schema / properties / history / description

Added value: +"Whether to use bounded historical SEC submission archives when needed."

Changedfiledproof.compare_filings2 fields changed

addedInput schema / properties / limit / description

Added value: +"Maximum number of operation-specific evidence or result records to return."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured FiledProof result with operation-specific evidence, provenance, coverage, and uncertainty fields.",
+  "type": "object"
+}

Changedfiledproof.list_filings4 fields changed

addedInput schema / properties / forms / description

Added value: +"SEC filing form types to include, such as 10-K, 10-Q, or 8-K."

addedInput schema / properties / history / description

Added value: +"Whether to use bounded historical SEC submission archives when needed."

addedInput schema / properties / limit / description

Added value: +"Maximum number of operation-specific evidence or result records to return."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured FiledProof result with operation-specific evidence, provenance, coverage, and uncertainty fields.",
+  "type": "object"
+}

Changedfiledproof.preflight_financial_fact2 fields changed

addedInput schema / properties / metric / description

Added value: +"Financial metric to reconcile: revenue, net income, or operating cash flow."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "canonicalRequest": {
+      "type": "object"
+    },
+    "checks": {
+      "additionalProperties": false,
+      "properties": {
+        "anchorFilingValid": {
+          "type": "boolean"
+        },
+        "issuerValid": {
+          "type": "boolean"
+        },
+        "metricSupported": {
+          "type": "boolean"
+        },
+        "requestedPeriodPlausible": {
+          "type": "boolean"
+        },
+        "requiredContextDataAvailable": {
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "issuerValid",
+        "anchorFilingValid",
+        "metricSupported",
+        "requestedPeriodPlausible",
+        "requiredContextDataAvailable"
+      ],
+      "type": "object"
+    },
+    "disclosureBoundary": {
+      "type": "string"
+    },
+    "eligible": {
+      "type": "boolean"
+    },
+    "operation": {
+      "const": "filedproof.reconcile_financial_fact"
+    },
+    "paymentMethods": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "price": {
+      "additionalProperties": false,
+      "properties": {
+        "cents": {
+          "minimum": 0,
+          "type": "integer"
+        },
+        "currency": {
+          "maxLength": 3,
+          "minLength": 3,
+          "type": "string"
+        }
+      },
+      "required": [
+        "cents",
+        "currency"
+      ],
+      "type": "object"
+    },
+    "reason": {
+      "type": "string"
+    },
+    "schemaVersion": {
+      "const": "financial-fact-preflight.v1"
+    },
+    "status": {
+      "enum": [
+        "eligible",
+        "ineligible"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "schemaVersion",
+    "operation",
+    "canonicalRequest",
+    "status",
+    "eligible",
+    "checks",
+    "price",
+    "paymentMethods",
+    "disclosureBoundary"
+  ],
+  "type": "object"
+}

Changedfiledproof.reconcile_financial_fact1 field changed
- addedInput schema / properties / metric / description
```
Added value: +"Financial metric to reconcile: revenue, net income, or operating cash flow."
```

Changedfiledproof.resolve_issuer1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured FiledProof result with operation-specific evidence, provenance, coverage, and uncertainty fields.",
+  "type": "object"
+}

Changedfiledproof.search_evidence4 fields changed

addedInput schema / properties / filings / description

Added value: +"Maximum number of filings to inspect for this invocation."

addedInput schema / properties / history / description

Added value: +"Whether to use bounded historical SEC submission archives when needed."

addedInput schema / properties / limit / description

Added value: +"Maximum number of operation-specific evidence or result records to return."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured FiledProof result with operation-specific evidence, provenance, coverage, and uncertainty fields.",
+  "type": "object"
+}

Changedfiledproof.verify_claim4 fields changed

addedInput schema / properties / filings / description

Added value: +"Maximum number of filings to inspect for this invocation."

addedInput schema / properties / history / description

Added value: +"Whether to use bounded historical SEC submission archives when needed."

addedInput schema / properties / limit / description

Added value: +"Maximum number of operation-specific evidence or result records to return."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured FiledProof result with operation-specific evidence, provenance, coverage, and uncertainty fields.",
+  "type": "object"
+}

2 tool updatesSep 13, 2026
- Addedfiledproof.preflight_financial_fact
- Addedfiledproof.reconcile_financial_fact

1 tool updateSep 12, 2026

Changedfiledproof.check_disclosure_changes2 fields changed

addedInput schema / properties / maxArchiveFiles

Added value: +{
+  "description": "Maximum historical SEC submission archive files to inspect when history is enabled.",
+  "maximum": 20,
+  "minimum": 1,
+  "type": "integer"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$id": "https://filedproof.com/schemas/monitor-check.v1",
+  "additionalProperties": true,
+  "properties": {
+    "agentGuidance": {
+      "additionalProperties": true,
+      "properties": {
+        "invocationBoundary": {
+          "type": "string"
+        },
+        "nextAction": {
+          "type": "string"
+        },
+        "reviewOrder": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "nextAction",
+        "invocationBoundary"
+      ],
+      "type": "object"
+    },
+    "attentionCounts": {
+      "additionalProperties": false,
+      "properties": {
+        "high": {
+          "minimum": 0,
+          "type": "integer"
+        },
+        "low": {
+          "minimum": 0,
+          "type": "integer"
+        },
+        "medium": {
+          "minimum": 0,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "high",
+        "medium",
+        "low"
+      ],
+      "type": "object"
+    },
+    "changeCount": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "changeDetected": {
+      "type": "boolean"
+    },
+    "checkpoint": {
+      "oneOf": [
+        {
+          "type": "null"
+        },
+        {
+          "additionalProperties": false,
+          "properties": {
+            "accession": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "filingDate": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "form": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "reportDate": {
+              "type": [
+                "string",
+                "null"
+              ]
+            }
+          },
+          "required": [
+            "accession",
+            "form",
+            "filingDate",
+            "reportDate"
+          ],
+          "type": "object"
+        }
+      ]
+    },
+    "events": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "baseline": {
+            "oneOf": [
+              {
+                "type": "null"
+              },
+              {
+                "additionalProperties": false,
+                "properties": {
+                  "accession": {
+                    "minLength": 1,
+                    "type": "string"
+                  },
+                  "filingDate": {
+                    "type": [
+                      "string",
+                      "null"
+                    ]
+                  },
+                  "form": {
+                    "type": [
+                      "string",
+                      "null"
+                    ]
+                  },
+                  "reportDate": {
+                    "type": [
+                      "string",
+                      "null"
+                    ]
+                  }
+                },
+                "required": [
+                  "accession",
+                  "form",
+                  "filingDate",
+                  "reportDate"
+                ],
+                "type": "object"
+              }
+            ]
+          },
+          "change": {
+            "oneOf": [
+              {
+                "type": "null"
+              },
+              {
+                "additionalProperties": true,
+                "properties": {
+                  "attentionCounts": {
+                    "additionalProperties": false,
+                    "properties": {
+                      "high": {
+                        "minimum": 0,
+                        "type": "integer"
+                      },
+                      "low": {
+                        "minimum": 0,
+                        "type": "integer"
+                      },
+                      "medium": {
+                        "minimum": 0,
+                        "type": "integer"
+                      }
+                    },
+                    "required": [
+                      "high",
+                      "medium",
+                      "low"
+                    ],
+                    "type": "object"
+                  },
+                  "changeCount": {
+                    "minimum": 0,
+                    "type": "integer"
+                  },
+                  "changed": {
+                    "type": "boolean"
+                  },
+                  "changes": {
+                    "items": {
+                      "additionalProperties": true,
+                      "properties": {
+                        "after": {
+                          "additionalProperties": true,
+                          "type": [
+                            "object",
+                            "null"
+                          ]
+                        },
+                        "attention": {
+                          "additionalProperties": true,
+                          "properties": {
+                            "level": {
+                              "enum": [
+                                "high",
+                                "medium",
+                                "low"
+                              ],
+                              "type": "string"
+                            },
+                            "score": {
+                              "type": "number"
+                            }
+                          },
+                          "required": [
+                            "level",
+                            "score"
+                          ],
+                          "type": "object"
+                        },
+                        "before": {
+                          "additionalProperties": true,
+                          "type": [
+                            "object",
+                            "null"
+                          ]
+                        },
+                        "category": {
+                          "minLength": 1,
+                          "type": "string"
+                        },
+                        "confidence": {
+                          "enum": [
+                            "high",
+                            "medium",
+                            "low"
+                          ],
+                          "type": "string"
+                        },
+                        "kind": {
+                          "enum": [
+                            "addition",
+                            "removal",
+                            "revised_disclosure",
+                            "moved_equivalent"
+                          ],
+                          "type": "string"
+                        },
+                        "signals": {
+                          "items": {
+                            "type": "string"
+                          },
+                          "type": "array"
+                        }
+                      },
+                      "required": [
+                        "kind",
+                        "category",
+                        "attention",
+                        "confidence",
+                        "signals",
+                        "before",
+                        "after"
+                      ],
+                      "type": "object"
+                    },
+                    "type": "array"
+                  },
+                  "highPriorityChangeCount": {
+                    "minimum": 0,
+                    "type": "integer"
+                  },
+                  "limitations": {
+                    "items": {
+                      "type": "string"
+                    },
+                    "type": "array"
+                  },
+                  "overallAttention": {
+                    "enum": [
+                      "high",
+                      "medium",
+                      "low",
+                      "none"
+                    ],
+                    "type": "string"
+                  },
+                  "schemaVersion": {
+                    "const": "disclosure-change.v1"
+                  }
+                },
+                "required": [
+                  "schemaVersion",
+                  "changed",
+                  "changes"
+                ],
+                "type": "object"
+              }
+            ]
+          },
+          "current": {
+            "oneOf": [
+              {
+                "type": "null"
+              },
+              {
+                "additionalProperties": false,
+                "properties": {
+                  "accession": {
+                    "minLength": 1,
+                    "type": "string"
+                  },
+                  "filingDate": {
+                    "type": [
+                      "string",
+                      "null"
+                    ]
+                  },
+                  "form": {
+                    "type": [
+                      "string",
+                      "null"
+                    ]
+                  },
+                  "reportDate": {
+                    "type": [
+                      "string",
+                      "null"
+                    ]
+                  }
+                },
+                "required": [
+                  "accession",
+                  "form",
+                  "filingDate",
+                  "reportDate"
+                ],
+                "type": "object"
+              }
+            ]
+          },
+          "error": {
+            "additionalProperties": true,
+            "properties": {
+              "code": {
+                "type": "string"
+              },
+              "message": {
+                "type": "string"
+              },
+              "retryable": {
+                "type": "boolean"
+              }
+            },
+            "required": [
+              "code",
+              "message",
+              "retryable"
+            ],
+            "type": "object"
+          },
+          "limitation": {
+            "type": "string"
+          },
+          "schemaVersion": {
+            "const": "monitor-event.v1"
+          },
+          "searchScope": {
+            "additionalProperties": true,
+            "type": "object"
+          },
+          "status": {
+            "enum": [
+              "topic_change_detected",
+              "no_detected_topic_change",
+              "insufficient_baseline",
+              "comparison_failed"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "schemaVersion",
+          "status",
+          "current",
+          "baseline",
+          "change"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "forms": {
+      "items": {
+        "type": "string"
+      },
+      "minItems": 1,
+      "type": "array"
+    },
+    "haltedOnFailure": {
+      "type": "boolean"
+    },
+    "highPriorityChangeCount": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "issuer": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "latestAvailable": {
+      "oneOf": [
+        {
+          "type": "null"
+        },
+        {
+          "additionalProperties": false,
+          "properties": {
+            "accession": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "filingDate": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "form": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "reportDate": {
+              "type": [
+                "string",
+                "null"
+              ]
+            }
+          },
+          "required": [
+            "accession",
+            "form",
+            "filingDate",
+            "reportDate"
+          ],
+          "type": "object"
+        }
+      ]
+    },
+    "limitations": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "mode": {
+      "enum": [
+        "initial_snapshot",
+        "incremental"
+      ],
+      "type": "string"
+    },
+    "newFilingsDetected": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "overallAttention": {
+      "enum": [
+        "high",
+        "medium",
+        "low",
+        "none"
+      ],
+      "type": "string"
+    },
+    "priorCheckpoint": {
+      "oneOf": [
+        {
+          "type": "null"
+        },
+        {
+          "additionalProperties": false,
+          "properties": {
+            "accession": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "filingDate": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "form": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "reportDate": {
+              "type": [
+                "string",
+                "null"
+              ]
+            }
+          },
+          "required": [
+            "accession",
+            "form",
+            "filingDate",
+            "reportDate"
+          ],
+          "type": "object"
+        }
+      ]
+    },
+    "purpose": {
+      "type": "string"
+    },
+    "remainingNewFilings": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "schemaVersion": {
+      "const": "monitor-check.v1"
+    },
+    "scope": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "status": {
+      "enum": [
+        "no_new_filing",
+        "checked",
+        "change_detected",
+        "partial_failure"
+      ],
+      "type": "string"
+    },
+    "topic": {
+      "minLength": 1,
+      "type": "string"
+    },
+    "truncated": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "schemaVersion",
+    "purpose",
+    "issuer",
+    "topic",
+    "forms",
+    "mode",
+    "status",
+    "changeDetected",
+    "checkpoint",
+    "priorCheckpoint",
+    "latestAvailable",
+    "newFilingsDetected",
+    "events",
+    "truncated",
+    "remainingNewFilings",
+    "haltedOnFailure",
+    "changeCount",
+    "highPriorityChangeCount",
+    "overallAttention",
+    "attentionCounts",
+    "scope",
+    "agentGuidance"
+  ],
+  "type": "object"
+}

2 tool updatesSep 12, 2026

Changedfiledproof.check_disclosure_changes1 field changed

changedInput schema / properties / sinceAccession / description

Previous value: -"Checkpoint accession returned by the previous check. Omit for the first snapshot."New value: +"Checkpoint accession returned by the previous paid check. Omit for the first snapshot."

Removedfiledproof.scan_disclosure_changes

11 tool updatesSep 11, 2026
- First observedfiledproof.build_disclosure_lineage
- First observedfiledproof.build_disclosure_matrix
- First observedfiledproof.build_evidence_pack
- First observedfiledproof.build_timeline
- First observedfiledproof.check_disclosure_changes
- First observedfiledproof.compare_filings
- First observedfiledproof.list_filings
- First observedfiledproof.resolve_issuer
- First observedfiledproof.scan_disclosure_changes
- First observedfiledproof.search_evidence
- First observedfiledproof.verify_claim

Related MCP Connectors

FiledProof A
com.davisvillelabs.filedproof
Primary-source SEC filing intelligence and financial/disclosure reconciliation for AI agents.
Finance Government Data Research & Data
131
Calera FINSEC — Certified SEC Memory A
io.github.CaseyYahbara
Certified SEC EDGAR fact memory for AI agents with zero hallucination and filing provenance.
Finance Government Data
72
arkolith AOAuth
io.github.wikatar
Evidence-backed capital-change intelligence and sourced financial data for AI agents
Finance Government Data
2
ticker-scout A
ai.tickerscout
Agent-native SEC filing data: statements assembled, filings read and synthesized. No API key.
Finance Open Data
61

Related MCP Servers

veris
Browser Automation Web Scraping Finance
jakeyoung1
A
license
A
quality
B
maintenance
Provenance-first web access for AI agents, delivering clean content with verifiable source metadata and SEC EDGAR financial data.
Updated 8 days ago (2026-09-24 23:08 UTC)
8
41 npm
MIT
Signal8 MCP Serverofficial
Finance Research & Data Legal & Compliance
signal8ai
A
license
A
quality
D
maintenance
Provides AI agents with direct access to SEC filing intelligence, company fundamentals, dilution risk scoring, and cross-company analytics for financial research.
Updated 9 days ago (2026-09-23 15:39 UTC)
101
434 npm
1
MIT
aether-developer
Finance Search RAG Systems
EvidInvest
A
license
Not graded
quality
B
maintenance
Enables agents to search SEC filings, earnings transcripts, and EU regulations with ready-to-cite evidence, including exact passages and source links.
Updated 21 days ago (2026-09-11 19:50 UTC)
Apache 2.0
earningsprism-mcp
Finance Research & Data Search
investmentchacha-wq
A
license
Not graded
quality
D
maintenance
Real-time AI-summarised SEC filing intelligence for Claude, Cursor, and any MCP-compatible AI client.
Updated 3 months ago (2026-07-05 04:47 UTC)
MIT