Skip to main content
Glama
kashrockapi

kashrock-mcp

Official
by kashrockapi

research_player

Get career tape for a player across a selected market and sport. Input a player ID, slug, or nickname to access historical stats for analysis.

Instructions

Career tape for one player and market. player is kr_pl_* (preferred), catalog slug, or nickname. Empty tape is 200, not 404.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sportNocs2
marketNokills_maps_1_2
playerYes
recentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.5

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description is the sole behavioral source. It discloses a valuable edge case — empty tape returns 200, not 404 — which prevents misinterpretation of empty results. It does not mention auth, data recency, or side effects, though the read-only nature is implied.

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?

Three short sentences each carry distinct information: purpose, player identifier format, and the empty-tape behavior. It is front-loaded, free of filler, and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with four parameters, no annotations, and no output schema, the description is too thin. It does not describe the structure of a career tape, the effect of `recent`, or valid values for `sport` and `market`, leaving an agent to guess important call details.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only documents the `player` parameter (kr_pl_*, slug, nickname). It leaves `sport`, `market`, and `recent` unexplained, and the market mention in the purpose line does not clarify its format or allowed values.

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 names a specific resource, 'Career tape', and scopes it to one player and market, which clearly conveys the core function. It implicitly distinguishes this from board-level siblings like research_board_tapes, but it uses no explicit verb and never names alternatives, so it stops short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this tool over research_board_tapes, get_player_stats_full, or get_player. The only usage hint is the parameter-level note about player identifiers, which is not tool-selection guidance.

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