Skip to main content
Glama
GregBaugues

Token Bowl MCP Server

by GregBaugues

fetch

Fetch full details for a fantasy football resource by ID. Use it to retrieve player stats, team rosters, user profiles, or matchup data from the Token Bowl league.

Instructions

Retrieve complete information for a specific fantasy football resource.

This tool is required for ChatGPT compatibility and fetches full details for:

  • Player statistics and projections

  • Team rosters with all players

  • User profiles

  • Matchup details

Args: id: Resource identifier with type prefix. Cannot be empty. Must contain underscore. Will be converted to string. Format: _ (e.g., "player_4046", "roster_2")

Returns: Complete resource data with id, title, text, url, and optional metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/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 does establish that this is a non-destructive retrieval returning "complete resource data." It does not state read-only semantics explicitly, nor any auth requirements, rate limits, or error behavior, though for a single-resource fetch these gaps are comparatively minor.

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?

The purpose sentence is front-loaded and the Args/Returns docstring sections are scannable, with examples doing real work. The "required for ChatGPT compatibility" line is somewhat incidental, but overall the text is tight and earns most of its space.

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

Completeness4/5

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

An output schema exists, so the description need not explain return values, yet it confirms the returned fields and fully covers the single required parameter. Combined with the resource-type list, an agent has enough to call it correctly; only clearer sibling routing 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?

Schema description coverage is 0%, so the description must compensate, and it does well: it specifies the type-prefixed format, requires an underscore, forbids an empty value, notes a string conversion, and gives concrete examples ("player_4046", "roster_2"). It stops short of enumerating all valid type prefixes, which is the only missing piece.

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 pairs a clear verb ("Retrieve complete information") with a specific resource category and enumerates the covered resource types (player stats, team rosters, user profiles, matchups). This makes the generic name "fetch" interpretable, but it never distinguishes itself from overlapping siblings like get_roster, get_user, or get_player_by_sleeper_id, so sibling differentiation is absent.

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

Usage Guidelines3/5

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

It notes the tool is "required for ChatGPT compatibility," which is a rationale rather than a usage rule, and the covered-types list implies when the tool applies. However, there is no explicit when-to-use/when-not guidance and no routing toward the many sibling lookups that fetch the same data (get_roster, get_user, get_player_by_sleeper_id), leaving the agent to infer selection.

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