CaseMagic — Federal Court Case Lookup & Monitor

List the cases saved to the account

list_my_cases

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

changedOutput 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"
+}

AddedOct 4, 2026

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.

All CaseMagic — Federal Court Case Lookup & Monitor tools Inspect

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.

Resources

Need Help?