Skip to main content
Glama
Silverkazimi

splinterlands-mcp

by Silverkazimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

players_item_details

Get the full list of Splinterlands item types with metadata like name, type, rarity, and transferability. Use this to browse the item catalogue without providing an item ID.

Instructions

List the full item-type catalogue returned by GET /players/item_details. The measured public response contained 320 items and was about 134 KB, with id, name, type, nullable sub_type, data, transferable, consumable, inventory, nullable print_limit, total_printed, nullable image_filename, nullable icon_filename, nullable description, nullable rarity and stake_type_id. The id parameter is inert: the no-id response and id=1 response were byte-identical, so this tool does not advertise id as an item lookup filter. The measured response carried no BCX, donor or account-attribution field. Successful metadata responses are cached for 24 hours; provenance reports the route and the original fetch time. This server applies its general 100-row and 256 KB result bounds to the returned array; it does not claim that the bounded response is the full upstream catalogue.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 the full burden, and it delivers richly: measured response size, field inventory, inert id behavior verified by byte-identical responses, absence of attribution fields, 24-hour caching, provenance reporting, and result-bound limitations. This is exemplary disclosure beyond a one-line tool description.

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 long but every sentence earns its place: the purpose is front-loaded, the field list substitutes for a missing output schema, and the caveats about id inertness, attribution, caching, and bounds all support correct invocation. There is no filler or tautology.

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?

For a zero-parameter tool with no output schema, this is nearly complete: it tells the agent what data is returned, the field names, response size, caching behavior, provenance, and the limits that prevent treating the result as the full upstream catalogue. Nothing essential is missing.

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?

The schema has zero parameters and 100% coverage, so the baseline is 4. The description usefully explains that the id parameter is not advertised as a lookup filter, which adds meaning around the absence of parameters, but there is no parameter semantics to elaborate further.

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?

The description states a specific action and resource ('List the full item-type catalogue returned by GET /players/item_details') and clarifies that the endpoint is not an id lookup. However, the word 'full' is later qualified by the 100-row/256 KB bounds, and it does not explicitly name a sibling tool to sharpen differentiation, so it stops short of a 5.

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?

It provides clear context and explicit exclusions: the id parameter is inert, there is no BCX/donor/account attribution, and the server applies bounded results. It does not name alternative tools or state an explicit 'use this when...' condition, so it is strong but not maximal.

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