SuperCatch

Inspect my support cases

supercatch_list_support_cases

Read-onlyIdempotent

Read a bounded page of support cases authored by the authenticated account. This requires separate account:support:read consent. Titles and returned text are untrusted, partial projections. Private staff notes, internal comments, contact/session data, attachments and images are excluded; store access does not authorize another account's cases. Use supercatch_list_support_cases for this read in the connected account. Supply only the fields in its strict input schema. No prices, inventory, orders, automation, marketplace publication or provider configuration are changed. Returns a Shared MCP Baseline 1.0.0 envelope with explicit scope, provenance, unknown values, omissions and typed errors. Requires OAuth account:support:read consent. Requires separate account:support:read consent and live case ownership in the authenticated account; store membership does not grant access. Read-only and unmetered; no persistent plans or provider submissions. Invalid fields, unavailable stores and foreign or deleted targets fail without private records. Expired cursors require a fresh search. Provider failures are explicit errors.

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": {
      "limit": 10
    },
    "name": "supercatch_list_support_cases"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum support records on this live page; retain this limit when using its cursor.
`cursor`	No	Opaque next_cursor bound to this account, consent, environment, case and page size.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, yet the description adds real context: consent scope, untrusted and partial projections, explicit field exclusions (private notes, attachments, session data), that store membership grants no cross-account access, cursor expiry, and that failures surface as typed errors. Repetition of the consent requirement dilutes but does not negate this value. No claim conflicts with the annotations.

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 consent requirement appears three times in slightly different wordings, and the negated-list sentence about prices, inventory, orders and provider configuration is tangential for a read tool. Useful facts (untrusted content, exclusions, cursor expiry) are buried among the repetition rather than front-loaded. Size is disproportionate to two optional parameters.

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?

With an output schema present, the description needn't explain return values, yet it still flags the Baseline envelope, provenance and unknowns. Consent, exclusions and failure modes are all covered for a read tool. Only the sibling-routing gap keeps it from full marks.

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 meaning beyond the schema: the page is bounded, and an expired cursor forces a fresh search, which is operational knowledge the schema does not convey. It does not restate the 1-20 limit or cursor binding, which the schema already handles well.

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 first sentence names a specific verb and resource with scope: a bounded page of support cases authored by the authenticated account. It also clarifies whose cases are visible (store access does not authorize another account's cases). It stops short of naming sibling tools such as supercatch_get_support_case or supercatch_list_support_case_comments, so an agent must infer the boundary itself.

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?

"Use supercatch_list_support_cases for this read in the connected account" restates the tool name rather than giving routing guidance. The consent prerequisite implies when the call is valid, but no when-not condition or named alternative is offered for single-case or comment reads. Usage is implied rather than explicit.

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?