This server enables law firms to search, monitor, and analyze federal court dockets via CourtListener, and integrate with a firm's client database for conflict checking and business development.
Search & Retrieve Dockets
Search federal dockets by case name, party name, or keywords, with optional filters for court, date range, and result limit (search_dockets)
Fetch full metadata for a specific docket by its numeric ID (get_docket)
Retrieve all or recent docket entries/filings for a case (get_new_filings)
Get a combined summary of key metadata plus the most recent filings (get_docket_summary)
List the parties and attorneys involved in a docket (get_parties)
Monitor Dockets
Add a docket to a watch list with a human-readable matter label (watch_docket)
Remove a docket from the watch list (unwatch_docket)
List all currently watched dockets (list_watched_dockets)
Poll all watched dockets for new filings, with optional AI-powered triage that classifies each filing as routine, needs-review, or urgent (check_watched_dockets)
Client Intelligence & Conflict Checking
Fuzzy-search the firm's client list (SharePoint, Excel, or custom webhook) to find clients matching a party or case name (find_matching_clients)
Link a CourtListener docket to a client in the firm's database, with automatic high-confidence linking or interactive confirmation when multiple matches exist (link_docket_to_client)
Health-check the configured client list backend to verify credentials and connectivity (check_client_source)
All tools forbid background task execution, keeping the human in the loop. The client data layer is swappable (SQLite, SharePoint, etc.) without changing the tool interface.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Legal Docket Monitor MCP Server Check my watched dockets for new filings."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
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: DocketBird MCP Server
git clone <repo>
cd docket-intelligence
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txtcp .env.example .env
# Edit .env and add your ANTHROPIC_API_KEY at minimumpython scripts/seed_clients.py# 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-01pytest tests/ -vdocket-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.txtThe 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.
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.
Source | Tools |
Official CL MCP (proxied) | All tools from |
Conflict & client intel |
|
Combined |
|
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.serverTo 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"],
)Create src/mcp_servers/docket_monitor/adapters/your_source.py
Implement fetch_dockets(...) returning list[Docket]
Set DOCKET_SOURCE=your_source in .env
The server picks up the new adapter via the factory in server.py
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.
Health check the configured client list backend (SharePoint, Excel, or webhook). Useful when setting up a new connection to verify credentials and connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates the tool performs a connectivity and credential verification, but does not specify outcomes (e.g., success/failure messages, side effects like logging, or whether it is read-only). Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the action and resource, the second provides usage context. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides all necessary information: purpose, supported backends, and when to use it. Fully complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), and schema description coverage is 100%. The description implicitly covers the absence of parameters by not mentioning any inputs. It adds no additional parameter information beyond the schema, but none is needed. Baseline 3 adjusted upward because no param info is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('health check') and the resource ('configured client list backend'), listing specific backend types (SharePoint, Excel, webhook). It is distinct from sibling tools, which focus on docket operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Useful when setting up a new connection to verify credentials and connectivity,' providing clear context for when to use the tool. No exclusions or alternatives are mentioned, but the context is sufficient given the tool's simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| since_override | No | Override the last-checked date for all dockets with this date (YYYY-MM-DD). Useful for looking back further than the last check. | |
| triage | No | Classify each new filing's urgency via sampling (requires client sampling support). Set false to skip triage and just list raw filings. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses side effects (updating last-checked timestamp) and conditional behavior (triage based on sampling). However, it omits prerequisites (e.g., must have watched dockets), potential rate limits, or error behavior, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word contributes meaning. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers input behavior and side effects, it lacks any hint about the output/return structure (e.g., does it return new filings, classifications?). Since there is no output schema, the description should compensate, but it does not, leaving a gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. The tool description adds minimal value beyond the schema; e.g., it mentions 'since_override' overriding the last-checked date, which is already in the schema. Baseline 3 is appropriate as schema coverage is 100% and description doesn't significantly enrich semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls all watched dockets for new filings since last checked, with specific actions like updating timestamp and optional triage. The action 'poll all watched dockets' is distinct from siblings like 'get_new_filings' which likely fetches filings for a single docket, though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide when-to-use or when-not-to-use guidance relative to sibling tools. It implies batch checking but lacks explicit context on when to choose this tool over alternatives like 'get_new_filings' or 'get_docket'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Case name, party name, or client name to search for | |
| limit | No | Maximum number of candidate matches to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It covers the fuzzy-search behavior and the dependency on configuration, but does not mention performance, rate limits, or what happens if the source is misconfigured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The most important information (operation, source, prerequisite, use case) is in the first sentence. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While all parameters are documented in the schema, there is no output schema and the description does not explain what the return format looks like (e.g., list of client objects with IDs). This is a moderate gap for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context that the query is for client names, but does not add new meaning beyond what the schema parameter descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs fuzzy-search on the configured client list, specifies the data sources (SharePoint, Excel, custom webhook), and directly distinguishes itself from the sibling tool link_docket_to_client by indicating its use case as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions the prerequisite CLIENT_SOURCE_TYPE configuration and gives a specific usage scenario before linking a docket. It does not explicitly state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full metadata for a specific CourtListener docket by its numeric ID. Returns case name, docket number, court, judge, filing dates, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| docket_id | Yes | CourtListener numeric docket ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states what the tool does and returns, without disclosing behavioral traits such as authentication requirements, rate limits, or error handling. The tool's read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence introduces the action and resource, the second lists key return fields. Front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool without output schema, the description adequately covers the purpose and return values. However, it could be slightly improved by noting error scenarios or the need for a valid docket ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (`docket_id`) already described as 'CourtListener numeric docket ID'. The description repeats this without adding new details like expected format, range, or examples. Baseline of 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'full metadata for a specific CourtListener docket', and lists the specific fields returned (case name, docket number, etc.). It distinguishes from sibling tools like `get_docket_summary` (summary vs full) and `search_dockets` (search vs fetch by ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'by its numeric ID' but provides no guidance on when to use this tool versus alternatives like `get_docket_summary` or `search_dockets`. It does not specify prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a combined summary of a docket: key metadata plus the most recent N filings. Ideal for a quick status check on a matter.
| Name | Required | Description | Default |
|---|---|---|---|
| docket_id | Yes | CourtListener numeric docket ID | |
| recent_entry_count | No | Number of recent entries to include (default: 5, max: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the output is a combined summary but does not disclose what 'key metadata' includes, error handling, rate limits, or whether it is read-only. More behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste: first sentence defines the tool, second sentence suggests the use case. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description provides a general idea of what the tool returns but lacks details on output format or potential constraints. It is adequate for a quick status check but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters have clear descriptions in the schema. The description reinforces the purpose of 'recent_entry_count' but adds no new semantic value beyond the schema, resulting in baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'docket summary', specifying it combines key metadata with recent N filings. It effectively distinguishes from sibling tools like 'get_docket' (full docket) and 'get_new_filings' (filings only) by offering a combined summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case ('Ideal for a quick status check on a matter'), but lacks explicit guidance on when not to use it or alternatives among siblings. It does not mention when to prefer other tools like 'get_docket' or 'get_parties'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| docket_id | Yes | CourtListener numeric docket ID | |
| since | No | Only return entries filed on or after this date (YYYY-MM-DD). Omit to get all entries. | |
| limit | No | Maximum entries to return (default: 25, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as retrieving entries (read operation) and optionally filtering by date, but does not explicitly state that it is a read-only operation, mention any side effects, or discuss authentication or rate limits. The behavior is implied but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the action, and contains no filler. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with 3 parameters and no output schema, the description covers the essential purpose and filtering capability. It does not detail the return format or pagination, but the limit parameter suggests pagination. Overall, it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters already have descriptions. The description adds context by linking the 'since' parameter to the use case of checking new filings, but does not provide additional semantic depth beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves docket entries (filings) for a case, with optional date filtering. It distinguishes itself from sibling tools like 'get_docket' or 'get_docket_summary' by focusing on entries and the specific use case of checking recent filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to check what has been filed since you last looked at a case,' providing a concrete use case. It does not explicitly state when not to use it, but the context of sibling tools implies alternatives for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the parties and their attorneys for a docket.
| Name | Required | Description | Default |
|---|---|---|---|
| docket_id | Yes | CourtListener numeric docket ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states a read operation ('Get'), but does not disclose whether the tool requires authentication, what happens on invalid docket_id, rate limits, or any potential side effects. The description is insufficient for an agent to understand behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded with the key verb and resource. However, it could be slightly restructured to include more context without sacrificing conciseness, e.g., specifying it returns a list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one required param, no output schema) and no annotations, the description is too minimal. It does not explain the return format, error handling, or pagination. An agent may not know that multiple parties can be returned or what 'attorneys' includes. Completeness is lacking for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (only one parameter 'docket_id' is documented in the schema). The description adds no additional meaning beyond the schema's 'CourtListener numeric docket ID'. Thus, the baseline score of 3 is appropriate; the description does not enhance understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('parties and their attorneys for a docket'). It is specific enough to distinguish from sibling tools like 'get_docket' which likely returns docket metadata. However, it does not use a more precise verb like 'list' or 'retrieve', and the scope is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_docket' or 'search_dockets'. There are no prerequisites, exclusions, or examples. The agent must infer usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link a docket to a client in the firm's client list. If the case name matches a single client with high confidence, links automatically. If multiple clients are plausible matches, asks the user to confirm via an interactive prompt (elicitation) rather than guessing. Requires CLIENT_SOURCE_TYPE to be configured.
| Name | Required | Description | Default |
|---|---|---|---|
| docket_id | Yes | CourtListener numeric docket ID | |
| case_name | Yes | The case name to match against the client list (e.g. from get_docket) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals auto-linking behavior, interactive prompting for multiple matches, and a configuration requirement. It does not cover edge cases like no match or potential reversibility, but the disclosed behaviors are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value. The first states the purpose, the second explains the conditional logic, and the third notes a requirement. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple parameters and no output schema, the description covers the key behaviors and prerequisites. It could mention what happens if no match is found, but overall it is sufficiently complete for an AI agent to understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds context about matching logic but does not significantly extend parameter meaning. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: linking a docket to a client. It explains the automatic linking with high confidence and the elicitation prompt for ambiguous matches, distinguishing it from siblings like find_matching_clients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by specifying the prerequisite (CLIENT_SOURCE_TYPE configuration) and the behavior when multiple clients match. However, it does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all dockets currently on the watch list.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose any behavioral traits like pagination, rate limits, or ordering, which would be helpful for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details on return format or pagination, which is notable given no output schema. It minimally informs the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, baseline is 4. The description adds no param info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all dockets on the watch list, using a specific verb and resource. It differentiates from siblings like 'watch_docket' and 'unwatch_docket'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use or not use this tool, but the name and context imply it is for viewing watched dockets, not for searching or managing them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Case name, party, or keywords to search for | |
| court | No | Optional court abbreviation to filter results (e.g. 'dcd' for D.D.C., 'ca2' for 2nd Cir.) | |
| date_filed_after | No | Filter to cases filed after this date (YYYY-MM-DD) | |
| date_filed_before | No | Filter to cases filed before this date (YYYY-MM-DD) | |
| limit | No | Maximum number of results to return (default: 10, max: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states it searches CourtListener and returns a list with case IDs, but with no annotations, it lacks details on result limits (though param schema has limit), ordering, pagination, or error behavior. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that effectively conveys purpose and output. No unnecessary words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return value is a list of matching cases with IDs, usable in other tools. This provides basic output context. However, missing details on return structure, error handling, and result format. Acceptable for a search tool given sibling tools cover specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal extra context by specifying search types (case name, party, docket number) that map to the query parameter, but does not add details beyond schema for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches federal court dockets by case name, party name, or docket number, and returns matching cases with IDs. This distinguishes it from sibling tools like get_docket which retrieve specific dockets by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for searching dockets and mentions returned IDs can be used in other tools, but does not explicitly state when to use this tool versus siblings like get_docket, get_docket_summary, etc. No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a docket from the watch list.
| Name | Required | Description | Default |
|---|---|---|---|
| matter_id | Yes | The matter_id used when adding the watch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description only states the action without disclosing consequences (e.g., irreversibility, effects on related data, error conditions). Minimal transparency for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, but could benefit from slight expansion (e.g., noting that the docket must already be watched). Efficient, not under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple one-parameter removal tool, but lacks error handling or prerequisite context (e.g., docket must be on watch list). Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the only parameter. The tool description adds no additional meaning beyond the schema's description, earning a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'remove' and resource 'docket from the watch list', distinguishing it from siblings like 'watch_docket' and 'list_watched_dockets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., 'watch_docket' or 'list_watched_dockets'), no prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a docket to the watch list. Use check_watched_dockets to poll all watched dockets for updates.
| Name | Required | Description | Default |
|---|---|---|---|
| docket_id | Yes | CourtListener numeric docket ID | |
| matter_id | Yes | A human-readable label for this matter (e.g. 'Smith v. Jones' or 'matter-0042'). Used to identify the watch in list/remove operations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the action but does not disclose side effects (e.g., duplicate handling, idempotency, auth requirements). The addition is straightforward but lacks depth in behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The action is front-loaded, and the cross-reference to a sibling tool adds value efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is mostly complete. It covers the primary action and references a related tool. Minor gaps exist in error handling or constraints, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and schema descriptions are adequate. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add') and resource ('docket to the watch list'), and distinguishes from sibling tools by explicitly naming 'check_watched_dockets' for polling. This meets the highest standard of specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using 'check_watched_dockets' for polling, providing context on related operations. However, it does not explicitly exclude use cases like overwriting existing watches or mention prerequisites, but the sibling list partially compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0check_client_sourcecheck_watched_docketsfind_matching_clientsget_docketget_docket_summaryget_new_filingsget_partieslink_docket_to_clientlist_watched_docketssearch_docketsunwatch_docketwatch_docketEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search US court opinions, federal dockets, judges, citations, and oral arguments via CourtListener.
Search US federal and state court records through CourtListener and the RECAP archive
MCP for CourtListener: US federal and state opinions, dockets, judges, plus eCFR regulations.
Official EUR-Lex, UK, US, and gazette search, metadata fetch, and change-only watches.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/deflucaseng/legal-docket-monitor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server