A Docket Lookup Inside the Workflow
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. PACER is the US federal judiciary's public access system for case dockets and filings. Reaching it from inside a workflow means a case lookup happens as part of the process rather than someone searching manually and pasting the result, which is where a reproducible record usually breaks down.
How it connects
There is no dedicated PACER node. The HTTP Request node would call PACER as a step in a workflow, with its settings fixed at design time, and an IF or Switch node would route to it only the runs that need a docket. What an engagement settles first is not technical: the terms of the PACER account the workflow uses, including any fees, make the request pattern a cost decision as much as a design one, and it belongs in scope before anything is built.
On MCP the honest position is narrow. PACER itself publishes no MCP server. What exists are third-party gateways that expose court records over MCP. The platform could reach one as a client, but that is a broker between you and the record rather than the judiciary's own interface, and an engagement would weigh that against calling PACER directly. Where CourtListener's docket holdings answer the question, the CourtListener connection is the better-founded route, because CourtListener publishes its own MCP server.
Nothing would be written back. PACER would be a read source, and the docket stays the authoritative record.
What you can do together
- Look up a docket as a step inside a workflow, so the result belongs to the process rather than to a browser tab.
- Ask a question that reaches the docket and your own case material at once, each cited.
- Shape the request pattern to the terms of the account the workflow uses, including any fees it carries.
- Use the CourtListener connection where its docket holdings answer the question.
A scenario
- ScopingThe engagement would agree the request pattern, the account used, and where CourtListener is sufficient instead.
- SetupAn HTTP Request node would be configured within the matter workflow.
- A checkThe workflow would look up the docket and record what it found as part of the run.
- An answerCounsel would ask what has been filed since a date and get the docket entries beside the team's own material, the internal half scoped to their identity.
- Usage reviewThe request pattern would be reviewed against the account's usage, which is the reason it was scoped rather than left open.
What stays where
PACER remains the authoritative docket
Entries would be read and not copied in, and nothing would be written back.
The account's terms are part of the design
Whatever the PACER account permits and charges, the request pattern would be agreed rather than left to a workflow running freely.
The MCP route is a third-party gateway, not the judiciary
Any such server is a broker in the path, weighed against a direct call in the engagement.
Processing runs where you deploy the platform
Reaching PACER needs an outbound network path, which an air-gapped deployment does not have.
Products and solutions
Next step
See it on your own PACER 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/pacer