Squish

Reopen my case

reopen_my_case

Reopen one of the customer's OWN support tickets (Salesforce Cases) that was closed — use when a previously-resolved issue has come back or was never actually fixed. Two-step usage REQUIRED: (1) call with confirm:false to look up the ticket and preview which one will be reopened — read the ticket number and subject back; (2) ONLY after the user confirms, call with confirm:true to reopen it. Puts the ticket back in the support queue (Status → New). If the ticket is already open, this is a no-op. Pass the ticket number exactly as shown by list_my_cases.

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": {
      "ticketNumber": "<ticketNumber>"
    },
    "name": "reopen_my_case"
  }
}

Input Schema

Name	Required	Description	Default
`confirm`	No	false (default) returns a preview; true reopens the ticket. Pass true ONLY after explicit user confirmation.
`ticketNumber`	Yes	The ticket / case number to reopen, as shown by list_my_cases (e.g. "00001040").

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description adds the real behavioral detail: the confirm:false preview step, the requirement to read the ticket number and subject back, the Status → New transition, and the no-op on already-open tickets. The no-op note is a specific condition rather than a contradiction of idempotentHint=false.

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?

Front-loads the purpose, then the required two-step flow, then the side effects and edge case. Every sentence carries operational information; nothing is redundant with the title or 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?

For a two-parameter mutation with no output schema, the description covers the confirmation protocol, the state change, the no-op case, and how to source the ticket number. An agent has everything needed to call it safely and 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 workflow meaning to confirm (preview vs. actual reopen, and that true must follow explicit user confirmation) and constrains ticketNumber to the exact value shown by list_my_cases. That is genuine value beyond the 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 ('Reopen one of the customer's OWN support tickets (Salesforce Cases) that was closed') and scopes it to the caller's own cases, which cleanly separates it from close_my_case and list_my_cases. An agent can identify the operation without opening 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger condition ('a previously-resolved issue has come back or was never actually fixed'), a mandatory two-step procedure, and the edge case where the ticket is already open (no-op). It also points to list_my_cases for obtaining the ticket number, so the alternative path is named.

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

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