Skip to main content
Glama
Sign In

SuperCatch

by com.supercatch
OverviewDiscussionsAdmin

Search SuperCatch

supercatch_search_marketplace
Read-onlyIdempotent

Find public trading-card and collectibles listings by keyword. Use when discovering public cards by player, set, year or product words before a product slug is known. Refine query words to narrow results; this tool returns only the first ranked page, with no cursor or page argument. A search summary is not a current offer lookup, private inventory report or repricing proposal. Returns top-ranked titles, slugs, canonical URLs, total matches, listing counts and list-price floors in USD; unlisted catalog matches may have a labeled market value. Use the returned search-page link for more matches. Public; no sign-in required. Read-only; no purchases, watchlist edits or price changes. No matches return a search link and any spelling suggestion; missing search terms return a tool error. HTTP 429 includes Retry-After. Use supercatch_get_product when a product slug is known or a search match needs its current sale-aware price and availability. Use supercatch_list_store_listings when the connected seller needs their own listing rows and statuses. Use supercatch_get_store_inventory when the connected seller needs aggregate stock counts. Use supercatch_preview_card_prices when the connected seller wants a repricing proposal instead of public discovery.

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": 3,
      "query": "Pikachu"
    },
    "name": "supercatch_search_marketplace"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum ranked matches to return (1-10); omit for 5.
queryYesSearch terms, player name, set name, or product keywords.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial context beyond the readOnly/idempotent annotations: public with no sign-in, read-only with no purchases or watchlist or price changes, a single ranked page with no cursor or page argument, empty-result behavior returning a search link plus spelling suggestion, a tool error for missing terms, and HTTP 429 with Retry-After. These are operational traits an agent could not infer from the annotations alone.

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?

Front-loaded with purpose and scoping, which is good, but the paragraph is dense and sprawling: four sibling-routing sentences plus return-value, error, and rate-limit sentences in one block. Some content (return fields, error behavior) is essential, yet the breadth makes it harder to scan than necessary. Wasted phrasing is limited but the sheer density costs it.

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?

There is no output schema, and the description compensates by naming what comes back: top-ranked titles, slugs, canonical URLs, total matches, listing counts, USD list-price floors, and labeled market values for unlisted catalog matches, plus the search-page link for further matches. Combined with error and rate-limit behavior, an agent has everything needed to call it and interpret results.

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 schema already defines query and limit (1-10, default 5), which sets the baseline at 3. The description adds that refining query words narrows results and that there is no cursor or page parameter — useful for understanding limit's role as a single-page cap. It stops short of explaining how ranking or match breadth responds to query wording.

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: finding public trading-card and collectibles listings by keyword, with scope words (public, discovery-oriented). It separates itself from get_product, list_store_listings, get_store_inventory and preview_card_prices. However, it never mentions the closest sibling, supercatch_search_listings, so an agent must guess which search tool handles non-public or account-scoped listings.

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

Usage Guidelines5/5

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

Explicitly says when to use it (discovering public cards by player, set, year or product words before a product slug is known) and enumerates four alternatives with the exact condition selecting each (slug known, seller listing rows, seller stock counts, repricing proposal). It also lists what this is not: offer lookup, private inventory report, repricing proposal.

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

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