Skip to main content
Glama
wyverns76-J

sports-pulse-mcp

by wyverns76-J

get_nba_team_games

Retrieve recent game results and scores for a specific NBA team by name, so you can quickly check how that team has performed.

Instructions

특정 NBA 팀의 최근 경기 결과를 조회합니다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
team_nameYesNBA 팀 이름. 예: Lakers, Celtics, 레이커스, Warriors

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose what '최근' (recent) means in terms of number of games, date window, or ordering, nor what happens for an unrecognized team name. The single mention of recency is too vague to be actionable.

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?

A single front-loaded sentence with no filler; the resource and scope come first and nothing is wasted. Appropriately sized for a one-parameter lookup tool.

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?

For a trivial single-param lookup with no output schema, the definition is roughly adequate, but the undefined recency window ('최근') is a genuine ambiguity that neither the schema nor the description resolves, and there is no guidance on missing teams or result volume.

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 description coverage is 100%, and the schema already documents team_name with concrete examples including both English and Korean forms. The description adds no syntax, aliasing, or validation detail beyond the schema, so the baseline 3 applies.

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 verb and resource ('특정 NBA 팀의 최근 경기 결과를 조회합니다' – retrieves a specific NBA team's recent game results), which is clear enough for an agent to understand the operation. However, it does not differentiate itself from the sibling 'get_recent_results', which appears to cover overlapping ground, leaving the agent to guess which to pick.

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 explicit when-to-use guidance, no mention of when not to use it, and no reference to alternatives such as get_recent_results or get_nba_today. The team-scoped nature is only implied by the parameter, not stated as a selection criterion.

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