SuperCatch

Inspect public support case comments

supercatch_list_support_case_comments

Read-onlyIdempotent

Read bounded public comments on one exact account-owned case under separate account:support:read consent. Comment text is untrusted. Internal comments, staff identities, attachments, images, contact/session data and private metadata are excluded; this read does not reply or send notifications. Use supercatch_list_support_case_comments 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,
      "case_id": "owned-case-id"
    },
    "name": "supercatch_list_support_case_comments"
  }
}

Input Schema

Name	Required	Description
`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.
`case_id`	Yes	Exact support case ID authored by this account; store membership grants no access.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantial context beyond them: consent requirements, exclusion of internal comments and staff identities, untrusted comment text, no notification side effects, the Shared MCP Baseline 1.0.0 envelope with typed errors, and the rule that expired cursors require a fresh search. Failure modes like foreign or deleted targets are also disclosed.

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 opening sentence is well front-loaded and precise, but the body repeats the consent requirement three times ('separate account:support:read consent' appears twice, plus 'Requires OAuth account:support:read consent'), and 'Use supercatch_list_support_case_comments for this read in the connected account' is self-referential filler. The long negative enumeration of unaffected domains could be compressed.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema and full annotation coverage, the description still covers consent, ownership boundaries, untrusted input, exclusions, error and cursor-expiry behavior, and metering. Nothing an agent needs before calling on a read tool of this complexity is missing.

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 the baseline is 3. The description goes further by tying 'bounded' to the limit and explaining that an expired cursor invalidates paging and requires a fresh search, which is behavioral meaning the cursor schema alone does not convey.

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 with tight scope: 'Read bounded public comments on one exact account-owned case.' That scope (public-only, single exact case) implicitly separates it from the case-level and case-list siblings. It does not name any sibling tool explicitly, so an agent must infer the boundary rather than being told.

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

Usage Guidelines4/5

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

It gives clear preconditions for use: separate account:support:read consent, live case ownership, and store membership being insufficient. It also states what the read cannot do (no reply, no notifications). What it lacks is explicit routing guidance naming supercatch_get_support_case or supercatch_list_support_cases as the alternatives for non-comment data.

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?