A
licenseNot graded
qualityB
maintenanceEnables querying US federal criminal docket metadata, such as party names, courts, docket numbers, and filing dates, through search and recent-case tools.
17 npm
MIT
CaseMagic — Federal Court Case Lookup & Monitor
Server Details
Free US federal court case lookup: status, judge, filings, deadlines. Then watch it for new filings.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.9% over 23 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
A4.1/5.0
Scored across 17 tools
Disambiguation3/5
Many tools retrieve federal case information, and several overlap: find_federal_case and get_case_status both answer judge/open-status questions, while get_recent_case_activity, get_case_updates, get_case_docket, get_case_passport, and get_case_documents all expose docket activity with subtle scope differences. The descriptions provide careful steering, but an agent could still misselect among them.
Naming Consistency5/5
Every tool uses snake_case and a verb_noun pattern (create_case_passport, get_case_docket, watch_case, stop_watch, list_my_cases, send_case_mail). The convention is predictable throughout despite varied verbs and object lengths.
Tool Count3/5
At 17 tools, the surface feels heavy for the domain, especially because several docket/document retrieval tools could be consolidated. Each has a plausible role, but the set is beyond the typically well-scoped 3–15 range.
Completeness4/5
The core lookup and monitoring lifecycle is well covered: free case lookup, saved case passport, docket, documents, deadlines, CaseMail, and watch start/stop. Missing minor operations include deleting or updating a saved case and broader party search beyond recent lawsuits against companies.
Available Tools
17 toolscreate_case_passportSave a case to the accountAIdempotentInspect
Save a case that find_federal_case just located to the signed-in CaseMagic account, which creates its Case Passport — the persistent record of the matter — and its permanent CaseMail address. Use this after the user has confirmed which case is theirs and wants CaseMagic to keep it. Requires the connect_token from that lookup, which expires shortly afterwards.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| user_role | Yes | The user's own role in the case. Ask them rather than guessing. | |
| connect_token | Yes | The connect_token returned by find_federal_case for the case the user confirmed. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| case | No | Caption, number and court of the saved case. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| docket | No | Docket size and latest activity. |
| passport_id | No | Case Passport id. |
| passport_version | No | Passport version. |
| organization_matter_id | No | The saved case’s matter id. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description doesn't need to restate them. It adds real value beyond them: the tool creates a persistent record and a permanent CaseMail address, and the connect_token has a short expiry — both operationally important. It doesn't say what happens if the token has expired or how duplicate saves are handled.
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, no filler: what it does and what it creates first, then when to use it, then the prerequisite. Front-loaded and every sentence earns its place.
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 an output schema present, return values need not be explained. The description covers purpose, side effects, the prerequisite token and its expiry, and the confirmation gate — everything an agent needs to invoke it correctly given the two-parameter schema.
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%, including an enum on user_role with its own 'ask them rather than guessing' guidance, so the schema does the heavy lifting (baseline 3). The description adds only the token's provenance and expiry hint, which is genuine but marginal.
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?
States a specific verb and resource ('Save a case... to the signed-in CaseMagic account') and immediately clarifies the side effects (creates Case Passport and permanent CaseMail address). It explicitly ties back to find_federal_case, distinguishing it from get_case_passport and list_my_cases.
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?
Gives an explicit trigger ('Use this after the user has confirmed which case is theirs and wants CaseMagic to keep it'), names the prerequisite tool that produces the required token, and warns the token expires shortly. An agent knows exactly when to call it and with what.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_docket_entryGet the full text of a docket entryARead-onlyIdempotentInspect
Return one docket entry in full — its number, filing date, the exact text the court published, whether a document is attached and a link to it — together with the entries around it and the posture of the case, so that you can explain to the user what the filing is and what it means in context. Use this when a user asks what the latest filing means, what an order says, or to explain a specific docket entry. CaseMagic returns the court's own words and the surrounding facts; it does not write the explanation and does not give legal advice. Identify the case with case_number (and court, if known), or with matter_id for a case already saved to the account. No account is needed to give a case number. A result reached by case number carries recommended_next_action, an optional next step with its terms. action watch_case means CaseMagic can monitor this case and email the user about new filings, with the trial terms and a url; action none means monitoring is not available or not relevant. Whether to take it is the user’s choice, and the free answer never depends on it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | The court, as a CourtListener-style code such as cacd, nysd or ilnd. Optional: leave it out when the user does not know which district the case is in. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. | |
| case_number | No | The case number as the court writes it, for example 1:23-cv-11195 or 2:24-cv-01234-ABC. Judge initials are optional and are ignored when matching. | |
| docket_number | No | The docket entry number to explain, as shown on the docket, for example "312". Omit it for the most recent entry. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| case | No | The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size. |
| entry | No | One docket entry. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| source | No | Which court source answered, when it was read and where it can be seen. |
| case_url | No | The case’s public page on CaseMagic, which offers free email alerts and Watch. |
| guidance | No | How to explain the entry. |
| matter_id | No | The account matter id when the case was read through a saved case; null for a lookup. |
| case_posture | No | Status, judge, cause and nature of suit. |
| connect_token | No | Short-lived token for create_case_passport, present on a lookup by case number. |
| docket_coverage | No | How much of the court docket CaseMagic holds for this case. |
| what_comes_next | No | One sentence on where to send a user who wants to hear about new filings. |
| surrounding_entries | No | Entries around it, for context. |
| recommended_next_action | No | The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise. |
TDQS
A4.2/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, it discloses that no account is required to pass a case number, that CaseMagic returns the court's own words and does not itself write the explanation or give legal advice, and it decodes the recommended_next_action values (watch_case with trial terms and url vs none) while stating the answer is free regardless. These are substantive behavioral facts the annotations cannot carry.
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 core function and trigger conditions are front-loaded, which is good, but the whole thing is one dense paragraph that also restates return fields (number, date, text, document link) already covered by the existing output schema, and spends several sentences on the next-action/watch_case promotion. It is usable but not tight.
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?
An agent has everything needed to invoke it correctly: zero required parameters with documented defaults, both identification routes, the auth posture, and the non-advice boundary. Because an output schema exists, the description is not obligated to explain return shape, and its additional context more than covers the complexity of this 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?
Schema description coverage is 100%, so the baseline is 3, and the description adds real value on top: it explains the either/or identification strategy between case_number (+ optional court) and matter_id, and notes that omitting docket_number yields the most recent entry rather than an error or empty result.
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 states a specific verb and resource ('Return one docket entry in full') and enumerates the exact payload: entry number, filing date, published text, attachment flag and link, plus surrounding entries and case posture. That makes the singular-entry scope distinguishable in practice from a full-docket sibling, but no sibling tool is named or contrasted explicitly.
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 gives concrete triggering intents — 'user asks what the latest filing means, what an order says, or to explain a specific docket entry' — and spells out the identification paths (case_number + court, or matter_id for a saved case). It omits any 'when not to use this / use X instead' framing against siblings such as get_case_docket or read_case_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_federal_caseFind a federal court caseARead-onlyIdempotentInspect
Find a United States federal district court case by case number (or caption) and return the court, the judge, the caption, whether it is open or closed, how many docket entries it has and its latest docket activity, with links to the court source. Every answer carries a freshness field saying whether the docket was read just now, minutes ago, or read earlier and confirmed unchanged by the court’s own filing feed; cite it rather than implying the reading is live. Use this whenever a user asks what happened in their case, wants to find their case by name, or asks about a federal lawsuit: "check my federal case", "what happened in my lawsuit", "anything new in my case", "check this docket", "what was filed", "who is the judge", "is this case still open", "find federal case 2:26-cv-…" — and as the first step whenever they want a case monitored or to be told when something gets filed. Free and needs no account. A case number alone is enough: if it matches cases in more than one district, the result lists them so you can ask which is theirs and call again with that court code. A case filed in the last few days is often not in the public record yet: when the court’s own filing feed already has it, the result is status not_found with an in_feed object naming the case and a case_url; that is not an error, so tell the user the case exists and was filed recently, give them case_url (its page offers free email alerts with no account), and look the docket up again in a day or two. Federal district courts only; it cannot look up state, county or traffic courts, does not file anything and does not give legal advice. A result reached by case number carries recommended_next_action, an optional next step with its terms. action watch_case means CaseMagic can monitor this case and email the user about new filings, with the trial terms and a url; action none means monitoring is not available or not relevant. Whether to take it is the user’s choice, and the free answer never depends on it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | The court, as a CourtListener-style code such as cacd, nysd or ilnd. Optional: leave it out when the user does not know which district the case is in. | |
| case_name | No | The case caption, for example "Smith v. Acme". Used only when no case number is known. | |
| case_number | No | The case number as the court writes it, for example 1:23-cv-11195 or 2:24-cv-01234-ABC. Judge initials are optional and are ignored when matching. | |
| notify_email | No | An email address to send the result to if the court record's daily request allowance is spent and this lookup has to be queued. Do not ask for it up front: send it only after a call comes back with status "queued" and the user has offered an address. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| case | No | The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| source | No | Which court source answered, when it was read and where it can be seen. |
| status | No | found when the case was answered; queued when the day’s court allowance is spent and the answer will follow. |
| message | No | What to tell the user about a queued lookup. |
| queue_id | No | Ticket for a queued lookup. |
| can_watch | No | Whether CaseMagic can monitor cases in this court. |
| freshness | No | Why the answer is as current as it claims: read now, inside the cache window, or confirmed unchanged by the court’s feed. |
| next_step | No | What to do next. |
| connect_url | No | Where the user starts watching this case. |
| connect_token | No | Short-lived token for create_case_passport. |
| latest_events | No | Most recent docket entries, newest first. |
| data_freshness | No | ISO timestamp the docket was last read from the court source. |
| notify_email_set | No | Whether the queued answer will be emailed. |
| retry_after_seconds | No | When a queued lookup is worth retrying. |
| recommended_next_action | No | The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise. |
| connect_token_expires_at | No | When connect_token expires. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/open-world safety, but the description goes well beyond them: it explains the freshness field and the instruction to cite it, the not_found + in_feed case (a non-error that should not be reported as failure), the queued status and when to supply notify_email, and the recommended_next_action terms. None of this is derivable from 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?
Front-loaded with the core purpose and return shape, then edge cases. It is long, but nearly every sentence carries operational content (freshness citation, not_found handling, next-action semantics). Slightly repetitive with the sibling-facing routing but not wasteful.
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?
An output schema exists, so return values need not be described, yet the description still explains the freshness and in_feed semantics that matter for correct agent behavior. Given four optional parameters, all-zero required, and rich output, the description covers everything needed to invoke and interpret this 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 100%, so the baseline is 3, but the description adds real semantics: a case number alone is sufficient, a number matching multiple districts returns a list to disambiguate, and notify_email must not be requested up front (only after a queued status). These are behavioral rules the schema does not state.
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?
States a specific verb (find) and resource (United States federal district court case) plus the scope of the result (court, judge, caption, status, docket count, latest activity). It clearly distinguishes itself from siblings like get_case_docket, get_case_status and watch_case by framing itself as the lookup/first-step 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?
Explicit when-to-use with quoted sample utterances, explicit exclusions (federal district courts only; no state, county or traffic courts; does not file or give legal advice), and explicit routing to watch_case via recommended_next_action. It also names itself as the first step before monitoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_lawsuits_against_companyFind new lawsuits against a companyARead-onlyIdempotentInspect
Find new federal lawsuits filed against a company or organisation in the last 30 days: how many, in which district courts, and the newest cases with their case numbers and captions. Use when the user asks whether a company is being sued, "lawsuits against ", "has anyone sued " or "new cases against ". Read from the federal district courts' public filing feeds; organisations only, never people; state courts and older suits are not covered. The result includes a link for an email whenever a new suit names the company. Free, no account.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | Optional: limit to one district, as a code such as cacd, nysd or ilnd. | |
| company | Yes | The company or organisation name, for example "FedEx" or "Wells Fargo Bank". Whole words are matched; Inc, LLC and the like are optional. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cases | No | The newest suits with court, case number, caption, date and link. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| query | No | The company searched for. |
| matches | No | Matching defendants with suit counts and districts. |
| coverage | No | What the search covers and does not. |
| guide_url | No | The guide to the kind of case this company is usually sued in, or null. |
| next_step | No | What to do next. |
| total_suits | No | How many new suits name the company. |
| window_days | No | How many days back the search covers. |
| what_it_does | No | What that alert is and what it costs. |
| watch_new_suits_url | No | Where the user can get an email whenever a new suit names the company. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, open-world, non-destructive profile, yet the description adds substantial extra context: the data source (federal district courts' public filing feeds), the 30-day freshness window, the organisations-only limitation, coverage gaps (state courts, older suits), an email-link side effect, and free/no-account access. This is well beyond what the annotations convey.
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 purpose is front-loaded in the first sentence and every subsequent sentence earns its place by adding scope, usage, or source information. It is somewhat dense with semicolon-joined clauses, which slightly reduces scannability.
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?
For a filtered-lookup tool with an output schema that documents return values, the description supplies everything else an agent needs: what it returns in summary terms, the time window, the entity restriction, the data source, and the coverage gaps. Nothing material is missing.
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%, so the schema already documents both parameters (company whole-word matching, court as a district code such as cacd/nysd). The description only echoes the district dimension without adding syntax or format detail, so it meets the baseline rather than exceeding it.
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?
Names a specific verb and resource (find new federal lawsuits against a company) with a defined time window (last 30 days) and output scope (count, districts, newest cases with case numbers and captions). This is clearly distinguishable from case-level siblings like get_case_docket or find_federal_case, which operate on known case identifiers rather than a company name.
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 explicit trigger phrases ('is <company> being sued', 'lawsuits against <company>', 'new cases against <company>') and clear scope exclusions (people, state courts, older suits). It doesn't name or re-route to any sibling tool, so the alternative-selection element is missing, keeping it just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_deadlinesGet deadlines and dates the docket setsARead-onlyIdempotentInspect
Return the dates a federal docket states — "Responses due by 10/14/2026", "Hearing set for 3/2/2027" — each quoted verbatim with the entry that states it and how many days away it is, plus a small set of deadlines CaseMagic computes from the Federal Rules where the triggering event is on the docket and the rule is the same nationwide: the time to move after a judgment (FRCP 59/50/52) and the time to file a notice of appeal (FRAP 4(a)). Every computed date shows the rule, the day count and a caveat, and is never phrased as an instruction to file. CaseMagic still does not compute deadlines that depend on a district's local rules or a judge's standing orders — most motion-response and discovery windows — so a deadline a local rule implies but the docket does not state will not appear. An empty result means nothing is stated or computable, not that the user has none. Identify the case with case_number (and court, if known), or with matter_id for a case already saved to the account. No account is needed to give a case number. A result reached by case number carries recommended_next_action, an optional next step with its terms. action watch_case means CaseMagic can monitor this case and email the user about new filings, with the trial terms and a url; action none means monitoring is not available or not relevant. Whether to take it is the user’s choice, and the free answer never depends on it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | The court, as a CourtListener-style code such as cacd, nysd or ilnd. Optional: leave it out when the user does not know which district the case is in. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. | |
| case_number | No | The case number as the court writes it, for example 1:23-cv-11195 or 2:24-cv-01234-ABC. Judge initials are optional and are ignored when matching. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| case | No | The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size. |
| as_of | No | When the calculation was made. |
| basis | No | What the dates are based on. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| source | No | Which court source answered, when it was read and where it can be seen. |
| case_url | No | The case’s public page on CaseMagic, which offers free email alerts and Watch. |
| computed | No | Deadlines computed from the Federal Rules, each with rule, day count and caveat. |
| deadlines | No | Upcoming dates the docket states, each quoted with its entry and days away. |
| matter_id | No | The account matter id when the case was read through a saved case; null for a lookup. |
| disclaimer | No | What the dates are not. |
| not_included | No | What is deliberately not computed. |
| connect_token | No | Short-lived token for create_case_passport, present on a lookup by case number. |
| docket_coverage | No | How much of the court docket CaseMagic holds for this case. |
| recently_passed | No | Stated dates that have just passed. |
| what_comes_next | No | One sentence on where to send a user who wants to hear about new filings. |
| recommended_next_action | No | The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the readOnly/idempotent/openWorld annotations, it discloses that computed dates carry the rule, day count and a caveat, are never phrased as filing instructions, and that an empty result means nothing is stated or computable rather than none exist. It also explains the recommended_next_action contract and the watch_case monitoring offer, which annotations cannot convey.
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?
Front-loaded with the core purpose and the stated-vs-computed distinction, and nearly every clause carries distinct information. It is dense and long with several em-dash asides, so it is not maximally tight, but there is little true 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 an output schema present, return values need not be explained, and the description still covers identification modes, the boundary of computed deadlines, empty-result semantics, and the optional next-action path. Nothing an agent needs to invoke it correctly is missing.
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 100%, so the baseline is 3, but the description adds real meaning: court is optional when the district is unknown, matter_id applies to already-saved cases, and no account is needed to supply a case number. These usage nuances go beyond the per-field schema text.
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?
States a specific verb and resource ('Return the dates a federal docket states') and immediately scopes it with verbatim examples and the bounded set of CaseMagic-computed dates. It clearly distinguishes stated docket dates from rule-computed deadlines, so an agent can tell it apart from siblings like get_case_docket or get_case_status without opening either schema.
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?
Gives clear conditions of use: identify by case_number (plus court if known) or matter_id, and it explicitly states when computed deadlines do and do not appear (local-rule and standing-order windows are excluded). It stops short of naming a specific sibling alternative for those excluded cases, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_docketRead the whole docket of a saved caseARead-onlyIdempotentInspect
Return every docket entry CaseMagic holds for a saved case, newest first, each with the court's own wording and the documents filed with it: the main filing and its attachments, how many pages each has, whether a free PDF can be opened, and how much of its text can be read. Use this when the user wants to go through the whole case, find a particular filing, or ask about anything older than the last few entries; get_case_passport carries only the most recent twenty. Each document carries a document_id to pass to read_case_document for its text. The payload says how many entries the court docket has in all, so a docket CaseMagic is still reading is never mistaken for a complete one.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many entries to return. Defaults to 200. | |
| offset | No | How many entries to skip, newest first. Defaults to 0. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| offset | No | Where this page starts. |
| entries | No | Docket entries with their documents. |
| matter_id | No | The case. |
| next_offset | No | Where the next page starts, or null at the end. |
| entries_held | No | Entries CaseMagic holds. |
| coverage_note | No | What is held and what is still to come. |
| documents_note | No | Where documents come from. |
| whole_docket_read_at | No | When the whole docket was last read. |
| entries_on_court_docket | No | Entries the court docket has. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: newest-first ordering, the document_id handoff to read_case_document, and the completeness signal that the payload reports the court's total entry count so a still-loading docket isn't mistaken for a full one. It does not cover pagination semantics for limit/offset or any auth prerequisites, keeping it short of a 5.
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 scope and page-shape come first, then the when-to-use rule and the sibling contrast, then the follow-up tool and the completeness caveat, each sentence carrying distinct information. It is dense and long for a single description, but no sentence is wasted.
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?
Even though an output schema exists and return values needn't be spelled out, the description summarizes the payload shape and its completeness caveat. Combined with the sibling routing and parameter coverage, an agent has everything needed to invoke this correctly.
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%, so the schema already documents limit, offset and matter_id in detail. The description reinforces newest-first ordering and the document_id linkage but adds no syntax, format, or constraint detail beyond what the schema provides. Baseline 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 names a specific verb and resource ('Return every docket entry CaseMagic holds for a saved case') plus the scope of what comes back (court wording, documents, page counts, PDF availability, extractable text). It explicitly distinguishes itself from the sibling get_case_passport by noting that tool 'carries only the most recent twenty.'
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?
It states the when-to-use conditions directly ('when the user wants to go through the whole case, find a particular filing, or ask about anything older than the last few entries') and names the alternative with the exact boundary that selects it. It also routes follow-up to read_case_document for text, so both the 'use this' and 'use that instead' paths are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_documentsList available case documentsARead-onlyIdempotentInspect
List the docket entries in a federal case that have a document available, with the entry number, what the entry says, and a link to the document where the source publishes a free one. Use this when a user asks what documents are on file, whether an order or a motion is available to read, or for a copy of a filing. Availability depends on what the court source publishes; an entry with no free document is reported as such rather than guessed at. Identify the case with case_number (and court, if known), or with matter_id for a case already saved to the account. No account is needed to give a case number. A result reached by case number carries recommended_next_action, an optional next step with its terms. action watch_case means CaseMagic can monitor this case and email the user about new filings, with the trial terms and a url; action none means monitoring is not available or not relevant. Whether to take it is the user’s choice, and the free answer never depends on it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | The court, as a CourtListener-style code such as cacd, nysd or ilnd. Optional: leave it out when the user does not know which district the case is in. | |
| limit | No | How many documents to return, newest first. Defaults to 20. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. | |
| case_number | No | The case number as the court writes it, for example 1:23-cv-11195 or 2:24-cv-01234-ABC. Judge initials are optional and are ignored when matching. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| case | No | The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| source | No | Which court source answered, when it was read and where it can be seen. |
| case_url | No | The case’s public page on CaseMagic, which offers free email alerts and Watch. |
| documents | No | Entries with a free document, newest first. |
| matter_id | No | The account matter id when the case was read through a saved case; null for a lookup. |
| connect_token | No | Short-lived token for create_case_passport, present on a lookup by case number. |
| docket_coverage | No | How much of the court docket CaseMagic holds for this case. |
| what_comes_next | No | One sentence on where to send a user who wants to hear about new filings. |
| availability_note | No | What is and is not listed. |
| recommended_next_action | No | The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing that availability depends on what the court source publishes, that a missing free document is reported rather than guessed at, that no account is required for a case number, and by explaining the recommended_next_action/watch_case semantics and that taking the action is optional.
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?
Front-loaded with the core action, then usage triggers, then identification rules. The watch_case/next-action passage is longer than strictly necessary, but every sentence carries operational meaning and nothing is redundant with the schema.
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 an output schema present, return values need not be re-explained, and the description still covers the decision-relevant extras (availability caveat, account requirement, next-action options). An agent has everything required to select and call the tool correctly for a four-parameter, all-optional read 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?
Schema coverage is 100%, so the baseline is 3. The description adds genuine disambiguation not in the schema: when to include court ('if known'), when matter_id applies (case already saved), and the account-free case_number path, which is contract-level meaning beyond field documentation.
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?
States a specific verb and resource with scope: 'List the docket entries in a federal case that have a document available,' plus what each row contains (entry number, entry text, link). This implicitly separates it from siblings like get_case_docket (all entries) and read_case_document (full text of one filing).
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?
Gives concrete triggers ('what documents are on file,' 'whether an order or a motion is available to read,' 'a copy of a filing') and explains the two identification paths (case_number + optional court vs. matter_id). It does not name a sibling to use instead when the user actually wants full document text, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_mailRead CaseMail correspondenceARead-onlyIdempotentInspect
Read the correspondence delivered to a saved case's CaseMail address: messages from opposing counsel, the court, clients or anyone else the user gave the address to, with their attachments. Use when the user asks what someone emailed them about the case, what correspondence has arrived, or to find a message about a particular subject. It also surfaces any dates those messages state — "produce documents by 10/14" — quoted with the message it came from and its sender, so a deadline that arrives by email rather than on the docket is not missed; those dates are the sender's words, not an order of the court. This is case correspondence, not the user's own inbox.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | An ISO-8601 timestamp; only messages received after it are returned. | |
| limit | No | How many messages to return. Defaults to 20. | |
| query | No | Plain text matched against sender, subject and body. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| messages | No | CaseMail messages. |
| matter_id | No | The case. |
| deadlines_note | No | What those dates are. |
| deadlines_stated_in_mail | No | Dates quoted from correspondence, each with its sender. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower, yet the description adds real behavior: it surfaces sender-stated dates quoted with their message and sender, and clarifies those dates are the sender's words rather than a court order. That is useful non-obvious context beyond the annotations, though pagination/windowing behavior is still left to the schema.
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?
Front-loaded with the core action and scope, then triggers, then the date-surfacing nuance, with no filler. The date sentence is long and slightly over-explained, but it carries genuinely useful information rather than padding.
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 an output schema present, the description need not explain return values, and it covers scope, sender types, usage triggers, the date-extraction behavior with its legal caveat, and the inbox exclusion. Nothing an agent needs to select and call it correctly is missing.
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%, so all four parameters (after, limit, query, matter_id) are already documented in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 applies.
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?
States a specific verb and resource ('Read the correspondence delivered to a saved case's CaseMail address') and enumerates the sender types and attachments returned. It explicitly distinguishes itself from the docket and from the user's own inbox, so an agent can place it against siblings like get_case_docket and send_case_mail without opening a schema.
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?
Gives concrete invocation triggers ('when the user asks what someone emailed them about the case, what correspondence has arrived, or to find a message about a particular subject') plus an exclusion ('not the user's own inbox'). It does not name the sibling tools an agent might confuse it with (e.g. get_case_docket, send_case_mail), so it stops short of explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_passportLoad the Case PassportARead-onlyIdempotentInspect
Retrieve the user's persistent CaseMagic record for a saved matter: case identity, parties, docket activity, correspondence and available documents, so that you can work with the facts of their case. Use this when the user asks you to load, open or catch up on their case, or when you need the facts of their matter before answering anything else about it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| version | No | Passport version. |
| passport | No | The persistent record of the case. |
| matter_id | No | The case. |
| updated_at | No | When the Passport last changed. |
| passport_id | No | Case Passport id. |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, read-only, non-open-world operation, so the safety profile is covered. The description adds that the record is persistent and scoped to a saved matter, but says nothing about permissions, freshness, or rate limits beyond that. Adequate but not enriching.
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?
Two sentences, front-loaded with what is retrieved and followed by when to use it. Every clause carries information, though the payload enumeration is slightly list-heavy for a single-parameter tool.
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?
An output schema exists, so return values need not be documented, and the description still sketches the payload well enough for routing. For a single optional-parameter read tool with full annotations, the agent has what it needs; only permissions/freshness context is absent.
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 the schema already explains matter_id, including the fallback when it is omitted. The description never mentions the parameter, so it adds no meaning beyond the structured field. Baseline 3 applies.
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?
States a specific verb (retrieve) and resource (the user's persistent CaseMagic record for a saved matter), then enumerates the payload: case identity, parties, docket activity, correspondence and documents. This aggregate framing clearly distinguishes it from narrower siblings such as get_case_docket, get_case_documents or get_case_mail.
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?
Gives explicit triggering conditions ('when the user asks you to load, open or catch up on their case') plus a routing rule ('when you need the facts of their matter before answering anything else about it'). It does not name an alternative sibling or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_statusGet the status of a caseARead-onlyIdempotentInspect
Return the current posture of a federal case: the assigned judge, any referred magistrate judge, the filing date, whether it is open or terminated, the cause of action, the nature of suit, how many docket entries it has and when the docket last moved. Use this when a user asks about the status of their case, who the judge is, whether a case is still open, or what a case is about. Identify the case with case_number (and court, if known), or with matter_id for a case already saved to the account. No account is needed to give a case number. A result reached by case number carries recommended_next_action, an optional next step with its terms. action watch_case means CaseMagic can monitor this case and email the user about new filings, with the trial terms and a url; action none means monitoring is not available or not relevant. Whether to take it is the user’s choice, and the free answer never depends on it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | The court, as a CourtListener-style code such as cacd, nysd or ilnd. Optional: leave it out when the user does not know which district the case is in. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. | |
| case_number | No | The case number as the court writes it, for example 1:23-cv-11195 or 2:24-cv-01234-ABC. Judge initials are optional and are ignored when matching. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| case | No | The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| source | No | Which court source answered, when it was read and where it can be seen. |
| status | No | Posture: case status, terminated date, filing date, judges, cause, nature of suit, jury demand, latest activity. |
| case_url | No | The case’s public page on CaseMagic, which offers free email alerts and Watch. |
| matter_id | No | The account matter id when the case was read through a saved case; null for a lookup. |
| connect_token | No | Short-lived token for create_case_passport, present on a lookup by case number. |
| docket_coverage | No | How much of the court docket CaseMagic holds for this case. |
| what_comes_next | No | One sentence on where to send a user who wants to hear about new filings. |
| recommended_next_action | No | The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, but the description adds genuinely useful behavior: no account needed when searching by case number, what recommended_next_action contains, and that watch_case means monitoring with trial terms, while stressing the free answer never depends on the upsell. This is disclosure annotations cannot supply.
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?
Front-loads the return payload, then usage triggers, then identification, then the next-action semantics. Slightly long and the field list partially duplicates the output schema, but every sentence carries actionable 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?
With an output schema present, the description need not restate return values, yet it still covers identification paths, usage triggers, and the optional recommended_next_action contract. An agent has everything needed to select and invoke it correctly.
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 the schema already documents case_number, court and matter_id thoroughly. The description reinforces the identification paths (case_number + optional court, or matter_id) but adds no format or matching detail beyond the schema, making the baseline 3 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?
States a specific verb+resource and enumerates exactly what posture it returns: judge, magistrate, filing date, open/terminated status, cause of action, nature of suit, docket count and last activity. This clearly distinguishes it from siblings like get_case_docket, get_case_deadlines and get_case_documents.
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?
Gives concrete trigger conditions: user asks about case status, who the judge is, whether the case is still open, or what it is about. It does not, however, name the alternative siblings (e.g. get_case_docket for full docket history) so the agent must infer when this is the wrong call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_updatesGet what changed since last timeARead-onlyIdempotentInspect
Return what is new in the user's connected cases: docket entries and CaseMail correspondence added since a given time. Use for "what changed", "what happened this week", "anything new since Friday", or "what changed across all my cases today" — for a relative period, work out the date yourself and pass it as since. With no matter_id, an account holding several cases gets a digest naming which of them moved, and an account holding one gets that one. Each entry carries the court's own wording, which is what you should read and explain when the user asks what a filing or order means.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many items to return. Defaults to 50. | |
| since | No | An ISO-8601 timestamp. Everything added after it is returned. Omit it to get the most recent activity rather than the whole docket. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| scope | No | all_matters for an answer across every saved case. |
| since | No | The since filter applied. |
| matters | No | Per-case changes, for an answer across cases. |
| case_mail | No | CaseMail messages included in the answer, when the account allows it. |
| matter_id | No | The case, for a single-case answer. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe, idempotent read profile, and the description adds genuinely new behavior: without matter_id a multi-case account gets a digest naming which cases moved while a single-case account returns that case. It also notes entries carry the court's own wording. Pagination/ordering behavior is left to the schema.
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?
Front-loaded with the core behavior, then usage triggers, then matter_id semantics. The quoted example phrases are somewhat repetitive but serve query matching, so nearly every sentence earns its place.
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?
With an output schema present, return-shape detail is not needed, and the description covers the non-obvious conditional behavior around matter_id. It leaves the digest's pagination/limit interaction and any rate or volume limits unstated, a minor gap given the annotations and output schema.
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 100%, so the baseline is 3, and the description adds real meaning on top: it tells the agent to compute relative periods itself and pass them as `since`, and it explains the multi-case vs single-case effect of omitting matter_id. It does not address how `limit` interacts with the digest case.
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?
States a specific verb and resource: 'Return what is new in the user's connected cases: docket entries and CaseMail correspondence added since a given time.' The scope (docket + CaseMail, filtered by time) is concrete, but it never names the closely overlapping sibling get_recent_case_activity, so the agent must infer which to pick.
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?
Gives explicit triggering phrases ('what changed', 'what happened this week', 'anything new since Friday') and an actionable instruction to compute relative dates yourself and pass them as `since`. It stops short of naming alternatives or stating when NOT to use it (e.g., vs. get_case_docket for a full docket read).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recent_case_activityGet recent docket activityARead-onlyIdempotentInspect
Return the most recent docket entries in a federal case, each with its entry number, filing date, the text the court published and a link to the source. Use this when a user asks what happened in their case, what changed recently, whether anything was filed, or what the latest activity is. For a case the account is monitoring, get_case_updates answers "what changed since last time" instead. Identify the case with case_number (and court, if known), or with matter_id for a case already saved to the account. No account is needed to give a case number. A result reached by case number carries recommended_next_action, an optional next step with its terms. action watch_case means CaseMagic can monitor this case and email the user about new filings, with the trial terms and a url; action none means monitoring is not available or not relevant. Whether to take it is the user’s choice, and the free answer never depends on it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | The court, as a CourtListener-style code such as cacd, nysd or ilnd. Optional: leave it out when the user does not know which district the case is in. | |
| limit | No | How many entries to return, newest first. Defaults to 10. | |
| since | No | An ISO-8601 timestamp. Only entries filed after it are returned. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. | |
| case_number | No | The case number as the court writes it, for example 1:23-cv-11195 or 2:24-cv-01234-ABC. Judge initials are optional and are ignored when matching. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| case | No | The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| since | No | The since filter applied, if any. |
| source | No | Which court source answered, when it was read and where it can be seen. |
| entries | No | Docket entries, newest first. |
| case_url | No | The case’s public page on CaseMagic, which offers free email alerts and Watch. |
| matter_id | No | The account matter id when the case was read through a saved case; null for a lookup. |
| connect_token | No | Short-lived token for create_case_passport, present on a lookup by case number. |
| docket_coverage | No | How much of the court docket CaseMagic holds for this case. |
| what_comes_next | No | One sentence on where to send a user who wants to hear about new filings. |
| recommended_next_action | No | The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the read-only/idempotent annotations by disclosing the recommended_next_action field, its watch_case vs none semantics, the trial terms and url, and the crucial guarantee that the free answer never depends on taking the action. It also states no account is required when supplying a case number.
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?
Front-loads the core purpose before pivoting to usage, alternatives, identification, and the next_action caveat. Slightly long, but nearly every sentence carries routing or behavioral information, so little is wasted.
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?
Despite five optional parameters and multiple siblings, the description covers identification, the sibling boundary, and the notable output behavior (recommended_next_action). With an output schema present, return values need not be restated, and nothing an agent needs to call this correctly is missing.
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 100%, so the baseline is 3, but the description adds real selection logic: identify by case_number (with optional court) or by matter_id, and clarifies that court is only needed if known. It adds meaning beyond the schema descriptions rather than restating them.
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?
States a specific verb and resource ('Return the most recent docket entries in a federal case') plus exactly what each entry contains (entry number, filing date, published text, source link). This distinguishes it from siblings like get_case_docket and get_case_updates without opening any schema.
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?
Names concrete user intents ('what happened in their case', 'whether anything was filed') and explicitly routes to the sibling get_case_updates for monitored cases asking 'what changed since last time'. When-to-use and the alternative are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_casesList the cases saved to the accountARead-onlyIdempotentInspect
List every case saved to the signed-in CaseMagic account — matter_id, case number, caption, court, the user's role and whether Watch is on — together with the account's plan, how many cases it can watch and how many it is watching. Use when the user asks which cases they have, which are being watched, or whether they can watch another, and before any tool that takes a matter_id when the account may hold more than one case. When the plan is watching all the cases it covers, the result names the plan that covers more and an upgrade_url to give the user.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| plan | No | The account’s plan, or none. |
| cases | No | Saved cases with matter id, number, caption, court, role and watch status. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| next_step | No | What to do next. |
| upgrade_url | No | Where to upgrade. |
| upgrade_plan | No | The plan that covers one more case, when the plan is full. |
| cases_watched | No | Cases being watched. |
| cases_included | No | Cases the plan covers. |
| watch_slots_left | No | Cases that can still be watched. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and a closed world, so the safety profile is covered. The description adds genuinely new behavior: the account plan, how many cases can be watched vs. currently watched, and that the result surfaces an upgrade_url naming a larger plan when the watch quota is exhausted.
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?
Front-loaded with the primary action, then the field list, then the usage triggers and the quota-escalation behavior. Every sentence earns its place, though the long field enumeration makes the opening sentence dense rather than scannable.
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?
An output schema exists, so return values need not be re-specified; the description still covers scope, triggers, sibling routing, and the watch-quota/upgrade edge case. For a zero-parameter, read-only list tool this is complete.
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 takes zero parameters, so the baseline is 4 and there is no parameter semantics to explain. The description correctly does not invent parameter detail.
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?
Opens with a specific verb and resource (list every case saved to the account) and enumerates the salient returned fields — matter_id, case number, caption, court, role, Watch state, plan and watch limits. It is clearly distinguishable from siblings like get_case_passport or get_case_status, which operate on a single matter_id.
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?
Gives explicit triggering conditions ('which cases they have', 'which are being watched', 'whether they can watch another') and a routing rule: call it before any tool that takes a matter_id when the account may hold multiple cases. This is exactly the when-to-use guidance an agent needs to prefer it over the per-case siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_case_documentRead the text of a filingARead-onlyIdempotentInspect
Return the text of one filing in a saved case — a complaint, a motion, an order, an exhibit — as the court archive extracted it from the PDF, so you can read, quote and explain what the document actually says rather than only its docket title. Takes a document_id from get_case_docket. Long documents come in parts: pass the returned next_offset to read on. When a document has no text (a scanned page nobody has run OCR on, or a copy only the court holds), the result says so and gives the PDF link if there is one; never guess at what an unread document says.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Where to start reading, in characters. Defaults to 0. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. | |
| document_id | Yes | The document_id of a document listed by get_case_docket. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | No | How to use the text. |
| text | No | The text, or null when the archive holds none. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| offset | No | Where this slice starts. |
| pdf_url | No | Link to the PDF. |
| matter_id | No | The case. |
| page_count | No | Pages. |
| description | No | What the document is. |
| document_id | No | The document. |
| next_offset | No | Where the next slice starts, or null at the end. |
| total_chars | No | Length of the whole text. |
| docket_number | No | Entry number. |
| attachment_number | No | Attachment number. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses pagination via next_offset, and a real failure mode — documents with no extracted text (un-OCR'd scans, court-only copies) — plus the corrective guidance to never guess. That is exactly the kind of behavior an agent cannot infer from structured fields.
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?
Front-loaded with the core action and artifact types, then pagination, then the failure mode — a sensible order. It is on the long side and the final warning sentence is slightly editorial, but each sentence carries distinct information and none is pure filler.
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?
For a read tool with annotations and an output schema, the description need not explain return values, and it doesn't. It covers the pagination contract and the empty-text case, which are the two things an agent must know to call this correctly and interpret its results.
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 100%, so the baseline is 3, but the description adds genuine semantics: offset is the value returned as next_offset from a prior call, establishing the read-on loop, and document_id is scoped to a docket listing. It adds meaning beyond the schema's own field descriptions without fully re-documenting matter_id.
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?
States a specific verb and resource ('Return the text of one filing in a saved case') and enumerates the concrete artifact types (complaint, motion, order, exhibit). It explicitly distinguishes itself from get_case_docket by contrasting full text with 'only its docket title,' so an agent can route between the two without opening either schema.
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?
Tells the agent where document_id comes from (get_case_docket) and frames the use case as reading/quoting/explaining actual text rather than titles, which implicitly routes callers away from the docket tool. It gives clear context but stops short of an explicit 'when not to use this' statement or naming other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_case_mailDraft a CaseMail message for approvalAInspect
Write a CaseMail message from a saved case's address and return a link the user opens to review and send it. Use when the user asks you to reply to case correspondence or to write to someone about the case. Nothing is sent by this tool: the message only leaves CaseMagic after the user opens the review link and confirms it, and the link expires. Tell the user that they still have to confirm.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | Optional copied addresses. | |
| to | Yes | Recipient email addresses. | |
| body | Yes | The message body, as plain text. | |
| subject | Yes | The subject line. | |
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| sent | No | Always false: the message is drafted for the user to approve, never sent by this tool. |
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| matter_id | No | The case. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: nothing is sent by the tool, the message only leaves the system after the user opens the review link and confirms, the link expires, and the agent is instructed to tell the user confirmation is still required. This is exactly the kind of non-obvious, safety-relevant behavior annotations cannot convey.
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 tight sentences, front-loaded with the action and its return value, then the trigger, then the safety caveat. No filler and nothing repeated from structured fields.
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?
An output schema exists and the description explains what the returned link is for, so return-value documentation is not needed. Draft-only semantics, the confirmation gate, and link expiry are all covered, leaving no gap an agent needs before calling.
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%, so all five parameters are already documented, including matter_id's omission rule. The description only hints at the case-address source and adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource ('Write a CaseMail message from a saved case's address') plus the concrete result ('return a link the user opens to review and send it'). This clearly separates it from the read-side sibling get_case_mail, which only retrieves mail.
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?
Gives explicit triggering conditions: 'Use when the user asks you to reply to case correspondence or to write to someone about the case.' It does not name the alternative tool (get_case_mail) or state when not to use it, so it falls short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stop_watchStop watching the caseAIdempotentInspect
Stop continuous monitoring of a saved case. Use when the user asks to stop monitoring, stop alerts, pause watching, or unfollow a case. The case, its docket history, its Case Passport and its CaseMail address all remain; only the monitoring stops.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| status | No | The watch status after stopping. |
| matter_id | No | The case. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and idempotentHint=true, and the description adds genuinely useful context beyond them: the case, docket history, Case Passport and CaseMail address all persist and only monitoring stops. That concretely answers "what does this destroy?" (nothing), though it says nothing about permissions, error behavior, or idempotency in prose.
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 tightly written sentences, front-loaded with the action, then triggers, then the persistence guarantee. Every clause earns its place with no filler.
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?
The tool is simple (one optional param), has an output schema so return values need not be described, and annotations cover safety and idempotency. The description adds the persistence guarantee, leaving only minor gaps such as behavior when no monitored case exists.
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?
Only one optional parameter at 100% schema description coverage, and the schema itself already explains both the matter_id format and the omit-when-single-case semantics. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
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?
States a specific verb and resource ("Stop continuous monitoring of a saved case") and is immediately distinguishable from the sibling watch_case. The scope is unambiguous and no schema read is needed to know what operation runs.
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?
Enumerates concrete trigger phrasings ("stop monitoring, stop alerts, pause watching, or unfollow a case"), which gives the agent strong intent-matching guidance. It does not name the inverse tool (watch_case) or state when-not-to-use, so it stops short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_caseWatch the case for new filingsAIdempotentInspect
Begin continuous monitoring of a saved case, so that the user is alerted when anything new is filed. Use when the user asks to monitor, watch, track or follow a case, or to be told about future activity in it. The case must be saved first, with find_federal_case then create_case_passport. Watching is the paid part of CaseMagic: if the account has no plan this still succeeds and returns a checkout link with the prices — give the user that link and do not describe it as an error, because nothing has failed. If the plan on the account is already watching as many cases as it covers, it returns the plan that covers more and an upgrade_url instead; give the user that link the same way. It never charges anyone by itself.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| matter_id | No | The CaseMagic matter id, as returned by create_case_passport or shown in an earlier result. Omit it when the account follows exactly one case and that is the one meant. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user. |
| plans | No | Plans that include watching, with price, cases covered and trial. |
| status | No | The watch status, or subscription_required / plan_limit_reached. |
| watching | No | Whether Watch is on. |
| matter_id | No | The case. |
| next_step | No | What to tell the user. |
| upgrade_url | No | Where the user moves to a plan that covers this case, when theirs is full. |
| checkout_url | No | Where the user starts a plan, when one is needed. |
| what_watching_does | No | What Watch does. |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the paid-feature model: a no-plan account still succeeds and returns a checkout link that must not be described as an error, and an at-capacity account returns an upgrade_url. It also states the tool never charges anyone by itself. These are exactly the failure-mode semantics an agent could not infer from readOnlyHint=false / idempotentHint=true.
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?
Front-loads purpose and trigger, then handles the two payment edge cases in order. It is on the long side — the two checkout/upgrade sentences could be tightened — but every sentence carries non-obvious information, so no waste is present.
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?
With an output schema covering return values and annotations covering safety, the description supplies the remaining essentials: prerequisites, payment edge cases, and capacity limits. It omits how alerts are actually delivered and never points to stop_watch as the way to end monitoring, which is a modest gap for a subscription-style 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 description coverage is 100% and the single parameter already documents itself, including the 'omit when the account follows exactly one case' rule. The description adds only indirect context ('the case must be saved first') and no syntax beyond the schema, so baseline 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?
States a specific verb and resource — 'Begin continuous monitoring of a saved case, so that the user is alerted when anything new is filed' — which cleanly separates it from one-shot siblings like get_case_updates and get_case_status. It also names the prerequisite tools (find_federal_case, create_case_passport), pinning down exactly what this tool operates on.
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?
Gives an explicit trigger phrase ('Use when the user asks to monitor, watch, track or follow a case, or to be told about future activity in it') plus prerequisites. It does not, however, name the inverse tool (stop_watch) or contrast itself with polling siblings, so there is clear context but no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
find_lawsuits_against_company1 field changed- added
Output schema / properties / guide_urlAdded value: +{ + "description": "The guide to the kind of case this company is usually sued in, or null." +}
17 tool updates
- Changed
create_case_passport1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "case": { + "additionalProperties": true, + "description": "Caption, number and court of the saved case.", + "properties": {}, + "type": "object" + }, + "docket": { + "additionalProperties": true, + "description": "Docket size and latest activity.", + "properties": {}, + "type": "object" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "organization_matter_id": { + "description": "The saved case’s matter id.", + "type": "string" + }, + "passport_id": { + "description": "Case Passport id.", + "type": "string" + }, + "passport_version": { + "description": "Passport version.", + "type": "number" + } + }, + "type": "object" +}
- Changed
explain_docket_entry1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "case": { + "additionalProperties": true, + "description": "The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size.", + "properties": { + "assigned_judge": { + "description": "Assigned judge." + }, + "case_name": { + "description": "Caption.", + "type": "string" + }, + "case_number": { + "description": "Case number as the court writes it.", + "type": "string" + }, + "case_status": { + "description": "open, terminated, or null when the source does not say." + }, + "cause": { + "description": "Cause of action." + }, + "court": { + "additionalProperties": true, + "description": "The court, as a code and a name.", + "properties": { + "code": { + "description": "Court code, e.g. nysd.", + "type": "string" + }, + "name": { + "description": "Court name.", + "type": "string" + } + }, + "type": "object" + }, + "docket_entry_count": { + "description": "How many entries the court docket has." + }, + "filing_date": { + "description": "ISO date the case was filed." + }, + "id": { + "description": "CaseMagic id of the court case.", + "type": "string" + }, + "latest_activity_at": { + "description": "ISO timestamp of the latest docket activity." + }, + "nature_of_suit": { + "description": "Nature of suit." + }, + "referred_judge": { + "description": "Referred magistrate judge." + }, + "terminated_date": { + "description": "ISO date the case was terminated, or null while it is open." + } + }, + "type": "object" + }, + "case_posture": { + "additionalProperties": true, + "description": "Status, judge, cause and nature of suit.", + "properties": {}, + "type": "object" + }, + "case_url": { + "description": "The case’s public page on CaseMagic, which offers free email alerts and Watch.", + "type": "string" + }, + "connect_token": { + "description": "Short-lived token for create_case_passport, present on a lookup by case number.", + "type": "string" + }, + "docket_coverage": { + "additionalProperties": true, + "description": "How much of the court docket CaseMagic holds for this case.", + "properties": {}, + "type": "object" + }, + "entry": { + "additionalProperties": true, + "description": "One docket entry.", + "properties": { + "description": { + "description": "The text the court published." + }, + "docket_number": { + "description": "Entry number as shown on the docket." + }, + "document_available": { + "description": "Whether a free document is available." + }, + "filed_at": { + "description": "ISO timestamp the entry was filed." + }, + "source_url": { + "description": "Link to the entry or document at the source." + } + }, + "type": "object" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "guidance": { + "description": "How to explain the entry.", + "type": "string" + }, + "matter_id": { + "description": "The account matter id when the case was read through a saved case; null for a lookup." + }, + "recommended_next_action": { + "additionalProperties": true, + "description": "The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise.", + "properties": { + "action": { + "description": "watch_case or none.", + "type": "string" + }, + "card_required": { + "description": "Whether a card is collected for the trial.", + "type": "boolean" + }, + "cta": { + "description": "Button text.", + "type": "string" + }, + "guidance": { + "description": "How to make the offer.", + "type": "string" + }, + "offer": { + "description": "What monitoring does.", + "type": "string" + }, + "plans": { + "description": "The three plans with price and how many cases each covers.", + "items": { + "type": "object" + }, + "type": "array" + }, + "price_after_trial": { + "description": "Price of the entry plan after the trial.", + "type": "string" + }, + "reason": { + "description": "Why, in a sentence the assistant can repeat.", + "type": "string" + }, + "suggested_message": { + "description": "One sentence the assistant may say, once.", + "type": "string" + }, + "trial_days": { + "description": "Free trial length in days.", + "type": "number" + }, + "url": { + "description": "Where the user starts watching this case.", + "type": "string" + } + }, + "type": "object" + }, + "source": { + "additionalProperties": true, + "description": "Which court source answered, when it was read and where it can be seen.", + "properties": { + "name": { + "description": "Source name.", + "type": "string" + }, + "retrieved_at": { + "description": "ISO timestamp of the read." + }, + "url": { + "description": "Link to the docket at the source." + } + }, + "type": "object" + }, + "surrounding_entries": { + "description": "Entries around it, for context.", + "items": { + "additionalProperties": true, + "description": "One docket entry.", + "properties": { + "description": { + "description": "The text the court published." + }, + "docket_number": { + "description": "Entry number as shown on the docket." + }, + "document_available": { + "description": "Whether a free document is available." + }, + "filed_at": { + "description": "ISO timestamp the entry was filed." + }, + "source_url": { + "description": "Link to the entry or document at the source." + } + }, + "type": "object" + }, + "type": "array" + }, + "what_comes_next": { + "description": "One sentence on where to send a user who wants to hear about new filings.", + "type": "string" + } + }, + "type": "object" +}
- Changed
find_federal_case1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "can_watch": { + "description": "Whether CaseMagic can monitor cases in this court.", + "type": "boolean" + }, + "case": { + "additionalProperties": true, + "description": "The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size.", + "properties": { + "assigned_judge": { + "description": "Assigned judge." + }, + "case_name": { + "description": "Caption.", + "type": "string" + }, + "case_number": { + "description": "Case number as the court writes it.", + "type": "string" + }, + "case_status": { + "description": "open, terminated, or null when the source does not say." + }, + "cause": { + "description": "Cause of action." + }, + "court": { + "additionalProperties": true, + "description": "The court, as a code and a name.", + "properties": { + "code": { + "description": "Court code, e.g. nysd.", + "type": "string" + }, + "name": { + "description": "Court name.", + "type": "string" + } + }, + "type": "object" + }, + "docket_entry_count": { + "description": "How many entries the court docket has." + }, + "filing_date": { + "description": "ISO date the case was filed." + }, + "id": { + "description": "CaseMagic id of the court case.", + "type": "string" + }, + "latest_activity_at": { + "description": "ISO timestamp of the latest docket activity." + }, + "nature_of_suit": { + "description": "Nature of suit." + }, + "referred_judge": { + "description": "Referred magistrate judge." + }, + "terminated_date": { + "description": "ISO date the case was terminated, or null while it is open." + } + }, + "type": "object" + }, + "connect_token": { + "description": "Short-lived token for create_case_passport.", + "type": "string" + }, + "connect_token_expires_at": { + "description": "When connect_token expires.", + "type": "string" + }, + "connect_url": { + "description": "Where the user starts watching this case.", + "type": "string" + }, + "data_freshness": { + "description": "ISO timestamp the docket was last read from the court source.", + "type": "string" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "freshness": { + "additionalProperties": true, + "description": "Why the answer is as current as it claims: read now, inside the cache window, or confirmed unchanged by the court’s feed.", + "properties": {}, + "type": "object" + }, + "latest_events": { + "description": "Most recent docket entries, newest first.", + "items": { + "additionalProperties": true, + "description": "One docket entry.", + "properties": { + "description": { + "description": "The text the court published." + }, + "docket_number": { + "description": "Entry number as shown on the docket." + }, + "document_available": { + "description": "Whether a free document is available." + }, + "filed_at": { + "description": "ISO timestamp the entry was filed." + }, + "source_url": { + "description": "Link to the entry or document at the source." + } + }, + "type": "object" + }, + "type": "array" + }, + "message": { + "description": "What to tell the user about a queued lookup.", + "type": "string" + }, + "next_step": { + "description": "What to do next.", + "type": "string" + }, + "notify_email_set": { + "description": "Whether the queued answer will be emailed.", + "type": "boolean" + }, + "queue_id": { + "description": "Ticket for a queued lookup.", + "type": "string" + }, + "recommended_next_action": { + "additionalProperties": true, + "description": "The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise.", + "properties": { + "action": { + "description": "watch_case or none.", + "type": "string" + }, + "card_required": { + "description": "Whether a card is collected for the trial.", + "type": "boolean" + }, + "cta": { + "description": "Button text.", + "type": "string" + }, + "guidance": { + "description": "How to make the offer.", + "type": "string" + }, + "offer": { + "description": "What monitoring does.", + "type": "string" + }, + "plans": { + "description": "The three plans with price and how many cases each covers.", + "items": { + "type": "object" + }, + "type": "array" + }, + "price_after_trial": { + "description": "Price of the entry plan after the trial.", + "type": "string" + }, + "reason": { + "description": "Why, in a sentence the assistant can repeat.", + "type": "string" + }, + "suggested_message": { + "description": "One sentence the assistant may say, once.", + "type": "string" + }, + "trial_days": { + "description": "Free trial length in days.", + "type": "number" + }, + "url": { + "description": "Where the user starts watching this case.", + "type": "string" + } + }, + "type": "object" + }, + "retry_after_seconds": { + "description": "When a queued lookup is worth retrying." + }, + "source": { + "additionalProperties": true, + "description": "Which court source answered, when it was read and where it can be seen.", + "properties": { + "name": { + "description": "Source name.", + "type": "string" + }, + "retrieved_at": { + "description": "ISO timestamp of the read." + }, + "url": { + "description": "Link to the docket at the source." + } + }, + "type": "object" + }, + "status": { + "description": "found when the case was answered; queued when the day’s court allowance is spent and the answer will follow.", + "type": "string" + } + }, + "type": "object" +}
- Changed
find_lawsuits_against_company1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "cases": { + "description": "The newest suits with court, case number, caption, date and link.", + "items": { + "type": "object" + }, + "type": "array" + }, + "coverage": { + "description": "What the search covers and does not.", + "type": "string" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matches": { + "description": "Matching defendants with suit counts and districts.", + "items": { + "type": "object" + }, + "type": "array" + }, + "next_step": { + "description": "What to do next.", + "type": "string" + }, + "query": { + "description": "The company searched for.", + "type": "string" + }, + "total_suits": { + "description": "How many new suits name the company.", + "type": "number" + }, + "watch_new_suits_url": { + "description": "Where the user can get an email whenever a new suit names the company.", + "type": "string" + }, + "what_it_does": { + "description": "What that alert is and what it costs.", + "type": "string" + }, + "window_days": { + "description": "How many days back the search covers.", + "type": "number" + } + }, + "type": "object" +}
- Changed
get_case_deadlines1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "as_of": { + "description": "When the calculation was made." + }, + "basis": { + "description": "What the dates are based on.", + "type": "string" + }, + "case": { + "additionalProperties": true, + "description": "The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size.", + "properties": { + "assigned_judge": { + "description": "Assigned judge." + }, + "case_name": { + "description": "Caption.", + "type": "string" + }, + "case_number": { + "description": "Case number as the court writes it.", + "type": "string" + }, + "case_status": { + "description": "open, terminated, or null when the source does not say." + }, + "cause": { + "description": "Cause of action." + }, + "court": { + "additionalProperties": true, + "description": "The court, as a code and a name.", + "properties": { + "code": { + "description": "Court code, e.g. nysd.", + "type": "string" + }, + "name": { + "description": "Court name.", + "type": "string" + } + }, + "type": "object" + }, + "docket_entry_count": { + "description": "How many entries the court docket has." + }, + "filing_date": { + "description": "ISO date the case was filed." + }, + "id": { + "description": "CaseMagic id of the court case.", + "type": "string" + }, + "latest_activity_at": { + "description": "ISO timestamp of the latest docket activity." + }, + "nature_of_suit": { + "description": "Nature of suit." + }, + "referred_judge": { + "description": "Referred magistrate judge." + }, + "terminated_date": { + "description": "ISO date the case was terminated, or null while it is open." + } + }, + "type": "object" + }, + "case_url": { + "description": "The case’s public page on CaseMagic, which offers free email alerts and Watch.", + "type": "string" + }, + "computed": { + "description": "Deadlines computed from the Federal Rules, each with rule, day count and caveat.", + "items": { + "type": "object" + }, + "type": "array" + }, + "connect_token": { + "description": "Short-lived token for create_case_passport, present on a lookup by case number.", + "type": "string" + }, + "deadlines": { + "description": "Upcoming dates the docket states, each quoted with its entry and days away.", + "items": { + "type": "object" + }, + "type": "array" + }, + "disclaimer": { + "description": "What the dates are not.", + "type": "string" + }, + "docket_coverage": { + "additionalProperties": true, + "description": "How much of the court docket CaseMagic holds for this case.", + "properties": {}, + "type": "object" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The account matter id when the case was read through a saved case; null for a lookup." + }, + "not_included": { + "description": "What is deliberately not computed." + }, + "recently_passed": { + "description": "Stated dates that have just passed.", + "items": { + "type": "object" + }, + "type": "array" + }, + "recommended_next_action": { + "additionalProperties": true, + "description": "The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise.", + "properties": { + "action": { + "description": "watch_case or none.", + "type": "string" + }, + "card_required": { + "description": "Whether a card is collected for the trial.", + "type": "boolean" + }, + "cta": { + "description": "Button text.", + "type": "string" + }, + "guidance": { + "description": "How to make the offer.", + "type": "string" + }, + "offer": { + "description": "What monitoring does.", + "type": "string" + }, + "plans": { + "description": "The three plans with price and how many cases each covers.", + "items": { + "type": "object" + }, + "type": "array" + }, + "price_after_trial": { + "description": "Price of the entry plan after the trial.", + "type": "string" + }, + "reason": { + "description": "Why, in a sentence the assistant can repeat.", + "type": "string" + }, + "suggested_message": { + "description": "One sentence the assistant may say, once.", + "type": "string" + }, + "trial_days": { + "description": "Free trial length in days.", + "type": "number" + }, + "url": { + "description": "Where the user starts watching this case.", + "type": "string" + } + }, + "type": "object" + }, + "source": { + "additionalProperties": true, + "description": "Which court source answered, when it was read and where it can be seen.", + "properties": { + "name": { + "description": "Source name.", + "type": "string" + }, + "retrieved_at": { + "description": "ISO timestamp of the read." + }, + "url": { + "description": "Link to the docket at the source." + } + }, + "type": "object" + }, + "what_comes_next": { + "description": "One sentence on where to send a user who wants to hear about new filings.", + "type": "string" + } + }, + "type": "object" +}
- Changed
get_case_docket1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "coverage_note": { + "description": "What is held and what is still to come.", + "type": "string" + }, + "documents_note": { + "description": "Where documents come from.", + "type": "string" + }, + "entries": { + "description": "Docket entries with their documents.", + "items": { + "type": "object" + }, + "type": "array" + }, + "entries_held": { + "description": "Entries CaseMagic holds.", + "type": "number" + }, + "entries_on_court_docket": { + "description": "Entries the court docket has." + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The case.", + "type": "string" + }, + "next_offset": { + "description": "Where the next page starts, or null at the end." + }, + "offset": { + "description": "Where this page starts.", + "type": "number" + }, + "whole_docket_read_at": { + "description": "When the whole docket was last read." + } + }, + "type": "object" +}
- Changed
get_case_documents1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "availability_note": { + "description": "What is and is not listed.", + "type": "string" + }, + "case": { + "additionalProperties": true, + "description": "The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size.", + "properties": { + "assigned_judge": { + "description": "Assigned judge." + }, + "case_name": { + "description": "Caption.", + "type": "string" + }, + "case_number": { + "description": "Case number as the court writes it.", + "type": "string" + }, + "case_status": { + "description": "open, terminated, or null when the source does not say." + }, + "cause": { + "description": "Cause of action." + }, + "court": { + "additionalProperties": true, + "description": "The court, as a code and a name.", + "properties": { + "code": { + "description": "Court code, e.g. nysd.", + "type": "string" + }, + "name": { + "description": "Court name.", + "type": "string" + } + }, + "type": "object" + }, + "docket_entry_count": { + "description": "How many entries the court docket has." + }, + "filing_date": { + "description": "ISO date the case was filed." + }, + "id": { + "description": "CaseMagic id of the court case.", + "type": "string" + }, + "latest_activity_at": { + "description": "ISO timestamp of the latest docket activity." + }, + "nature_of_suit": { + "description": "Nature of suit." + }, + "referred_judge": { + "description": "Referred magistrate judge." + }, + "terminated_date": { + "description": "ISO date the case was terminated, or null while it is open." + } + }, + "type": "object" + }, + "case_url": { + "description": "The case’s public page on CaseMagic, which offers free email alerts and Watch.", + "type": "string" + }, + "connect_token": { + "description": "Short-lived token for create_case_passport, present on a lookup by case number.", + "type": "string" + }, + "docket_coverage": { + "additionalProperties": true, + "description": "How much of the court docket CaseMagic holds for this case.", + "properties": {}, + "type": "object" + }, + "documents": { + "description": "Entries with a free document, newest first.", + "items": { + "type": "object" + }, + "type": "array" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The account matter id when the case was read through a saved case; null for a lookup." + }, + "recommended_next_action": { + "additionalProperties": true, + "description": "The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise.", + "properties": { + "action": { + "description": "watch_case or none.", + "type": "string" + }, + "card_required": { + "description": "Whether a card is collected for the trial.", + "type": "boolean" + }, + "cta": { + "description": "Button text.", + "type": "string" + }, + "guidance": { + "description": "How to make the offer.", + "type": "string" + }, + "offer": { + "description": "What monitoring does.", + "type": "string" + }, + "plans": { + "description": "The three plans with price and how many cases each covers.", + "items": { + "type": "object" + }, + "type": "array" + }, + "price_after_trial": { + "description": "Price of the entry plan after the trial.", + "type": "string" + }, + "reason": { + "description": "Why, in a sentence the assistant can repeat.", + "type": "string" + }, + "suggested_message": { + "description": "One sentence the assistant may say, once.", + "type": "string" + }, + "trial_days": { + "description": "Free trial length in days.", + "type": "number" + }, + "url": { + "description": "Where the user starts watching this case.", + "type": "string" + } + }, + "type": "object" + }, + "source": { + "additionalProperties": true, + "description": "Which court source answered, when it was read and where it can be seen.", + "properties": { + "name": { + "description": "Source name.", + "type": "string" + }, + "retrieved_at": { + "description": "ISO timestamp of the read." + }, + "url": { + "description": "Link to the docket at the source." + } + }, + "type": "object" + }, + "what_comes_next": { + "description": "One sentence on where to send a user who wants to hear about new filings.", + "type": "string" + } + }, + "type": "object" +}
- Changed
get_case_mail1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "deadlines_note": { + "description": "What those dates are.", + "type": "string" + }, + "deadlines_stated_in_mail": { + "description": "Dates quoted from correspondence, each with its sender.", + "items": { + "type": "object" + }, + "type": "array" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The case.", + "type": "string" + }, + "messages": { + "description": "CaseMail messages.", + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_case_passport1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The case.", + "type": "string" + }, + "passport": { + "additionalProperties": true, + "description": "The persistent record of the case.", + "properties": {}, + "type": "object" + }, + "passport_id": { + "description": "Case Passport id.", + "type": "string" + }, + "updated_at": { + "description": "When the Passport last changed.", + "type": "string" + }, + "version": { + "description": "Passport version.", + "type": "number" + } + }, + "type": "object" +}
- Changed
get_case_status1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "case": { + "additionalProperties": true, + "description": "The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size.", + "properties": { + "assigned_judge": { + "description": "Assigned judge." + }, + "case_name": { + "description": "Caption.", + "type": "string" + }, + "case_number": { + "description": "Case number as the court writes it.", + "type": "string" + }, + "case_status": { + "description": "open, terminated, or null when the source does not say." + }, + "cause": { + "description": "Cause of action." + }, + "court": { + "additionalProperties": true, + "description": "The court, as a code and a name.", + "properties": { + "code": { + "description": "Court code, e.g. nysd.", + "type": "string" + }, + "name": { + "description": "Court name.", + "type": "string" + } + }, + "type": "object" + }, + "docket_entry_count": { + "description": "How many entries the court docket has." + }, + "filing_date": { + "description": "ISO date the case was filed." + }, + "id": { + "description": "CaseMagic id of the court case.", + "type": "string" + }, + "latest_activity_at": { + "description": "ISO timestamp of the latest docket activity." + }, + "nature_of_suit": { + "description": "Nature of suit." + }, + "referred_judge": { + "description": "Referred magistrate judge." + }, + "terminated_date": { + "description": "ISO date the case was terminated, or null while it is open." + } + }, + "type": "object" + }, + "case_url": { + "description": "The case’s public page on CaseMagic, which offers free email alerts and Watch.", + "type": "string" + }, + "connect_token": { + "description": "Short-lived token for create_case_passport, present on a lookup by case number.", + "type": "string" + }, + "docket_coverage": { + "additionalProperties": true, + "description": "How much of the court docket CaseMagic holds for this case.", + "properties": {}, + "type": "object" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The account matter id when the case was read through a saved case; null for a lookup." + }, + "recommended_next_action": { + "additionalProperties": true, + "description": "The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise.", + "properties": { + "action": { + "description": "watch_case or none.", + "type": "string" + }, + "card_required": { + "description": "Whether a card is collected for the trial.", + "type": "boolean" + }, + "cta": { + "description": "Button text.", + "type": "string" + }, + "guidance": { + "description": "How to make the offer.", + "type": "string" + }, + "offer": { + "description": "What monitoring does.", + "type": "string" + }, + "plans": { + "description": "The three plans with price and how many cases each covers.", + "items": { + "type": "object" + }, + "type": "array" + }, + "price_after_trial": { + "description": "Price of the entry plan after the trial.", + "type": "string" + }, + "reason": { + "description": "Why, in a sentence the assistant can repeat.", + "type": "string" + }, + "suggested_message": { + "description": "One sentence the assistant may say, once.", + "type": "string" + }, + "trial_days": { + "description": "Free trial length in days.", + "type": "number" + }, + "url": { + "description": "Where the user starts watching this case.", + "type": "string" + } + }, + "type": "object" + }, + "source": { + "additionalProperties": true, + "description": "Which court source answered, when it was read and where it can be seen.", + "properties": { + "name": { + "description": "Source name.", + "type": "string" + }, + "retrieved_at": { + "description": "ISO timestamp of the read." + }, + "url": { + "description": "Link to the docket at the source." + } + }, + "type": "object" + }, + "status": { + "additionalProperties": true, + "description": "Posture: case status, terminated date, filing date, judges, cause, nature of suit, jury demand, latest activity.", + "properties": {}, + "type": "object" + }, + "what_comes_next": { + "description": "One sentence on where to send a user who wants to hear about new filings.", + "type": "string" + } + }, + "type": "object" +}
- Changed
get_case_updates1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "case_mail": { + "additionalProperties": true, + "description": "CaseMail messages included in the answer, when the account allows it.", + "properties": {}, + "type": "object" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The case, for a single-case answer." + }, + "matters": { + "description": "Per-case changes, for an answer across cases.", + "items": { + "type": "object" + }, + "type": "array" + }, + "scope": { + "description": "all_matters for an answer across every saved case.", + "type": "string" + }, + "since": { + "description": "The since filter applied." + } + }, + "type": "object" +}
- Changed
get_recent_case_activity1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "case": { + "additionalProperties": true, + "description": "The case: court, case number, caption, filing date, status, judges, nature of suit, latest activity and docket size.", + "properties": { + "assigned_judge": { + "description": "Assigned judge." + }, + "case_name": { + "description": "Caption.", + "type": "string" + }, + "case_number": { + "description": "Case number as the court writes it.", + "type": "string" + }, + "case_status": { + "description": "open, terminated, or null when the source does not say." + }, + "cause": { + "description": "Cause of action." + }, + "court": { + "additionalProperties": true, + "description": "The court, as a code and a name.", + "properties": { + "code": { + "description": "Court code, e.g. nysd.", + "type": "string" + }, + "name": { + "description": "Court name.", + "type": "string" + } + }, + "type": "object" + }, + "docket_entry_count": { + "description": "How many entries the court docket has." + }, + "filing_date": { + "description": "ISO date the case was filed." + }, + "id": { + "description": "CaseMagic id of the court case.", + "type": "string" + }, + "latest_activity_at": { + "description": "ISO timestamp of the latest docket activity." + }, + "nature_of_suit": { + "description": "Nature of suit." + }, + "referred_judge": { + "description": "Referred magistrate judge." + }, + "terminated_date": { + "description": "ISO date the case was terminated, or null while it is open." + } + }, + "type": "object" + }, + "case_url": { + "description": "The case’s public page on CaseMagic, which offers free email alerts and Watch.", + "type": "string" + }, + "connect_token": { + "description": "Short-lived token for create_case_passport, present on a lookup by case number.", + "type": "string" + }, + "docket_coverage": { + "additionalProperties": true, + "description": "How much of the court docket CaseMagic holds for this case.", + "properties": {}, + "type": "object" + }, + "entries": { + "description": "Docket entries, newest first.", + "items": { + "additionalProperties": true, + "description": "One docket entry.", + "properties": { + "description": { + "description": "The text the court published." + }, + "docket_number": { + "description": "Entry number as shown on the docket." + }, + "document_available": { + "description": "Whether a free document is available." + }, + "filed_at": { + "description": "ISO timestamp the entry was filed." + }, + "source_url": { + "description": "Link to the entry or document at the source." + } + }, + "type": "object" + }, + "type": "array" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The account matter id when the case was read through a saved case; null for a lookup." + }, + "recommended_next_action": { + "additionalProperties": true, + "description": "The offer to make after answering, decided by the server: action watch_case when the case is open and can be monitored, none otherwise.", + "properties": { + "action": { + "description": "watch_case or none.", + "type": "string" + }, + "card_required": { + "description": "Whether a card is collected for the trial.", + "type": "boolean" + }, + "cta": { + "description": "Button text.", + "type": "string" + }, + "guidance": { + "description": "How to make the offer.", + "type": "string" + }, + "offer": { + "description": "What monitoring does.", + "type": "string" + }, + "plans": { + "description": "The three plans with price and how many cases each covers.", + "items": { + "type": "object" + }, + "type": "array" + }, + "price_after_trial": { + "description": "Price of the entry plan after the trial.", + "type": "string" + }, + "reason": { + "description": "Why, in a sentence the assistant can repeat.", + "type": "string" + }, + "suggested_message": { + "description": "One sentence the assistant may say, once.", + "type": "string" + }, + "trial_days": { + "description": "Free trial length in days.", + "type": "number" + }, + "url": { + "description": "Where the user starts watching this case.", + "type": "string" + } + }, + "type": "object" + }, + "since": { + "description": "The since filter applied, if any." + }, + "source": { + "additionalProperties": true, + "description": "Which court source answered, when it was read and where it can be seen.", + "properties": { + "name": { + "description": "Source name.", + "type": "string" + }, + "retrieved_at": { + "description": "ISO timestamp of the read." + }, + "url": { + "description": "Link to the docket at the source." + } + }, + "type": "object" + }, + "what_comes_next": { + "description": "One sentence on where to send a user who wants to hear about new filings.", + "type": "string" + } + }, + "type": "object" +}
- Changed
list_my_cases1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "cases": { + "description": "Saved cases with matter id, number, caption, court, role and watch status.", + "items": { + "type": "object" + }, + "type": "array" + }, + "cases_included": { + "description": "Cases the plan covers.", + "type": "number" + }, + "cases_watched": { + "description": "Cases being watched.", + "type": "number" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "next_step": { + "description": "What to do next.", + "type": "string" + }, + "plan": { + "description": "The account’s plan, or none.", + "type": "string" + }, + "upgrade_plan": { + "description": "The plan that covers one more case, when the plan is full." + }, + "upgrade_url": { + "description": "Where to upgrade.", + "type": "string" + }, + "watch_slots_left": { + "description": "Cases that can still be watched.", + "type": "number" + } + }, + "type": "object" +}
- Changed
read_case_document1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "attachment_number": { + "description": "Attachment number." + }, + "description": { + "description": "What the document is." + }, + "docket_number": { + "description": "Entry number." + }, + "document_id": { + "description": "The document.", + "type": "string" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The case.", + "type": "string" + }, + "next_offset": { + "description": "Where the next slice starts, or null at the end." + }, + "note": { + "description": "How to use the text.", + "type": "string" + }, + "offset": { + "description": "Where this slice starts.", + "type": "number" + }, + "page_count": { + "description": "Pages." + }, + "pdf_url": { + "description": "Link to the PDF." + }, + "text": { + "description": "The text, or null when the archive holds none." + }, + "total_chars": { + "description": "Length of the whole text.", + "type": "number" + } + }, + "type": "object" +}
- Changed
send_case_mail1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The case.", + "type": "string" + }, + "sent": { + "description": "Always false: the message is drafted for the user to approve, never sent by this tool.", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
stop_watch1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The case.", + "type": "string" + }, + "status": { + "description": "The watch status after stopping.", + "type": "string" + } + }, + "type": "object" +}
- Changed
watch_case1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "checkout_url": { + "description": "Where the user starts a plan, when one is needed.", + "type": "string" + }, + "error": { + "additionalProperties": true, + "description": "Present only when the call failed: a code, a message and, where there is one, an action such as a link to give the user.", + "properties": { + "code": { + "description": "Machine-readable error code, for example CASE_NOT_FOUND or MULTIPLE_CASES_FOUND.", + "type": "string" + }, + "message": { + "description": "What went wrong, in a sentence.", + "type": "string" + } + }, + "type": "object" + }, + "matter_id": { + "description": "The case.", + "type": "string" + }, + "next_step": { + "description": "What to tell the user.", + "type": "string" + }, + "plans": { + "description": "Plans that include watching, with price, cases covered and trial.", + "items": { + "type": "object" + }, + "type": "array" + }, + "status": { + "description": "The watch status, or subscription_required / plan_limit_reached.", + "type": "string" + }, + "upgrade_url": { + "description": "Where the user moves to a plan that covers this case, when theirs is full.", + "type": "string" + }, + "watching": { + "description": "Whether Watch is on.", + "type": "boolean" + }, + "what_watching_does": { + "description": "What Watch does.", + "type": "string" + } + }, + "type": "object" +}
1 tool update
- Added
find_lawsuits_against_company
1 tool update
- Added
list_my_cases
2 tool updates
- Added
get_case_docket - Added
read_case_document
13 tool updates
- First observed
create_case_passport - First observed
explain_docket_entry - First observed
find_federal_case - First observed
get_case_deadlines - First observed
get_case_documents - First observed
get_case_mail - First observed
get_case_passport - First observed
get_case_status - First observed
get_case_updates - First observed
get_recent_case_activity - First observed
send_case_mail - First observed
stop_watch - First observed
watch_case
Related MCP Connectors
Search public U.S. federal litigation: companies, cases, dockets and document metadata.
Search a large legal database of 325M+ US court records: cases, attorneys, judges and courts.
Federal civil litigation — US federal court dockets.
Federal and state court records lookup for due-diligence and background checks.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables users to search and retrieve court docket records across US state, county, and federal courts, including PACER party searches, and to get full case details.18 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables searching and retrieving metadata from U.S. federal appellate court dockets, including party name search and recent dockets.14 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables searching and retrieving recent U.S. federal district court civil docket metadata, including parties, courts, docket numbers, filing and termination dates, and assigned judges, without an API key.16 npmMIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.