Loading ToolBench
Search and retrieve US court opinions, federal dockets, judge records, citation networks, and oral arguments from CourtListener's 9M+ opinion corpus via MCP. STDIO or Streamable HTTP.
Strong foundation with well-structured tool definitions, comprehensive parameter descriptions, and clear use-case guidance. All 5 tools have detailed descriptions (150-400 chars) explaining what they do, when to use them, and API cost implications. Input schemas are complete with typed parameters and enums. However, output schemas are not explicitly documented in the source code provided, and error handling guidance is minimal. Tool names follow verb_noun convention (get_*, courtlistener_*). Descriptions are LLM-optimized with practical constraints (e.g., 'free tier supports shallow traversal'). Parameters include helpful context about rate limits and pagination behavior.
Retrieve the citation network for an opinion cluster. Supports two directions: "cited_by" (opinions that cite this one — measures precedential influence) and "citing" (opinions this one cites — reveals the authority chain relied on). This is the primary tool for tracing legal precedent chains. Note: the free tier supports shallow traversal — following 1–2 hops of a single case is practical; deep multi-hop analysis burns through the daily budget quickly.
Fetch full docket metadata and entry list for a single federal case by docket ID. Returns all available docket entries with document availability status. Documents with is_available=true have a RECAP-stored copy; others require a PACER account. Obtain docket IDs from courtlistener_search_dockets or from opinion results.
Fetch a single judicial financial disclosure with its parsed line-item categories (investments, debts, positions, income, etc.).
Fetch full biographical profile for a single judge: positions on record — judicial appointments across all courts plus non-judicial roles — education, political affiliations, and ABA ratings. The position list is paginated upstream and walked under a page bound; the response reports whether it was truncated. Obtain person IDs from courtlistener_search_judges results.
Output schemas not documented in source. Tool descriptions explain what is returned (e.g., 'returns cluster metadata plus every opinion variant'), but formal output schema definitions are not visible in the provided code. LLMs cannot plan downstream tool calls without knowing return field names and types.
Error handling guidance absent. Tools document rate limits and pagination but do not describe what errors can occur (e.g., 'invalid cluster_id', 'rate limit exceeded') or how to recover. Descriptions lack recovery hints like 'If not found, try search_opinions() first.'
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Fetch the full text and metadata for a single opinion cluster by cluster ID. A cluster groups all opinions filed in a case — majority, concurrence, dissent, and per curiam. Returns the cluster metadata (case name, court, citations, dates) plus every opinion variant with HTML and plain text. When the combined opinion text is too large to inline, the response lists each variant as a retrievable section (opinion_<id>) while keeping the cheap cluster metadata — re-call with sections:[...] to pull specific variants in full. Obtain cluster IDs from courtlistener_search_opinions, courtlistener_lookup_citation, or docket results.
courtlistener_get_financial_disclosure has minimal description (65 chars). Lacks context on when to use it, what data it reveals, or how it relates to judge lookups. Should explain: 'Fetch parsed financial disclosures for judges (investments, debts, income). Use after get_judge to analyze potential conflicts of interest.'
Parameter 'sections' in courtlistener_get_opinion lacks clear guidance on when to use it. Description mentions 'opinion_<id>' format but does not explain: when does the response return an outline vs. full text? How does the agent know which section IDs to request?
No tool composition guidance. Descriptions do not explain how tools chain together (e.g., 'search_opinions → get_opinion → get_citations → get_docket'). Agents must infer the workflow without explicit hints.