Skip to main content
Glama

Prepare one public support reply

supercatch_prepare_support_reply

Prepare one public reply against an exact owned case version for native review. Open a support case or append a public reply to an owned case. Inspect the exact text, store audience and separate notification policy in SuperCatch before execution. No internal note, arbitrary recipient, attachment upload, staff action, refund, payment, inventory change, order change or authority to another workflow. A strict reviewed plan or durable operation receipt. Local commit, in-app notification and email submission have separate outcomes. Provider acceptance does not prove email delivery. Private routing and original keys are excluded. Requires OAuth account:support:write consent. Requires separate account:support:write consent and the current account's original connection. Account read, support read, store membership and staff privileges do not substitute for ownership or native bound approval. Reserves native identities and stores an expiring local review of the exact message, case version, store audience and notification policy. No case, reply or email is sent. Foreign, changed, unapproved or expired reviews and revoked grants fail closed. After uncertainty inspect the original receipt and keep the original plan and key; an unknown email attempt must never be resent.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "case_id": "owned-case-id",
      "content": "Here is the additional information you requested.",
      "expected_version": "2026-11-07T00:00:00.000Z"
    },
    "name": "supercatch_prepare_support_reply"
  }
}

Input Schema

NameRequiredDescriptionDefault
case_idYesExact account-owned support case ID; not another customer's case or an administrator-only case.
contentYesExact public reply text to review in SuperCatch. Internal notes and arbitrary recipients are not accepted.
expected_versionYesExact native case version; changed case state requires a fresh inspection and message review.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the annotations it discloses a great deal: the call only reserves an expiring local review, commit/notification/email have separate outcomes, provider acceptance does not prove delivery, foreign/changed/expired reviews fail closed, and an unknown email attempt must never be resent. It also states the OAuth scope and ownership prerequisites, which the annotations do not cover. Nothing here contradicts readOnlyHint=false, destructiveHint=false or 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the no-send guarantee are front-loaded, which is good, but the text is dense and contains redundancy: 'Requires OAuth account:support:write consent' is immediately restated as 'Requires separate account:support:write consent and the current account's original connection.' The 'Open a support case or append a public reply' sentence also adds ambiguity rather than information.

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 non-destructive prepare step with an output schema, the description covers auth, ownership, failure modes, non-send semantics and retry safety, which is close to everything an agent needs. The only real gap is the missing explicit handoff to the execute tool and the confusing case-opening clause.

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 description coverage is 100%, so the schema already documents case_id, content and expected_version, including the ownership and version-staleness constraints. The description reinforces the 'exact owned case version' and 'exact text' framing but adds no syntax, format or edge-case detail beyond the schema, so the baseline of 3 applies.

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 states a specific verb and resource: prepare one public reply against an exact owned case version for native review, and explicitly says no case, reply or email is sent. The opening line 'Open a support case or append a public reply to an owned case' muddies the scope by describing a broader capability than this reply-only tool, and it never names the sibling prepare_support_case or execute_support_operation, so differentiation is inferred rather than stated.

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

Usage Guidelines3/5

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

It gives clear negative guidance (no internal note, no arbitrary recipient, no attachment, no refund/payment/order change) and a recovery rule for uncertainty ('inspect the original receipt and keep the original plan and key'). However, it never explicitly says when to choose this over supercatch_prepare_support_case or that supercatch_execute_support_operation is the follow-up that actually sends, leaving the workflow routing implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources