FiledProof

Build cross-company disclosure matrix

filedproof.build_disclosure_matrix

Read-onlyIdempotent

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.

Input Schema

TableJSON 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

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 13, 2026

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"
+}

First observedSep 11, 2026

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.

All FiledProof tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?