Skip to main content
Glama
GregBaugues

Token Bowl MCP Server

by GregBaugues

get_league_winners_bracket

Fetch the playoff winners bracket for the Token Bowl fantasy football championship, including matchups, seeds, winners, and points scored by round.

Instructions

Get the playoff winners bracket for the Token Bowl league championship.

Returns playoff bracket information including:

  • Round number (1 = first round, increases each week)

  • Matchup ID and competing roster IDs

  • Winner and loser roster IDs (when determined)

  • Points scored by each team (when games complete)

  • Playoff seed assignments

Typically covers weeks 15-17 of the NFL season.

Returns: List of playoff matchup dictionaries for the winners bracket

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/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. 'Get' and the enumerated return fields make clear this is a non-mutating read, but it omits auth/permission requirements and any caveats about what happens before the bracket is determined (though 'when determined' hints at this).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, which is good, but the bulleted list of return fields duplicates what the output schema already declares, making it larger than necessary for an accessor tool. Structure is clean but not every sentence earns its place.

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?

For a zero-parameter read tool with an output schema and no annotations, the description supplies enough context: league identity, playoff scope, and the typical week range. Return-value detail is redundant given the output schema but not harmful; no critical calling information 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?

Zero parameters and 100% schema coverage, so the baseline of 4 applies. There are no parameters whose semantics require explanation, and the description correctly adds no parameter guidance.

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?

States a specific verb (Get) and resource (playoff winners bracket) with scope narrowed to the Token Bowl league championship. It is distinguishable from the regular-season get_league_matchups sibling by the 'playoff winners bracket' framing, though it never explicitly names any sibling.

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?

Usage is implied via the 'playoff championship' framing and the note that it 'typically covers weeks 15-17,' which hints at when it is relevant. However there is no explicit when-not-to-use guidance or pointer to an alternative such as get_league_matchups for regular-season data.

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