search_records
{ query }
Plain-language search over everything the agency has released — the tool descriptions steer agents to search before filing, so the deflection posture survives the machine door.
For developers & AI agents
Every portal is an API. Every archive speaks MCP.
Brandeis is built for the agentic web: a resident's, a newsroom's, or a researcher's AI agent can search an agency's public archive, read records, file a request, and track it — over plain JSON or the Model Context Protocol. Agencies turn it on per portal.
One agent's session
→ tools/call search_records {"query": "towing contracts"}
3 public records · download links includedSame public-records-only door as the portal
→ tools/call file_request {"description": "police incident report…"}
Filed as PR-2026-00184Response due Mar 14, per Cal. Gov. Code § 7922.535
The agent never sees more than the portal shows anyone — and a filing it makes is a real request, on the real statutory clock.
The rules of the machine door
Safe for agents because it's the same door.
Projection only
Without a key, every byte served already flows through a page an anonymous visitor can load; with one, only what its owner sees signed in. Enabling the API changes the format, never the audience.
Filing is the real thing
file_request rides the exact chain the portal form uses: one filing path, two front doors. A machine-filed request gets the same deadline, the same audit trail, the same named-human review.
Keys are optional
Anonymous use stays open and rate-limited. A free key, made on your portal account once your email is verified, is you: your own requests, files and messages, a higher filing limit, and status pings.
The MCP tools
Six tools. The whole requester loop.
POST /api/v1/{agency}/mcp — streamable HTTP, stateless, no SDK required on either side.
get_record
{ id }
One public record, extracted text included. Non-public ids behave exactly like nonexistent ones — an agent can't even learn what it isn't allowed to see.
get_request_status
{ trackingNumber }
The public tracker's projection: status, statutory due date, published events. Nothing about the requester, no internal notes.
preview_request
{ description, …same optional fields }
An optional dry run that files nothing: published matches, narrowing questions, and the deadline a filing would get. Filing never requires it.
get_agency_rules
{ }
The records law as data: deadline and whether it's the statute's number, extensions, exemptions, appeal, with sources.
file_request
{ description, requesterEmail?, idempotencyKey?, dateRangeStart?, recordTypes?, agent?, … }
Files a real request through the portal's own intake chain — real tracking number, statutory deadline, triage, audit events. The tool description says out loud that this is a legal act.
Prefer plain JSON? The same surface is REST: GET /archive?q=… · POST /requests/preview · GET /rules · POST /requests · GET /requests/{id}. Agents find all of it at /{agency}/llms.txt.
Try it in a terminal
The live demo has the door open.
The City of Riverton demo runs with the requester API enabled — list the tools:
curl -s https://brandeis.us/api/v1/riverton/mcp \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Or hand the endpoint straight to an agent — in Claude Code, for example:
claude mcp add --transport http riverton \ https://brandeis.us/api/v1/riverton/mcp
Then ask the agent for towing contracts. It will search before it files — and if it files, the request lands on the statutory clock with a tracking number the agent can poll. Your move, robots.
For the agencies
Your records, readable by the next generation of requesters.
Agentic AI is already filing requests. Give it a front door that answers from the public archive first.