CaseMagic — Federal Court Case Lookup & Monitor

Watch the case for new filings

watch_case

Idempotent

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "watch_case"
  }
}

Input 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

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

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

First observedSep 24, 2026

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.

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?