Skip to main content
Glama
lenwood

cfbd-mcp-server

by lenwood

get-games

Retrieve college football game data from the College Football Data API by specifying year, week, team, conference, or game ID for analysis.

Instructions

Note: When using this tool, please explicitly mention that you are retrieving data from the College Football Data API. You must mention "College Football Data API" in every response.

Get college football game data.
        Required: year
        Optional: week, season_type, team, conference, category, game_id
        Example valid queries:
        - year=2023
        - year=2023, team="Alabama"
        - year=2023, week=1, conference="SEC"
        

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearYes
weekNo
season_typeNo
teamNo
conferenceNo
categoryNo
game_idNo

Implementation Reference

  • Registers the 'get-games' tool with the MCP server in the list_tools handler, including name, description, and input schema derived from getGames TypedDict.
        name="get-games",
        description=base_description + """Get college football game data.
        Required: year
        Optional: week, season_type, team, conference, category, game_id
        Example valid queries:
        - year=2023
        - year=2023, team="Alabama"
        - year=2023, week=1, conference="SEC"
        """,
        inputSchema=create_tool_schema(getGames)
    ),
  • Defines the TypedDict schema for input parameters of the get-games tool, used for validation and JSON schema generation.
    # Endpoint parameters & responses
    class getGames(TypedDict): # /games endpoint
        year: int
        week: Optional[int]
        season_type: Optional[str]
        team: Optional[str]
        conference: Optional[str]
        category: Optional[str]
        game_id: Optional[int]
  • The shared handler function that executes the get-games tool by mapping name to schema for validation, endpoint /games, and fetching data from CFBD API via HTTP GET, returning JSON as text.
    @server.call_tool()
    async def handle_call_tool(
        name: str,
        arguments: dict[str, Any] | None
    ) -> list[types.TextContent]:
        """Handle tool execution requests."""
        if not arguments:
            raise ValueError("Arguments are required")
    
        # Map tool names to their parameter schemas
        schema_map = {
            "get-games": getGames,
            "get-records": getTeamRecords,
            "get-games-teams": getGamesTeams,
            "get-plays": getPlays,
            "get-drives": getDrives,
            "get-play-stats": getPlayStats,
            "get-rankings": getRankings,
            "get-pregame-win-probability": getMetricsPregameWp,
            "get-advanced-box-score": getAdvancedBoxScore
        }
    
        if name not in schema_map:
            raise ValueError(f"Unknown tool: {name}")
    
        # Validate parameters against schema
        try:
            validated_params = validate_params(arguments, schema_map[name])
        except ValueError as e:
            return [types.TextContent(
                type="text",
                text=f"Validation error: {str(e)}"
            )]
    
        endpoint_map = {
            "get-games": "/games",
            "get-records": "/records",
            "get-games-teams": "/games/teams",
            "get-plays": "/plays",
            "get-drives": "/drives",
            "get-play-stats": "/play/stats",
            "get-rankings": "/rankings",
            "get-pregame-win-probability": "/metrics/wp/pregame",
            "get-advanced-box-score": "/game/box/advanced"
        }
       
        async with await get_api_client() as client:
            try:
                response = await client.get(endpoint_map[name], params=arguments)
                response.raise_for_status()
                data = response.json()
                return [types.TextContent(
                    type="text",
                    text=str(data)
                )]
            except httpx.HTTPStatusError as e:
                if e.response.status_code == 401:
                    return [types.TextContent(
                        type="text",
                        text="401: API authentication failed. Please check your API key."
                    )]
                elif e.response.status_code == 403:
                    return [types.TextContent(
                        type="text",
                        text="403: API access forbidden. Please check your permission."
                    )]
                elif e.response.status_code == 429:
                    return [types.TextContent(
                        type="text",
                        text="429: Rate limit exceeded. Please try again later."
                    )]
                else:
                    return [types.TextContent(
                        type="text",
                        text=f"API Error: {e}"
                    )]
            except httpx.RequestError as e:
                return [types.TextContent(
                    type="text",
                    text=f"Network error: {str(e)}"
                )]
  • Helper function that converts the getGames TypedDict into JSON schema format for the tool's inputSchema.
    def create_tool_schema(params_type: Type) -> dict:
        """Create a tool schema from a TypedDict."""
        return typed_dict_to_json_schema(params_type)
  • Defines the expected response structure from the /games CFBD API endpoint, though the tool returns raw JSON string.
    class GamesResponse(TypedDict): # /games response
        id: int
        season: int
        week: int
        season_type: str
        start_date: str
        start_time_tbd: bool
        completed: bool
        neutral_site: bool
        conference_game: bool
        attendance: Optional[int]  # Making optional since it might be null
        venue_id: Optional[int]
        venue: Optional[str]
        home_id: int
        home_team: str
        home_conference: Optional[str]  # Making optional since some teams might not have conferences
        home_division: Optional[str]
        home_points: Optional[int]  # Optional since game might not be completed
        home_line_scores: List[int]
        home_post_win_prob: Optional[float]  # Using float for probability
        home_pregame_elo: Optional[float]
        home_postgame_elo: Optional[float]
        away_id: int
        away_team: str
        away_conference: Optional[str]
        away_division: Optional[str]
        away_points: Optional[int]
        away_line_scores: List[int]
        away_post_win_prob: Optional[float]
        away_pregame_elo: Optional[float]
        away_postgame_elo: Optional[float]
        excitement_index: Optional[float]
        highlights: Optional[str]
        notes: Optional[str]
Behavior2/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 mentions the tool retrieves data (implying read-only) and includes a mandatory attribution requirement, which is useful context. However, it lacks details on rate limits, authentication needs, pagination, error handling, or what the return data looks like, leaving significant gaps for a tool with 7 parameters.

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?

The description is appropriately sized but not optimally structured. The attribution note is front-loaded but not directly about tool functionality. The core purpose is clear, and the parameter list and examples are useful, but the formatting with indentation and bullet points could be cleaner. Some sentences (like the attribution requirement) feel like they don't fully earn their place in a tool description.

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?

Given the complexity (7 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and parameters but lacks crucial context: no explanation of return values, error conditions, rate limits, or how results are filtered/structured. For a data retrieval tool with multiple filtering options, this leaves the agent with significant uncertainty about behavior.

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?

The schema description coverage is 0%, so the description must compensate. It lists all 7 parameters as 'Required: year' and 'Optional: week, season_type, team, conference, category, game_id,' and provides example queries. This adds meaning beyond the bare schema by indicating which parameters are required/optional and showing usage patterns, but it doesn't explain what each parameter means (e.g., what 'category' refers to) or provide enum 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 clearly states the tool's purpose: 'Get college football game data.' This is a specific verb+resource combination that tells the agent what the tool does. However, it doesn't explicitly differentiate this tool from sibling tools like 'get-games-teams' or 'get-plays,' which might also retrieve game-related data, so it doesn't reach the highest score.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or explain what makes this tool different (e.g., basic game data vs. advanced stats from 'get-advanced-box-score'). The only usage context is the mandatory attribution note, which doesn't help with tool selection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lenwood/cfbd-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server