MedBillAnalyzer

Delete a case

delete_case

DestructiveIdempotent

Delete everything held about a case, immediately and permanently. The record is removed, not flagged, and it cannot be recovered afterwards — not by us either. This is the promise the privacy policy makes, and it needs no account. It does need the delete token issued when the case was created: reading a case and destroying it are deliberately different capabilities.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "case_id": "<case_id>",
      "delete_token": "<delete_token>"
    },
    "name": "delete_case"
  }
}

Input Schema

Name	Required	Description	Default
`case_id`	Yes	The case id returned by check_medical_bill (it starts with `case_`).
`delete_token`	Yes	The one-time token returned by check_medical_bill. Deleting is a separate capability from reading on purpose: a case link can end up in a browser history or a forwarded message, and whoever finds it should not be able to destroy the record.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 13, 2026
- addedInput schema / properties / case_id / description
```
Added value: +"The case id returned by check_medical_bill (it starts with `case_`)."
```
First observedOct 3, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description goes well beyond them: deletion is immediate, unrecoverable by anyone including the service, not a soft flag, and requires a token despite needing no account. Those are exactly the facts an agent needs before committing an irreversible action.

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?

Irreversibility is front-loaded and the token requirement follows logically, with no sentence off-topic. There is some rhetorical flourish ('not by us either', the privacy-policy aside) that could be trimmed without loss.

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 destructive two-parameter tool with full schema coverage and no output schema, nothing material is missing: irreversibility, required credential, and the non-soft-delete semantics are all stated.

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 both parameters already document their origin and format, so the schema does the heavy lifting. The description restates the delete-token requirement and adds the rationale for why it is separate from read access, which is mild reinforcement rather than new parameter-level meaning.

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 opens with a specific verb+resource+scope: delete everything held about a case, immediately and permanently, with the record removed rather than flagged. That is clearly distinct from reading (get_case) or exporting (export_case), so an agent can select it without inspecting the 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?

It establishes the precondition (the delete token issued at case creation) and the division of capabilities between reading and destroying, which steers an agent away from treating a plain case link as a delete handle. It stops short of naming an alternative tool for the read-only path, so the routing guidance is strong but implicit rather than explicit.

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

All MedBillAnalyzer 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?