Legal Docket Monitor — MCP Server

An MCP server that wraps the CourtListener API for real-time federal docket monitoring — and, when configured, automatically connects new filings to your firm's existing client list, wherever it lives.

Built for litigation teams who don't want to manually check PACER for new filings, and who want that monitoring connected to "which client does this affect" without re-keying data between systems.

Why this exists

Most docket-monitoring tools are single-purpose: they watch a case and email you. This is an MCP server instead — a tool layer any AI agent (Claude Desktop, Cursor, your own orchestrator) can call. That means an agent can watch dockets, triage what's urgent, and link filings to clients as part of a larger workflow you control, not a fixed pipeline someone else built.

Related MCP server: DocketBird MCP Server

What's new in v2

v1 monitored dockets. v2 adds:

• A pluggable client-list connector — SharePoint List, Excel Table, or your own backend via webhook, all behind one interface. Pick whichever fits your stack; switching later is a config change, not a rewrite.

• Sampling-based filing triage — new filings are automatically classified (routine / needs-review / urgent) using the connected AI client's own model. The server never holds a model API key.

• Elicitation-based client matching — when a filing's case name could match more than one client, the server asks a human to confirm instead of guessing.

Tools

Docket monitoring

Client matching (requires a configured client source — see below)

Architecture

MCP tool layer (src/index.ts)
        │
        ├─→ CourtListener client (src/courtlistener.ts)     — docket data
        ├─→ Watch list (src/watchlist.ts)                    — tracked matters
        ├─→ Triage (src/triage.ts)                            — sampling-based urgency classification
        ├─→ Client matching (src/client-matching.ts)          — elicitation-based resolution
        └─→ ClientListSource (src/client-sources/)             — pluggable client-list backend
                  ├─ SharePointListSource   (Microsoft Graph: SharePoint Lists)
                  ├─ ExcelTableSource       (Microsoft Graph: Excel Workbook API)
                  └─ WebhookSource          (your own REST endpoint)

Every client-list backend implements the same ClientListSource interface. The tool layer never knows which one is active — that's controlled entirely by environment configuration (see below). This is what makes "connect your client list however you want" an actual property of the system rather than a roadmap item.

Prerequisites

• Node.js 18+

• A free CourtListener account, for an API token: https://www.courtlistener.com/sign-in/

• If connecting SharePoint or Excel: an Entra ID (Azure AD) app registration with Sites.Read.Write.All (or narrower, scoped to the specific site) Graph API permissions, using the client-credentials flow

• If connecting a custom backend: an HTTP endpoint matching the contract below

Installation

git clone <your-repo>
cd legal-docket-monitor
npm install
npm run build

Configuration

Docket monitoring works standalone with just a CourtListener token. Client matching requires one client-source configuration block, chosen by CLIENT_SOURCE_TYPE.

# Required for docket monitoring
COURTLISTENER_API_TOKEN=your_token_here

# Optional — enables client-matching tools. One of: sharepoint, excel, webhook
CLIENT_SOURCE_TYPE=

# --- SharePoint List ---
SHAREPOINT_SITE_ID=
SHAREPOINT_LIST_ID=
GRAPH_TENANT_ID=
GRAPH_CLIENT_ID=
GRAPH_CLIENT_SECRET=

# --- Excel Table (same Graph credentials as SharePoint) ---
EXCEL_DRIVE_ID=
EXCEL_ITEM_ID=
EXCEL_TABLE_NAME=
GRAPH_TENANT_ID=
GRAPH_CLIENT_ID=
GRAPH_CLIENT_SECRET=

# --- Custom webhook (your own code) ---
WEBHOOK_BASE_URL=
WEBHOOK_AUTH_TOKEN=
WEBHOOK_SEARCH_FALLBACK=true   # set false to require the backend implement /clients/search

If CLIENT_SOURCE_TYPE is unset, the server runs in docket-monitoring-only mode — find_matching_clients and link_docket_to_client report that no client source is configured, rather than failing.

SharePoint List — expected columns

Excel Table — expected columns

