Skip to main content
Glama

get_team_year

Read-onlyIdempotent

Retrieve a single FRC team's performance summary for a specific season, including EPA ratings, win record, events attended, district points, and awards.

Instructions

Get one team's performance summary for one specific FIRST Robotics Competition (FRC) season. Returns the team's EPA breakdown for that year (start, pre-playoffs, end, max, mean, ranks/percentiles), win/loss/tie record and win rate, count and list of events attended, district points, and award totals. Use this to answer "how did team 2056 do in 2023?", "what was team 254's peak EPA in 2018?", or "how many events did team 1114 attend in 2024?". Requires both team number (integer, no prefix) and a 4-digit year >= 2002. For multi-team or multi-year browsing, use get_team_years.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
teamYesTeam number (no prefix), e.g. 86
yearYesFour-digit year (2002 onwards)

Implementation Reference

  • Handler logic for the 'get_team_year' tool. Parses team and year from input, then calls the Statbotics API at /v3/team_year/{team}/{year}.
    case 'get_team_year': {
      const { team, year } = GetTeamYearInputSchema.parse(args);
      const data = await makeApiRequest(`/v3/team_year/${team}/${year}`);
      return {
        content: [{ type: 'text', text: JSON.stringify(data, null, 2) }],
      };
    }
  • Zod input schema for GetTeamYearInputSchema - validates team (integer >= 1) and year (integer >= 2002).
    export const GetTeamYearInputSchema = z.object({
      team: TeamNumberSchema,
      year: YearSchema,
    });
  • src/tools.ts:100-115 (registration)
    Registration of the 'get_team_year' tool in the tools array, including its name, description, annotations, and inputSchema.
    {
      name: 'get_team_year',
      description:
        "Get one team's performance summary for one specific FIRST Robotics Competition (FRC) season. " +
        "Returns the team's EPA breakdown for that year (start, pre-playoffs, end, max, mean, ranks/percentiles), " +
        'win/loss/tie record and win rate, count and list of events attended, district points, and award totals. ' +
        'Use this to answer "how did team 2056 do in 2023?", "what was team 254\'s peak EPA in 2018?", or ' +
        '"how many events did team 1114 attend in 2024?". ' +
        'Requires both team number (integer, no prefix) and a 4-digit year >= 2002. ' +
        'For multi-team or multi-year browsing, use get_team_years.',
      annotations: {
        title: 'Get FRC Team Season Stats (Single Team-Year)',
        ...readOnlyAnnotations,
      },
      inputSchema: toMCPSchema(GetTeamYearInputSchema),
    },
Behavior4/5

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by clarifying the input constraints ('team number (integer, no prefix)' and '4-digit year >= 2002') and listing the output structure (EPA breakdown, win/loss, etc.), which agents need to understand behavior beyond the annotations.

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 sentences with no wasted words. It front-loads the purpose, then gives concrete examples, and ends with requirements and an alternative. Every sentence serves a distinct purpose.

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

Completeness5/5

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

For a simple two-parameter read tool with full schema descriptions and annotations, the description completely covers the tool's purpose, output, required parameters, and relationship to siblings. No gaps remain.

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?

The input schema already has 100% coverage with descriptions for both parameters. The description adds nuance: clarifies that the team number has no prefix ('no prefix') and that the year must be a 4-digit year from 2002 onwards. This goes beyond the schema's minimum/maximum constraints.

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 uses a specific verb ('Get') and resource ('one team's performance summary for one specific FRC season'), and lists the exact data fields returned. It also explicitly distinguishes from the sibling tool 'get_team_years' by stating 'For multi-team or multi-year browsing, use get_team_years.'

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

Usage Guidelines5/5

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

The description provides clear example queries ('how did team 2056 do in 2023?') and explicitly states when to use an alternative ('For multi-team or multi-year browsing, use get_team_years.'), giving both usage context and exclusion criteria.

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/withinfocus/statbotics-mcp-server'

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