SuperCatch

Inspect one recorded collection item

supercatch_get_collection_item

Read-onlyIdempotent

Read one exact account-owned recorded catalog collection item. This does not include reference-only ownership, verify physical possession or purchase-date provenance, or expose titles, costs, notes, certificates, photos, valuations, transfers or automation data. Use supercatch_get_collection_item 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:read consent. Returns only the current verified connection; discovery cannot 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": {
      "item_id": "owned-recorded-item-id"
    },
    "name": "supercatch_get_collection_item"
  }
}

Input Schema

Name	Required	Description	Default
`item_id`	Yes	Exact recorded collection item ID belonging to this account; not a catalog, lot or seller listing ID.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, yet the description adds genuinely new behavior: OAuth account:read consent, unmetered operation, a Shared MCP Baseline 1.0.0 envelope with provenance and typed errors, and failure modes that do not leak private records. It loses a point for the sentence 'Expired cursors require a fresh search', which is irrelevant noise since the tool accepts only item_id and no cursor.

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 bloated with a long negative enumeration (titles, costs, notes, certificates, photos, valuations, transfers, automation) and generic boilerplate about prices, inventory, orders and provider configuration that no reader needs for a one-parameter read. The cursor sentence is not just verbose but irrelevant, and the opening is not front-loaded ahead of the noise.

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 a complete output schema, full annotation coverage, and a fully documented single parameter, the description supplies what structured fields cannot: auth requirement, cost model, envelope shape and explicit failure semantics. Only the misleading cursor remark keeps it from a clean fit.

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 coverage is 100% and the item_id description already excludes catalog, lot and seller listing IDs, so the schema does the heavy lifting. The description reinforces ownership ('exact account-owned') and warns to supply only schema fields, but adds no new syntax, format, or sourcing guidance for obtaining the ID.

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?

States a specific verb and resource ('Read one exact account-owned recorded catalog collection item') and adds a scope boundary, excluding reference-only ownership. It never names supercatch_list_collection_items as the contrasting sibling, so the agent must infer the singular-vs-list distinction, but the purpose itself is unambiguous.

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_get_collection_item for this read in the connected account' merely restates the tool name rather than telling the agent when to prefer it over the list tool. The exclusions ('does not include reference-only ownership... or expose titles, costs...') narrow expectations but do not route to an alternative or state prerequisites for obtaining a valid item_id.

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?