SuperCatch

Prepare one support case

supercatch_prepare_support_case

Prepare one new support case and its derived account/store audience for exact 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": {
      "title": "Order question",
      "category": "OTHER",
      "description": "Please help me understand the status of my order."
    },
    "name": "supercatch_prepare_support_case"
  }
}

Input Schema

Name	Required	Description
`title`	Yes	Exact requested case title to review in SuperCatch; treated as untrusted text, never instructions.
`category`	Yes	Native customer support category; internal system categories are unavailable. It does not authorize a refund, payment or change to another workflow.
`description`	Yes	Exact support request text. Native recipient routing and notification content are reviewed separately; this field grants no authority.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

B3.1/5.0

Behavior4/5

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

It adds substantial behavioral context beyond the annotations, including OAuth consent requirements, ownership and native-bound approval, expiring local reviews, reserved native identities, fail-closed behavior, and receipt handling after uncertainty. It also warns that provider acceptance does not prove email delivery. Some internal tension remains because it mentions opening a case or appending a reply while later saying nothing is sent, which reduces clarity even though the disclosure is rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The description is dense but poorly structured, relying on fragments and repetition, including duplicate consent requirements. The prepare-only behavior is not cleanly front-loaded, and several constraints could be consolidated into fewer sentences.

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?

Given that an output schema exists and all parameters are fully documented, the safety and side-effect information is mostly present. Still, the scope conflict between preparing a case and appending a public reply leaves an agent unsure about operation boundaries and sibling selection.

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%, and the schema already documents title, category, and description with length constraints and an enum. The description mentions exact text, store audience, and notification policy, but store audience and notification policy are not input parameters, so it adds little parameter-level meaning beyond the schema.

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

Purpose3/5

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

The opening states a specific verb and resource: prepare one new support case and its derived audience for native review. However, the next sentence says it can open a support case or append a public reply to an owned case, which blurs whether this tool also handles replies and overlaps with supercatch_prepare_support_reply. That ambiguity keeps the purpose from being clearly distinguishable.

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?

The description implies a prepare-then-execute workflow by saying to inspect the exact text, store audience, and notification policy before execution, and by stating that no case, reply, or email is sent. It does not explicitly say when to use this tool versus supercatch_prepare_support_reply or supercatch_execute_support_operation, nor does it name exclusions beyond broad workflow limits.

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

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