Legal Docket Monitor MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
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.
Average 3.7/5 across 12 of 12 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![legal-docket-monitor-mcp MCP server](https://glama.ai/mcp/servers/deflucaseng/legal-docket-monitor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/deflucaseng/legal-docket-monitor-mcp)

Score Badge

Copy to your README.md:

[![legal-docket-monitor-mcp MCP server](https://glama.ai/mcp/servers/deflucaseng/legal-docket-monitor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/deflucaseng/legal-docket-monitor-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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