Same shape as above, but the data must be formatted as an actual Excel Table (Insert → Table), not a raw range — the Graph Workbook API operates on named tables. Header names: ClientName, Aliases, MatterIds, ContactEmail, PracticeArea.

Custom webhook — expected contract

Your backend implements:

GET  /clients                    → ClientRecord[]
GET  /clients/search?q=&limit=   → ClientMatch[]   (optional; falls back to local
                                    fuzzy search over GET /clients if omitted)
POST /clients/:id/link           → body: { docketId: number }, 204 on success
GET  /health                     → { ok: boolean, detail?: string }

All requests carry Authorization: Bearer <WEBHOOK_AUTH_TOKEN>. See src/client-sources/types.ts for the exact ClientRecord and ClientMatch shapes.

Connecting to Claude Desktop

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "legal-docket-monitor": {
      "command": "node",
      "args": ["/absolute/path/to/legal-docket-monitor/dist/index.js"],
      "env": {
        "COURTLISTENER_API_TOKEN": "your_token_here",
        "CLIENT_SOURCE_TYPE": "sharepoint",
        "SHAREPOINT_SITE_ID": "...",
        "SHAREPOINT_LIST_ID": "...",
        "GRAPH_TENANT_ID": "...",
        "GRAPH_CLIENT_ID": "...",
        "GRAPH_CLIENT_SECRET": "..."
      }
    }
  }
}

Restart Claude Desktop after editing. Note: sampling and elicitation require a client that supports those MCP capabilities — check your client's documentation if check_watched_dockets triage or link_docket_to_client confirmation prompts don't appear.

Example agent interactions

Watch a matter and check in on it:
→ watch_docket(docket_id=4214664, matter_id="smith-v-jones")
→ check_watched_dockets()
   → new filings are automatically triaged: 🔴 urgent / 🟡 needs-review / ⚪ routine

Connect a docket to your client list:
→ link_docket_to_client(docket_id=4214664, case_name="Acme Corp Holdings LLC v. Smith")
   → if one clear match: linked automatically
   → if ambiguous: you're asked to pick which client record is correct

Check whether your client source is set up correctly:
→ check_client_source()

Running tests

npm test          # full suite — 55 tests across docket, watchlist, and client-source logic
npm run typecheck  # type-check only, faster than a full build

All tests mock network calls (fetch) — no real CourtListener, Graph, or webhook requests are made during testing.

Project structure

src/
  index.ts                    MCP server entry point — all tool definitions
  courtlistener.ts            CourtListener API v4 client
  watchlist.ts                In-memory watch list
  triage.ts                   Sampling-based filing urgency triage
  client-matching.ts          Elicitation-based docket→client resolution
  client-sources/
    types.ts                  ClientListSource interface + fuzzy matching + caching
    graph-client.ts           Shared Microsoft Graph auth client
    sharepoint-source.ts      SharePoint List adapter
    excel-source.ts           Excel Table adapter
    webhook-source.ts         Custom backend adapter
    factory.ts                Picks the adapter from CLIENT_SOURCE_TYPE
  *.test.ts                   Vitest suites
CLAUDE.md                     Guidance for AI agents extending this codebase

Limitations & production considerations

• Watch list is in-memory — lost on restart. Swap WatchList for a persistent store for production use.

• CourtListener coverage isn't complete for every federal case — cases not submitted to RECAP may have limited entry data.

• Client-source caching: client lists are cached for 5 minutes by default (TtlCache in types.ts) to avoid hammering SharePoint/Excel/your webhook on every fuzzy search. Adjust if your client list changes more frequently than that.

• Sampling and elicitation require client support. Not every MCP client implements these capabilities yet. The server degrades gracefully (triage falls back to raw filing text; matching without elicitation support will simply not offer disambiguation), but won't error out.

• No webhooks from CourtListener (yet) — check_watched_dockets is poll-based. A future extension could register CourtListener webhooks for push-based alerts instead.

Contributing

See CLAUDE.md for architecture conventions, the adapter-extension checklist, and PR expectations if you're adding a new client-list backend or tool.

License

MIT