Retrieve current TCGplayer market prices and cost basis for cards by name filter. Compare what you paid versus current worth.
Get latest TCGplayer market prices and cost basis for cards, optionally filtered by name. Use for "what is X worth" or "what did I pay vs. what is it worth now" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| name_contains | No | Optional case-insensitive filter on card name. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It correctly conveys a read operation and the returned data type (market prices plus cost basis), which makes side effects unlikely. However, it omits response shape, pagination/limit behavior, and any freshness or authorization caveats, so transparency is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states function and filtering capability, the second provides concrete use cases. The key action is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter getter, the description covers purpose and common use cases. Yet because there is no output schema, it should clarify return format and limit semantics; those gaps prevent full completeness for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%; 'limit' has no schema description. The tool description rephrases name_contains as 'optionally filtered by name' but adds no detail about the meaning or effect of limit (e.g., maximum result count). Thus the description does not meaningfully compensate for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Get latest TCGplayer market prices and cost basis for cards.' It also notes the optional name filter. This clearly separates it from siblings like get_price_alerts or get_global_pnl, which concern alerts or P&L rather than current market prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly maps the tool to user intents: 'what is X worth' and 'what did I pay vs. what is it worth now.' It gives clear contexts for use but does not name sibling tools or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.