Skip to main content
Glama
Silverkazimi

splinterlands-mcp

by Silverkazimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

cards_find

Retrieve per-instance Splinterlands card records by supplying comma-separated UIDs. Returns player, XP, gold, edition, and market details for each card.

Instructions

Look up per-instance card records through GET /cards/find. Supply ids as one comma-separated string of full per-instance card UIDs; real 2-ID and 3-ID requests returned exactly the requested UIDs in order. Repeated ids=, ids[]= and JSON-array encodings are not valid: repeated and bracketed parameters return an unable-to-parse error, while a JSON array is split as literal comma-separated text. A matched record carries player, uid, card_detail_id, xp, gold, edition, card_set, collection_power, market and rental fields, and the measured bcx and bcx_unbound fields. BCX is therefore promised for this per-instance route only; it is not a claim about definition routes. player is current-owner attribution, not donor provenance, and donor was absent in the measured record. This result is bounded by this server's 100-row and 256 KB limits and is not cached as static metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.0.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses encoding errors, return fields, semantics of player ownership, limits (100-row, 256 KB), and caching behavior. No contradictions with annotations (none present).

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

Conciseness5/5

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

The description is dense but every sentence adds value, front-loading the purpose, then encoding rules, then fields, then semantics, then limits. No redundant or filler content.

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 one parameter, no output schema, and no annotations, the description covers all necessary aspects: purpose, encoding, expected fields, behavioral constraints, and caching. An agent can call it correctly without additional information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully explains the single 'ids' parameter: comma-separated UIDs, invalid encodings, and what constitutes a valid request. It adds substantial meaning beyond the bare schema.

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?

The description clearly states it looks up per-instance card records via a specific endpoint, distinguishing it from definition routes and other card-related siblings. It specifies the resource and scope precisely.

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?

Provides clear context on when to use (per-instance records with BCX) and implicitly when not to (definition routes), but does not name specific alternative tools. The exclusion of definition routes is explicit, though no sibling is suggested.

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

Deploy Server

Other Tools