Skip to main content
Glama
Legal Docket Monitor MCP Server

Legal Docket Monitor MCP Server

by deflucaseng

Docket Intelligence

Monitors court dockets and cross-references them against a client database to surface business development opportunities and conflict flags for law firms.

Built with MCP (Model Context Protocol), Claude, and Python. Runs locally with SQLite; deploys to Azure with SharePoint as the data layer.


Architecture

Scheduler (cron / Azure Logic App)
        │
        ▼
Agent Orchestrator  ←──── Claude API (entity extraction + classification)
        │
        ├──► Docket Monitor MCP Server   (CourtListener / Docket Alarm)
        ├──► Client Intel MCP Server     (SQLite locally / SharePoint in prod)
        └──► Notifications MCP Server    (log file locally / Graph API in prod)

Related MCP server: CourtListener MCP Server

Local Setup

1. Clone and install dependencies

git clone <repo>
cd docket-intelligence
python -m venv .venv
source .venv/bin/activate       # Windows: .venv\Scripts\activate
pip install -r requirements.txt

2. Configure environment

cp .env.example .env
# Edit .env and add your ANTHROPIC_API_KEY at minimum

3. Seed the local client database

python scripts/seed_clients.py

4. Run the agent

# Dry run — fetches and analyzes dockets but writes nothing
python -m src.agent.orchestrator --dry-run

# Live run — logs opportunities to SQLite, sends mock notifications
python -m src.agent.orchestrator

# Filter by court and date
python -m src.agent.orchestrator --court nysd --date-from 2024-01-01

5. Run tests

pytest tests/ -v

Project Structure

docket-intelligence/
├── src/
│   ├── models/
│   │   └── models.py              # Pydantic data models (Docket, Client, Opportunity, …)
│   ├── mcp_servers/
│   │   ├── docket_monitor/
│   │   │   └── server.py          # MCP server: fetches dockets from CourtListener
│   │   ├── client_intel/
│   │   │   ├── server.py          # MCP server: client DB operations
│   │   │   └── sqlite_repo.py     # SQLite adapter (swap for Graph adapter in prod)
│   │   └── notifications/
│   │       └── server.py          # MCP server: Teams/email/tasks (logs locally)
│   └── agent/
│       └── orchestrator.py        # Core AI loop connecting all three servers
├── scripts/
│   └── seed_clients.py            # Populate local DB with test clients
├── tests/
│   └── test_client_repo.py        # Unit tests for SQLite repo and matching
├── data/                          # Local SQLite DB and notification logs (git-ignored)
├── .env.example
└── requirements.txt

Swapping to Production (Microsoft)

The local → production swap is controlled by one env variable: ENV=production.

When ENV=production, the Client Intel server loads graph_adapter.py instead of sqlite_repo.py. The MCP tool interface is identical — only the data layer changes.

See DEPLOYMENT.md for Azure setup instructions.


CourtListener Wrapper Server

src/mcp_servers/courtlistener_wrapper/server.py is a unified server that combines the official CourtListener hosted MCP server with this project's conflict-checking and opportunity-management tools. Use it when you want a single connection point instead of running three separate servers.

What it exposes

Source

Tools

Official CL MCP (proxied)

All tools from mcp.courtlistener.com — search, opinions, citations, alerts, judge data, etc. Auto-updates as CourtListener adds new tools.

Conflict & client intel

check_conflicts, find_entity_matches, log_opportunity, list_opportunities, update_opportunity_status

Combined

search_filings_with_conflicts — fetch dockets + run conflict check in one call; check_party_in_courts — find all cases for a named entity + check if they're a client

Connecting

If COURTLISTENER_API_TOKEN is set, the wrapper connects to the official CourtListener MCP server via OAuth SSE and proxies its full tool set. Without a token it runs in local-only mode (direct REST API + conflict tools only).

# Run the wrapper standalone (e.g. to wire into Claude Desktop or another MCP host)
python -m src.mcp_servers.courtlistener_wrapper.server

