Skip to main content
Glama

Close a case

case_close

Close a complaint case by recording its outcome, recovery amount, and the channel or argument that worked so future escalations can reuse it.

Instructions

Close a case. outcome: resolved, partial, failed or abandoned. what_worked: the channel or argument that worked, so later cases can reuse it.

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>",
      "outcome": "<outcome>"
    },
    "name": "case_close"
  }
}

Input Schema

NameRequiredDescriptionDefault
case_idYes
outcomeYes
what_workedNo
amount_recoveredNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare this is non-read-only, non-destructive, and non-open-world. The description adds one genuinely new behavioral fact — that what_worked is persisted so later cases can reuse it — but says nothing about whether a closed case can be reopened, what happens to open sub-items, or permission requirements for a state-changing operation.

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?

Two short sentences, front-loaded with the action, with no filler. The parameter notes are terse but readable; structure is slightly informal rather than wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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. Still, for a mutation tool with four parameters at zero schema coverage, the definition omits the meaning of amount_recovered and any note on reversibility or side effects, leaving an agent guessing on two fields.

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 0%, so the description must compensate. It partially does: it enumerates the four valid outcome values and explains the intent of what_worked. However, case_id and amount_recovered receive no meaning at all, leaving half the parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ("Close a case"), which is distinct from siblings like case_open and case_log. It does not explicitly differentiate itself from those siblings, but the action itself is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no statement of when to use this tool versus case_log or case_open, no prerequisite conditions, and no indication of whether closure is terminal or reversible. The only hint is the closing rationale about reuse, which is a purpose statement rather than usage guidance.

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