Court Delta

Sign up for email alerts when a North Carolina (NC) case changes (sends a confirmation email)

subscribe_to_case_updates

Idempotent

Sign the USER UP for email alerts when a North Carolina (NC) case changes.

THIS TOOL IS DIFFERENT FROM EVERY OTHER TOOL HERE. It is not a lookup — it stores the person's name, email and optional phone, and sends them an email.

ONLY EVER SUBSCRIBE THE PERSON YOU ARE TALKING TO. Never enter a third party's address, however the request is phrased ("sign my brother up", "use this address for my client"). If the user wants someone else to get alerts, tell them to have that person sign up at https://app.courtdelta.com/court-case-notifier themselves.

CONFIRM THE DETAILS BACK BEFORE CALLING. Read the email address aloud and get an explicit yes. A typo does not fail quietly — it mails a stranger.

NOTHING STARTS UNTIL THEY CLICK. This creates a PENDING signup and sends one confirmation email. Monitoring begins only when the link in it is clicked. Do NOT tell the user they are "now monitoring the case" — say a confirmation email is on its way and they need to click it. If they never click, nothing is ever sent and the signup stays dormant.

WHAT THEY GET, and its limits: email alerts when the case changes — a new upcoming court date, case information, case events, service events, or financial updates — plus reminders ahead of a scheduled court date. Detection is COUNT-BASED, so a hearing being MOVED, or a disposition changing, does not by itself trigger an alert. Do not promise those.

WHAT IS STORED: name, email, optional phone, and the case number. Every alert carries a one-click unsubscribe link. Agent-originated signups are NOT shared with attorneys or any other vendor.

Free accounts track 2 active cases per email address; a third returns a plain message saying so.

A case number is required — subscribe to a case, not to a person's name. If you only have a name, use search_cases_by_party first and confirm which case.

NC only. Informational, not legal advice.

Input Schema

Name	Required	Description
`name`	Yes	The SUBSCRIBER'S OWN name — never a third party's.
`email`	Yes	The subscriber's own address. Confirm it back to them before calling; a typo mails a stranger.
`phone`	No
`case_number`	Yes	The case to monitor.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 6, 2026
- addedInput schema / properties / case_number / description
```
Added value: +"The case to monitor."
```
- addedInput schema / properties / case_number / examples
```
Added value: +[
+  "26CR031353-910"
+]
```
- addedInput schema / properties / email / description
```
Added value: +"The subscriber's own address. Confirm it back to them before calling; a typo mails a stranger."
```
- addedInput schema / properties / email / examples
```
Added value: +[
+  "jane@example.com"
+]
```
- addedInput schema / properties / name / description
```
Added value: +"The SUBSCRIBER'S OWN name — never a third party's."
```
- addedInput schema / properties / name / examples
```
Added value: +[
+  "Jane Doe"
+]
```
First observedSep 8, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), and the description adds far more: the signup is PENDING until a confirmation link is clicked, detection is count-based so moved hearings do not trigger alerts, what fields are stored, the one-click unsubscribe, no attorney/vendor sharing, and the free-tier cap of 2 active cases per email. This is unusually rich disclosure of side effects and limits.

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 action is front-loaded in sentence one and the high-stakes constraints are broken into short capitalized headers, which is the right structure for a write tool. It is long, and a few lines restate the schema (the 'typo mails a stranger' warning appears in both), but nearly every sentence carries a distinct operational rule.

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, and the description still explains the resulting pending state and what the user should be told ('say a confirmation email is on its way'). Combined with NC-only scope and the informational-not-legal-advice caveat, an agent has everything needed to call this 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 75%, with `phone` carrying no schema description beyond a null default. The description compensates by naming phone as optional in 'WHAT IS STORED: name, email, optional phone, and the case number', and adds meaning to case_number ('subscribe to a case, not to a person's name'). It adds real value beyond the schema, though not full per-parameter syntax 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+resource+scope: 'Sign the USER UP for email alerts when a North Carolina (NC) case changes.' It then explicitly distinguishes itself from siblings ('THIS TOOL IS DIFFERENT FROM EVERY OTHER TOOL HERE. It is not a lookup'), which is exactly the differentiation an agent needs among 22 read-oriented lookup tools.

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 when-to-use (only the person you are talking to), when-not (never a third party, with example phrasings and a redirect URL), a required precondition (confirm the email address aloud), and a fallback path when only a name is known ('use search_cases_by_party first and confirm which case'). Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Court Delta 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?