To point the orchestrator at the wrapper instead of the three individual servers, replace the StdioServerParameters in orchestrator.py with a single entry:

WRAPPER_SERVER = StdioServerParameters(
    command="python",
    args=["-m", "src.mcp_servers.courtlistener_wrapper.server"],
)

Adding a New Docket Data Source

  1. Create src/mcp_servers/docket_monitor/adapters/your_source.py

  2. Implement fetch_dockets(...) returning list[Docket]

  3. Set DOCKET_SOURCE=your_source in .env

  4. The server picks up the new adapter via the factory in server.py


Key Design Decisions

  • Adapter pattern — every external dependency sits behind an interface, making the local↔production swap clean and testable without cloud access.

  • MCP over direct function calls — each server can be tested, replaced, or scaled independently. The agent only knows tool names and schemas, not implementations.

  • Human in the loop — the agent surfaces and classifies; attorneys decide. No automated outreach without human approval.

  • Tenant-local in production — client data never leaves the Microsoft 365 tenant. The only external calls are reads from court data APIs and the Claude API.

Available Tools

12 tools
check_client_sourceA

Health check the configured client list backend (SharePoint, Excel, or webhook). Useful when setting up a new connection to verify credentials and connectivity.

Inputs: no named parameters.

check_watched_docketsA

Poll all watched dockets for new filings since they were last checked. Updates the last-checked timestamp for each docket after polling. When triage is enabled, each new filing is classified by urgency via the connected model (sampling) — routine, needs-review, or urgent.

Inputs: since_override, triage.

find_matching_clientsA

Fuzzy-search the firm's configured client list (SharePoint, Excel, or custom webhook) for clients matching a name or query. Requires CLIENT_SOURCE_TYPE to be configured. Use this to find candidate clients before linking a docket with link_docket_to_client.

Inputs: query (required), limit.

get_docketB

Fetch full metadata for a specific CourtListener docket by its numeric ID. Returns case name, docket number, court, judge, filing dates, and status.

Inputs: docket_id (required).

get_docket_summaryA

Get a combined summary of a docket: key metadata plus the most recent N filings. Ideal for a quick status check on a matter.

Inputs: docket_id (required), recent_entry_count.

get_new_filingsA

Get docket entries (filings) for a case, optionally filtered to entries since a given date. Use this to check what has been filed since you last looked at a case.

Inputs: docket_id (required), since, limit.

get_partiesC

Get the parties and their attorneys for a docket.

Inputs: docket_id (required).

list_watched_docketsA

List all dockets currently on the watch list.

Inputs: no named parameters.

search_docketsA

Search CourtListener for federal court dockets by case name, party name, or docket number. Returns a list of matching cases with IDs you can use in other tools.

Inputs: query (required), court, date_filed_after, date_filed_before, +1 more.

unwatch_docketB

Remove a docket from the watch list.

Inputs: matter_id (required).

watch_docketA

Add a docket to the watch list. Use check_watched_dockets to poll all watched dockets for updates.

Inputs: docket_id (required), matter_id (required).

Tool Schema Changelog

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

Loading tool schema changelog…

    TDQS

    A3.9/5.0

    Scored across 12 tools

    Disambiguation5/5

    Each tool has a clearly distinct purpose, from health checks to client linking to docket retrieval and watch list management. No two tools overlap in functionality; descriptions are precise and disambiguate effectively.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern using lowercase with underscores, e.g., check_client_source, get_docket, link_docket_to_client. The naming is predictable and aids in understanding tool roles.

    Tool Count5/5

    12 tools is well-scoped for a legal docket monitoring server, covering search, retrieval, watch list management, client linking, and health checks with no unnecessary clutter.

    Completeness5/5

    The tool surface provides comprehensive coverage for monitoring court dockets: searching, fetching metadata, filings, parties, managing a watch list, linking to clients, and verifying connectivity. There are no obvious gaps for the stated purpose.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers