DocketBird MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose. Full-text search vs. docket entry search, single document download vs. bulk, metadata-only vs. full docket, and the unique litigation graph tool prevent any ambiguity.
Naming Consistency5/5
All tools follow a consistent 'docketbird_verb_noun' pattern in snake_case, with verbs like search, get, list, download, create, follow, ask. No mixing of conventions.
Tool Count5/5
16 tools cover the essential functionalities of searching, listing, downloading, calendar management, and litigation graph queries without being excessive or sparse.
Completeness4/5
Core workflows (search, retrieve, download, calendar, monitor) are covered. Minor gaps like missing unfollow_case or delete_autocalendar exist, but agents can still operate effectively.
Average 4.8/5 across 16 of 16 tools scored. Lowest: 4.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 26 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=false (mutation) and destructiveHint=false (non-destructive). The description adds behavioral context: monitoring frequency and that it triggers notifications. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a 'When to use' section, but it redundantly includes an 'Args' block that restates the parameter name from the schema. Could omit that section for conciseness.
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?
Given low complexity (1 required param, output schema exists), the description covers purpose, usage context, parameter format, and monitoring frequency. It is sufficient for an agent to use the tool correctly.
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?
Schema coverage is 0% (only title 'Case Id'), but the description adds concrete meaning with an example format 'txnd-3:2007-cv-01697', compensating for the sparse schema. This helps the agent understand the expected input format.
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 uses a specific verb+resource combination ('Follow a court case so DocketBird monitors it for new filings') and clearly distinguishes from siblings like docketbird_search_cases or docketbird_get_case_details by focusing on ongoing monitoring.
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 'When to use' section explicitly states tracking/monitoring use cases. It also provides monitoring frequency (twice weekly for federal, once weekly for state), which helps the agent set expectations. However, it does not directly contrast with sibling tools, but the guidance is clear enough.
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?
Adds context beyond annotations: lightweight, research-scope, works for any case in index (not just user's), does NOT fetch docket. No contradiction with annotations. Could mention rate limits or auth, but still strong.
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?
Well-structured with bullet points for usage scenarios and args. Concise but includes necessary details. Could be slightly shorter, but very readable.
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?
Given output schema exists, description appropriately covers purpose, behavior, and parameter. Mentions return content (metadata and pointer to complaint). Complete for a simple lookup 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?
Despite 0% schema coverage, the description explains the case_id parameter with format and example ('txwd-1:2022-cv-00398'), compensating well for the missing schema description.
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?
Clearly states the action is to get a case's metadata including a pointer to its complaint. Distinguishes from siblings by contrasting with get_case_details (full docket) and ask_litigation_graph (parties/attorneys).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use (resolving case ID, jumping to complaint, checking PACER ID) and why not to use alternatives. Also notes it does not fetch docket to avoid timeout, providing clear context.
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?
Annotations already mark it as readOnly and idempotent. The description adds key behavioral details: live API data, the curated vs full set behavior, search result limits (up to 25 ranked matches), and the use of court_system to include unlisted state courts. No contradictions with annotations.
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 well-structured with bold headers and bullet points, front-loading the main purpose. Every sentence adds value, though it is slightly verbose; the verbosity is justified by the need to explain multiple modes.
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 the three parameters and lack of schema descriptions, the description covers all modes and parameter effects. It includes behavior for no arguments, search, and court_system, as well as the optional court_type filter. The output schema handles return structure, so no further details needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains each parameter: search for free-text lookup, court_system for browsing a system, court_type as an optional filter. It also describes default behavior. This fully compensates for the missing schema 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 lists courts covered by DocketBird, live from the API, with three distinct lookup modes (none, search, court_system). It distinguishes itself from sibling docketbird_list_court_systems by focusing on individual courts rather than court systems.
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 explains when to use each argument: no arguments returns a curated set, search is the fastest way to find a court_id, and court_system browses all courts in a system. It indirectly contrasts with search tools but does not explicitly list when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavior beyond annotations: explains remote vs local modes, inline content vs URL fallback based on MAX_INLINE_SIZE, and error handling. This level of detail is valuable given the openWorldHint and no destructiveHint.
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 well-structured with a summary, mode explanation, When to use, Args, and Returns sections. While slightly verbose, each sentence adds value and the information is front-loaded. No unnecessary repetition.
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 the lack of output schema, the description covers all critical aspects: usage scenarios, parameter details, return types for remote/local modes, size cap behavior, and error cases. It is fully sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully describes both parameters: document_id as the DocketBird document ID, and save_path with its mode-dependent behavior (ignored remotely, used locally). This adds essential meaning missing from the schema.
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 'Download a specific document by ID.' and differentiates itself from siblings by detailing two modes (remote vs local stdio), making its purpose distinct among tools like docketbird_get_document and docketbird_download_files.
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 'When to use' section explicitly lists three scenarios: retrieving a specific filing, after searching for documents, and downloading individual documents. While it lacks explicit 'when not to use' guidance, the context is clear enough for an agent to determine appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses important behavioral details: cross-corpus vs. account-scoped search, pagination behavior (cursor, how to handle empty pages, result window limit of 10,000), and the fact that found count may be inaccurate due to removed documents. These enrich the agent's understanding of the tool's actions and 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 well-structured with clear sections (intro, differentiation, when-to-use, scope, query syntax, pagination, args). It is relatively long but every sentence serves a purpose, given the complexity of the tool (9 parameters, query syntax, pagination rules). Minor redundancy (scope boundary repeats some of 'when to use') prevents a perfect score.
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 the tool's complexity (9 parameters, query syntax, pagination, scope boundaries), the description covers all necessary aspects: purpose, usage, parameter semantics, behavioral constraints, and edge cases. An output schema exists but is not shown; still, the description provides sufficient context for an AI agent to invoke the tool correctly without needing further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully compensate. It provides an extensive 'Args' section that explains every parameter with meaning, constraints (e.g., query max 500 chars, date format YYYY-MM-DD, court_id formats), defaults, and examples (e.g., query: '"summary judgment" and forfeit* -insurance'). This adds substantial value beyond the schema.
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 full-text search of the bodies of court filings across the entire DocketBird index, and explicitly distinguishes itself from the sibling tool docketbird_search_documents by contrasting what is searched (text content vs. docket entry titles). This meets the standard of specific verb+resource with sibling 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 provides explicit scenarios for when to use the tool (e.g., scanning recent filings, finding documents mentioning a term, practice research with my_cases_only=True) and contrasts it with docketbird_search_documents. It lacks a direct 'when not to use' statement, but the given guidance is clear and helpful for decision-making.
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?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral context about text availability (scans, text-only stubs, not downloaded) and explains that a clear message is returned when text is unavailable, without contradicting annotations.
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 well-structured with sections and bullet points, front-loaded purpose. While slightly long, every sentence adds value, and no unnecessary words are present.
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 the tool's complexity (3 parameters, output schema exists), the description covers purpose, usage guidelines, parameter semantics, availability nuances, and sibling differentiation. It is fully sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains each parameter: document_id with example, offset for paging, max_chars with default and maximum. This adds essential meaning not present in the schema.
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 gets extracted plain text of a court filing and distinguishes it from sibling tools that return metadata or PDFs (docketbird_get_document, docketbird_download_document). It uses specific verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section lists reading/summarizing/quoting and pulling text after docketbird_get_case. Also discusses availability limitations and when other tools are appropriate, providing clear context for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses queued creation, docket sheet update, and potential PACER fees. This goes beyond annotations (which only mark openWorldHint=true) by explaining side effects and costs.
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?
Concise, well-structured: purpose, scope, behavior, usage, args. Every sentence adds value without redundancy.
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?
Covers purpose, behavior, usage, parameter with examples. Output schema exists, so return info is not needed. References related tool for viewing calendar. Complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description provides domain context (DocketBird case ID) and an example format, adding significant meaning over the schema's bare type definition.
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?
Clearly states verb (create), resource (autocalendar for a case), and outcome (deadlines and hearings appear in calendar). Distinguishes from sibling docketbird_get_calendar by referencing it and from docketbird_follow_case by specifying different action.
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?
Explicit 'When to use' section with two scenarios. Mentions practice scope and queuing behavior. Lacks explicit when-not-to-use or alternatives, but provides sufficient context for selection.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context: lightweight lookup, returns specific metadata, and mentions 'without the bytes'. No contradiction. Some behavioral details like link expiry are not covered, but overall sufficient.
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?
Well-structured with distinct sections for purpose, return values, alternatives, usage scenarios, and argument description. Every sentence adds value, no redundancy.
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?
With one parameter, explicit usage guidance, and an output schema present, the description covers all necessary context. It addresses when to use versus siblings, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'document_id' is explained with a clear description and an example format. Schema coverage is 0%, so the description fully compensates.
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 metadata and download links for one document without bytes. It specifies the returned fields (title, filing date, restricted status, PDF link) and distinguishes from sibling tools like docketbird_download_document and docketbird_get_document_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' section listing three specific scenarios. It also implies when not to use by naming alternatives for file content and extracted text.
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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds the important context that only tracked cases (practice scope) are returned. While it doesn't discuss auth or rate limits, the added scope detail justifies a slightly above-baseline score.
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 concise (about 100 words) and well-structured with a heading, a note about alternative, bullet-point usage scenarios, and a clean args list. Every sentence adds value.
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 the simple listing functionality, rich annotations, and presence of an output schema, the description covers all essential aspects: purpose, scope, parameter details, and usage guidance. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries full responsibility. It explains each parameter: scope enum values, page starting at 1, page_size default and max. This compensates fully for the lack of schema 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 lists cases on the user's DocketBird account (practice scope). It uses specific verbs and resources, and explicitly distinguishes from the sibling tool 'docketbird_search_cases' for searching all courts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios: viewing own/firm's tracked cases and finding case IDs for other operations. It also directs to an alternative tool for broader searches, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral detail beyond annotations: research scope (all courts), matching logic for case numbers vs names, date filter tier behavior, and pagination via cursor. No contradictions with readOnlyHint, idempotentHint, etc.
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?
Well-structured with summary, bullet points for scope/matching/dates, when-to-use, and Args. Every sentence is informative and no redundancy.
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?
Complete given 7 params, 1 required, output schema exists. Covers all parameters, behavior, scope, matching, date filtering, pagination, and usage guidance. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully compensates by explaining each parameter: query (max 500 chars), court_id (formats), date params (inclusive, format), exclude_unknown_dates, size (bounds), cursor. Adds meaning beyond schema defaults.
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 searches ALL cases by name or number, and explicitly distinguishes from sibling tool docketbird_list_cases which only covers user's account. The verb 'Search' and resource 'cases' are specific.
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?
Provides a 'When to use' section with two concrete use cases and suggests pairing with docketbird_ask_litigation_graph. Not explicitly stating when not to use, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavioral context: slow 10-25s response, variable result shape, 200-record limit with truncated flag, no email addresses, and no invented data. No contradictions with annotations.
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 well-structured with clear sections (overview, coverage, behavior, args) and front-loaded with purpose. While every sentence adds value, it could be slightly more concise (e.g., the coverage ceiling explanation is repeated in two different ways).
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 the tool's complexity (NL query over graph, variable output), the description covers key expectations: coverage limits, slowness, result shape, truncation, and data policies. The existence of an output schema (mentioned in context) reduces the need for exhaustive return field documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'question' has 0% schema description coverage. The description compensates fully by specifying it is natural-language, max 1000 characters, and provides usage context through examples. This adds clear meaning beyond the schema.
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 answers natural-language queries about the litigation graph, listing entities (parties, attorneys, etc.) and explicitly distinguishes it from siblings: 'This is the ONLY source of party/attorney/firm/judge relationships — the docket endpoints do not return them.' The verb 'ask' and resource 'litigation graph' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (for relationship queries), includes examples, and explains coverage limitations and empty result interpretation. It indirectly tells when not to use (not for criminal/bankruptcy/state) and names alternatives (docket endpoints).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that remote mode returns pre-signed short-lived download links, while local stdio with save_path streams files to disk. Describes return format as Markdown with counts. No contradictions with annotations (readOnlyHint=false, etc.).
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?
Well-structured with clear sections, but somewhat verbose. Could be slightly more concise while retaining all necessary information.
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?
Comprehensive coverage of tool's behavior across modes, return format, and edge cases (restricted/unavailable filings). Output schema exists but description still adds value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explains both parameters: case_id as DocketBird case ID, save_path as local folder, noting it is only honored in local stdio mode. Fully compensates for missing schema 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?
Clearly states 'List or save every available document for a case' and distinguishes itself from sibling docketbird_download_document by noting that it provides links for bulk retrieval while the sibling handles single documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use (complete archive, bulk retrieval, surveying filings) and implies when not to use (single document, instead call docketbird_download_document). Also explains mode-specific behavior (remote vs local stdio).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safe, read-only, idempotent behavior. The description adds that the company-wide scope uses a pre-computed rollup that may need building, and the tool will ask to retry if not built. No contradiction.
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?
Description is well-structured with sections, clear scoping, and no wasted words. It is slightly lengthy but every sentence adds value. Could be trimmed slightly but remains highly organized.
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 two optional parameters, no required params, and an output schema (not shown), the description covers all necessary context: usage scopes, prerequisites, rollup behavior, how days interacts with case_id. An AI agent can confidently decide when and how to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description fully explains both parameters: case_id (format, default empty, omit for company-wide) and days (company-wide only, default 7, clamped 1-90, ignored with case_id). This provides comprehensive meaning beyond the schema.
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 retrieves calendar entries (deadlines, hearings, conferences) from autocalendars. It distinguishes two scopes: with case_id for a single case, and without for company-wide view. The verb 'get' and resource 'calendar entries' are specific, and the tool is distinct from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly tells when to use case_id vs. omit it, explains the company-wide scope and its pre-computed rollup behavior, and references prerequisite docketbird_create_autocalendar. It also notes days is ignored when case_id is provided, giving clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true, but the description adds crucial behavioral details: the upstream /documents endpoint has no pagination (entire docket fetched, page/page_size only shape response), potential 504 timeout for large dockets, and that parties/attorneys are not available from docket endpoints. This goes beyond the annotations.
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 well-structured with clear sections (When to use, Notes, Args) and front-loaded with a summary. While slightly long, every sentence provides value. A minor reduction could improve conciseness.
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 the output schema exists, the description covers purpose, usage, behavioral notes, and parameter details comprehensively. Sibling distinctions and limitations are addressed. The description leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the tool description fully explains all three parameters: case_id format with example, page defaults, and page_size defaults and max. This provides essential meaning the schema lacks.
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 a case's full docket sheet including case info and list of documents. It distinguishes from the sibling docketbird_get_case, which provides only metadata. The verb 'get' and resource 'docket sheet' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (when user wants the docket sheet or before downloading documents) and when not to use (for parties/attorneys, use docketbird_ask_litigation_graph). It also notes that for case metadata alone, use docketbird_get_case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral trait 'Changes rarely; safe to cache' beyond the annotations (readOnlyHint, idempotentHint, etc.). It also notes the data is live from the API, giving a complete picture of freshness and cacheability. No contradictions with annotations.
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 front-loaded with the primary purpose, uses bullet points for usage guidance, and every sentence adds relevant information. It is concise without being terse.
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 an output schema, the description fully covers what the tool does, when to use it, and how to interpret and apply the results. No gaps remain.
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 tool has zero parameters, so baseline is 4. The description adds value by explaining the output structure (federal + state systems with names and court counts) and how to use the returned identifiers with docketbird_list_courts.
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 lists every court system DocketBird covers, specifying the federal system and state court systems with human-readable names and court counts. It distinguishes from sibling tools like docketbird_list_courts by explicitly mentioning how to use a court_system_id to browse courts within a system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' section with concrete scenarios: discovering state-court coverage and getting identifiers to browse courts. It also references docketbird_list_courts as the follow-up tool, providing clear context and differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), it discloses the lack of pagination and potential 504 timeout for large dockets, and clarifies that it only searches metadata not full text.
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?
Well-organized with a clear first sentence, bulleted usage guidance, a notable caveat, and a parameter list. Every sentence adds value without redundancy.
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 output schema exists, return values are covered. The description explains scope, limitations, and parameter details, fully addressing the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the Args section explains each parameter's purpose, defaults, and constraints (e.g., page_size max 50).
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 finds docket entries in one case matching metadata (title/description), distinguishing itself from the sibling fulltext search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (e.g., filings titled a certain way in a known case) and when-not-to-use (full text search), naming the alternative tool.
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:

[![docketbird-mcp MCP server](https://glama.ai/mcp/servers/JustlyAI/docketbird-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JustlyAI/docketbird-mcp)

Score Badge

Copy to your README.md:

[![docketbird-mcp MCP server](https://glama.ai/mcp/servers/JustlyAI/docketbird-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JustlyAI/docketbird-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/JustlyAI/docketbird-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server