Skip to main content
Glama
kashrockapi

kashrock-mcp

Official
by kashrockapi

get_live_games

Retrieve live games with in-game telemetry, including KDA frames, for a selected sport. Use game_id with get_live_boxscore for detailed stats.

Instructions

List games with live in-game telemetry (KDA frames). Sandbox=CS2, 30-60s delayed; Hobby=all sports, 5s delayed; Builder+=real-time. Use game_id with get_live_boxscore.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sportYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.5

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful behavioral context: the telemetry delay characteristics per environment and the fact that it returns game IDs usable with get_live_boxscore. However, it does not explicitly state that the operation is read-only/safe, nor does it mention authentication requirements or potential rate limiting. The delay disclosure and follow-up linkage are helpful, but the absence of a clear safety profile prevents a higher score.

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 three tight, efficient sentences. The main purpose is front-loaded in the first sentence, followed by necessary environment-specific delay caveats, and a concise pointer to the companion boxscore tool. There is no filler or redundant content; every sentence earns its place.

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

Completeness3/5

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

Given the tool has no output schema and no annotations, the description should explain what the response contains. It confirms that games with live KDA telemetry are returned and implicitly indicates that game_id is available, but it does not describe the full response structure (e.g., fields like match info, scores, timestamps). The delay and tier caveats add situational completeness, but the lack of return-shape detail leaves an agent uncertain about what data it can use after calling this tool.

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

Parameters1/5

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

The input schema has a single required parameter 'sport' with no description, and the schema description coverage is 0%. The description does not mention the 'sport' parameter at all, nor does it explain what values it accepts (e.g., 'cs2', 'football', 'nba') or how it affects results. This is a critical gap because the tool cannot be invoked correctly without understanding this parameter. The description fails to compensate for the poor schema coverage.

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 opens with a specific verb and resource: 'List games with live in-game telemetry (KDA frames).' This clearly identifies what the tool does and distinguishes it from sibling tools like get_matches or get_live_odds by emphasizing KDA telemetry. The additional environment-specific delay details further narrow the tool's scope, making its purpose unambiguous without needing to mention sibling names.

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?

The description provides clear context for when to use the tool: it explains the data freshness differences across Sandbox/Hobby/Builder+ tiers ('Sandbox=CS2, 30-60s delayed; Hobby=all sports, 5s delayed; Builder+=real-time') and gives a direct follow-up instruction ('Use game_id with get_live_boxscore'). It does not explicitly name alternative tools to exclude, but the environment-specific delay guidance effectively informs the agent when this tool's data is appropriate versus other live-data tools.

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