Skip to main content
Glama
Silverkazimi

splinterlands-mcp

by Silverkazimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

cards_history

Retrieve transfer records for a specific card UID, showing transfer dates, types, players, and payment details.

Instructions

List the transfer records returned by GET /cards/history for one per-instance card UID. id is a card UID, not a card_detail_id: numeric ids silently returned [], while a real UID returned transfer records. A returned record carries card_id, transfer_date, transfer_type, transfer_tx, from_player, to_player, card_detail_id, xp, gold, edition, payment_amount, payment_currency and combined_cards. from_player and to_player are account-attribution fields for the transfer, not donor provenance. Donor and BCX were absent in the measured response. This route is a per-instance event lookup, not a card-definition lookup or an enumeration of history for a numeric card_detail_id. The result is limited by this server's 100-row and 256 KB bounds and is not cached as static metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
limitNo
transfer_typesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.2
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / limit / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / limit / minimum
      Added value: +-9007199254740991
  2. First observedv0.0.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries full burden and discharges it: it lists returned fields, flags that from_player/to_player are attribution not provenance, notes donor/BCX were absent, and states the 100-row/256 KB bounds and non-caching. No major behavioral trait is left undisclosed.

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?

Dense and front-loaded with purpose and the id caveat; nearly every sentence adds value. Slightly longer than necessary due to repeating the per-instance/non-definition framing and the measured-response detail, but not padded.

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?

Although there is no output schema, the description enumerates the record fields and clarifies the semantics of the route, limits, and cache behavior. For a required-param list endpoint, this is enough for an agent to select and call it 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 0%, so the description must compensate; it does thoroughly for the required id parameter (UID vs numeric, empty-array behavior). However, limit and transfer_types receive no semantic explanation beyond their names/schema types, leaving their expected formats or accepted values ambiguous.

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 an exact verb+resource ('List transfer records... per-instance card UID') and explicitly contrasts with card-definition lookup and enumeration by numeric card_detail_id. This clearly separates it from the many cards_* siblings.

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 when-to-use context: only for per-instance card UID transfer events, and explicitly warns 'id is a card UID, not a card_detail_id'. It gives when-not conditions but does not name or route to a specific alternative sibling tool, so not a 5.

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