Filings Read as a Step, Not as a Separate Search
This connector is not prebuilt. It would be reached from a workflow over HTTP, and what an engagement scopes is the step rather than a connector, because EDGAR is a public database with no credential to negotiate. EDGAR is the SEC's public record of company filings and disclosures, and the reason to reach it from inside a workflow is that due diligence otherwise means someone searching separately and pasting a result back, which is where the audit trail breaks.
How it connects
There is no dedicated EDGAR node. The HTTP Request node would call the EDGAR interface as a step in a workflow, so a filing lookup happens where the rest of the work happens. The node is a workflow step with its settings fixed at design time, not a tool the model calls, so where not every run needs a lookup, an IF or Switch node would route only the runs that do.
A community MCP server for EDGAR exists, published by third parties rather than by the SEC. The platform connects to MCP servers as a client, so such a server is technically reachable, but the SEC does not publish or support it, and it would be assessed on its own terms in an engagement rather than treated as a shipped path. For a public HTTP interface the direct call is usually the simpler answer anyway.
Because the source is public, the care goes elsewhere. An answer that mixes filings with an organization's own material must not leak the private half, and retrieval from the library runs under the asking user's identity with their access list pre-filtered, which is what prevents that. Whatever access conditions the SEC sets would apply to what the workflow does, and an engagement would set the request pattern accordingly.
What you can do together
- Look up a company's filings as a step inside a due diligence workflow, so the result is part of the record rather than pasted in.
- Ask a question that reaches filings and your own case or contract material at once, each source cited.
- Run the lookup only on the branch of a workflow that needs it, rather than on every run.
- Keep the private half of an answer scoped to the person asking, even when the public half is open to everyone.
A scenario
- ScopingThe engagement would agree the request pattern against EDGAR and which workflows include the step.
- SetupAn HTTP Request node would be configured against the EDGAR interface within the diligence workflow.
- A screeningThe workflow would look up the counterparty's filings and gather them alongside the contracts and recorded calls already in the library.
- The answerAn analyst would ask what the filings say about a subsidiary and get an answer citing the filing and the internal material, the internal half scoped to what the analyst may see.
- The recordThe lookup would be part of the workflow run rather than a browser tab, so the diligence would be reproducible.
What stays where
EDGAR remains the public record
Filings would be read from it and not copied in, so a citation points at the authoritative document.
No credential is involved, so the care is on the other side
Library retrieval runs as the asking user, which keeps private material out of an otherwise public answer.
The community MCP server is not a shipped path
One exists but the SEC does not run it, so it would be assessed rather than assumed.
Processing runs where you deploy the platform
Reaching a public interface needs an outbound network path, which an air-gapped deployment does not have.
Products and solutions
Next step
See it on your own SEC EDGAR instance. We will show the connection made, the data moving and the output, then size it for your deployment.
Request a demonstration or write to sales@vidizmo.ai
sales@vidizmo.ai · vidizmo.ai/integrations/catalog/sec-edgar