Pawsitive Future Pawsitive FutureDeveloper docs

patch_support_by_id

Changes data · you confirm first

Calls PATCH /api/support/{id} as the signed-in person · REST reference

Update a support case, or drive it through a status transition

Platform-staff only (requirePlatformStaff). Dispatches on the body rather than a single generic setter, so each transition keeps the DAL's own guard: assignedTo present -> assignSupportCase; status: RESOLVED (with resolution) -> resolveSupportCase; status: CLOSED -> closeSupportCase (only from RESOLVED); status: REOPENED (with reason) -> reopenSupportCase (only from CLOSED); otherwise a field-level updateSupportCase (title/description/priority/category/ metadata — this mutation does not accept status or assignedTo).

Arguments

ArgumentTypeDescription
idpathstringrequired
bodyJSONobjectThe request body, as a JSON object. Its fields are listed below.

Fields of body

FieldTypeDescription
assignedTostring
categorystring
descriptionstring
metadataobject
priority"LOW" | "MEDIUM" | "HIGH" | "CRITICAL"
reasonstringRequired when status is REOPENED.
resolutionstringRequired when status is RESOLVED.
status"RESOLVED" | "CLOSED" | "REOPENED"
titlestring

Example call

A client sends this over the MCP session; Claude and other agents build it for you. The values are placeholders — the shape is real.

json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "patch_support_by_id",
    "arguments": {
      "id": "string",
      "body": {
        "assignedTo": "string",
        "category": "string",
        "description": "string",
        "metadata": {},
        "priority": "LOW",
        "reason": "string",
        "resolution": "string",
        "status": "RESOLVED",
        "title": "string"
      }
    }
  }
}
Confirmation
The client shows the person the exact request and waits. Nothing runs until they tick Make this change. See Reading and changing.

Result

On success (HTTP 200) the tool returns one text item holding the API's JSON, pretty-printed.

The updated support case.

json
{
  "caseNumber": "string",
  "createdAt": "2026-01-15T12:00:00Z",
  "description": "string",
  "id": "11111111-1111-4111-8111-111111111111",
  "metadata": {},
  "priority": "LOW",
  "status": "OPEN",
  "submittedBy": "string",
  "title": "string",
  "type": "string",
  "updatedAt": "2026-01-15T12:00:00Z",
  "assignedTo": "string",
  "assignedToName": "string",
  "createdByName": "string"
}

Fields

FieldTypeDescription
assignedTostring
assignedToNamestring
caseNumberstring
createdAtstring (date-time)
createdByNamestring
descriptionstring
idstring (uuid)
metadataobject
priority"LOW" | "MEDIUM" | "HIGH" | "CRITICAL"
relatedEntitystring
relatedEntityIdstring
resolvedAtstring (date-time)
status"OPEN" | "IN_PROGRESS" | "RESOLVED" | "CLOSED" | "PENDING" | "REOPENED"
submittedBystring
titlestring
typestring
updatedAtstring (date-time)

When it fails

A failed call returns isError: true with the API's message as text. A change the person declines, or lets time out, also comes back this way and nothing changes.

400

A status transition was requested without its required field, the DAL's own validation refused the change (its sentence), or the id is not a UUID (the generic message).

403

The caller is not platform staff.

404

No support case with that id, or it is not in a state the transition allows — the DAL's NOT_FOUND, carrying its sentence.

What the model is shown

This is the tool exactly as the server lists it in tools/list. The description starts with the REST call it makes.

json
{
  "name": "patch_support_by_id",
  "description": "PATCH /api/support/{id} — Platform-staff only (`requirePlatformStaff`). Dispatches on the body rather than a single generic setter, so each transition keeps the DAL's own guard: `assignedTo` present -> `assignSupportCase`; `status: RESOLVED` (with `resolution`) -> `resolveSupportCase`; `status: CLOSED` -> `closeSupportCase` (only from RESOLVED); `status: REOPENED` (with `reason`) -> `reopenSupportCase` (only from CLOSED); otherwise a field-level `updateSupportCase` (title/description/priority/category/ metadata — this mutation does not accept `status` or `assignedTo`).\n\nThis changes data. The person is asked to confirm it before it runs, and nothing happens if they decline.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "id": {
        "type": "string"
      },
      "body": {
        "type": "string",
        "description": "The JSON request body: { assignedTo: string; category: string; description: string; metadata: object; priority: one of \"LOW\" | \"MEDIUM\" | \"HIGH\" | \"CRITICAL\"; reason: string (Required when status is REOPENED.); resolution: string (Required when status is RESOLVED.); status: one of \"RESOLVED\" | \"CLOSED\" | \"REOPENED\"; title: string }"
      }
    },
    "required": [
      "id"
    ]
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true,
    "idempotentHint": false,
    "openWorldHint": false
  }
}