Skip to main content
Glama

Hundo

search_cards

Read-only

Find trading cards (Pokémon) in Hundo's card catalog, to add them to the user's collection with propose_collectibles_add or to link a card with propose_collectible_edit. Returns candidate prints, each with the variantId those tools need. A card's price belongs to its exact print, and the same card printed in another language, with another number or another finish is a different print with a different price: pick the print that matches the card the user holds (language included), and ask the user when two results could be it. 'held' lists copies of a print the user already holds, with their assetId.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_cards"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesOne line, the way a collector writes a card: name, set code, card number and language in any order, e.g. 'Lugia MA6 173/130', 'charizard ex 199 sv3 jp', 'pikachu batik id'. A set code, a number, a language word (en, jp, id) and a grade (psa 10) each narrow the search.

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?

Annotations cover safety (readOnly, closed-world), and the description adds rich context beyond them: it returns candidate prints each carrying a variantId, explains that price is per exact print (language/number/finish matter), and documents the 'held' field with its assetId. This is substantive behavioral detail an agent needs to interpret results correctly.

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

Conciseness4/5

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

Front-loaded with purpose and downstream usage, then the print/price nuance. Every sentence carries useful signal, though the print-price explanation is dense and could be marginally tightened.

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?

No output schema exists, but the description compensates by describing the return shape (candidate prints with variantId, held copies with assetId) and the disambiguation guidance. An agent has enough to call the tool and route its results correctly.

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 query parameter is fully documented with format and examples, so the description leans on structured data. The description adds a note about picking the matching print and asking the user on ambiguity, but contributes nothing new about the query string syntax itself.

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

Purpose5/5

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

States a specific verb and resource ('Find trading cards (Pokémon) in Hundo's card catalog') and immediately situates it relative to the downstream tools it feeds (propose_collectibles_add, propose_collectible_edit). An agent can tell exactly what this tool produces and why.

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?

Clearly frames the workflow: use this when adding a card to the collection or linking one, and to ask the user when two results could match. There is no competing search sibling, so explicit exclusions aren't needed, but it does not spell out when a card should NOT be searched here.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources