Squish

Close my case

close_my_case

Close one of the customer's OWN support tickets (Salesforce Cases) when they say the issue is resolved. Two-step usage REQUIRED: (1) call with confirm:false to look up the ticket and preview which one will be closed — read the ticket number and subject back to the user; (2) ONLY after the user explicitly says yes, call with confirm:true to close it. Pass the ticket number exactly as shown by list_my_cases (e.g. "00001040"). Staff can reopen a closed ticket if needed, but never close a ticket the user hasn't clearly said is resolved.

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": "close_my_case"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the real burden and does so well: it discloses the preview-then-commit safety gate and that closure is reversible ('Staff can reopen a closed ticket'), which explains why the operation is flagged non-destructive. It stops short of covering failure modes (already-closed tickets, invalid numbers) or permission requirements, which is why it is not a 5.

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 purpose, then the required sequence, then the constraint, so an agent can act after the first two sentences. It is dense with actionable content, though the numbered protocol is slightly verbose for a two-parameter tool and the 'read the ticket number and subject back' instruction edges into agent-scripting rather than tool description.

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?

For a mutating, two-parameter tool with no output schema, the definition covers the critical decision points: when to act, how to confirm, and how to source the identifier, and it implicitly describes the preview's return content (ticket number and subject). Missing are what happens on an invalid or already-closed ticket, a minor gap given the tool's simplicity.

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 baseline is 3, but the description adds genuine meaning: it defines confirm:false as a preview rather than a no-op, ties confirm:true to an explicit user 'yes', and specifies that ticketNumber must be passed exactly as shown by list_my_cases with a concrete example. This sequencing semantics is not derivable from the schema alone.

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 ('Close one of the customer's OWN support tickets (Salesforce Cases)') and scopes it to the user's own cases, which separates it from admin-facing siblings. The mention of 'own' plus the ticket-number format from list_my_cases lets an agent distinguish it from list_my_cases and reopen_my_case without opening a 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 two-step protocol (confirm:false preview, then confirm:true only after explicit user consent) and an explicit prohibition: 'never close a ticket the user hasn't clearly said is resolved.' It also names where the ticket number comes from (list_my_cases), leaving nothing to inference.

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?