Skip to main content
Glama

get_teams_by_year_keys

Read-onlyIdempotent

Retrieve paginated team keys for a specified FRC season year. Use this to build per-year team indices or drive downstream per-team data lookups.

Instructions

Paginated list of team keys that competed in a given FRC season year. Lightest variant; ideal for building per-year team indices or driving downstream per-team lookups.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearYesFRC competition season year. FRC began in 1992 and runs one game per year (e.g., 2023 = "Charged Up", 2024 = "Crescendo", 2025 = "Reefscape"). Must be between 1992 and next calendar year.
page_numYesZero-indexed page number for paginated team listings. TBA returns up to 500 teams per page; increment until the response is empty to enumerate all teams.

Implementation Reference

  • Handler for 'get_teams_by_year_keys' tool. Parses year and page_num from args, calls the API /teams/{year}/{page_num}/keys, and returns the list of team keys as JSON.
    case 'get_teams_by_year_keys': {
      const { year, page_num } = z
        .object({
          year: YearSchema,
          page_num: z.number().min(0),
        })
        .parse(args);
      const data = await makeApiRequest(`/teams/${year}/${page_num}/keys`);
      const keys = z.array(z.string()).parse(data);
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(keys, null, 2),
          },
        ],
      };
    }
  • Input schema for get_teams_by_year_keys: requires year (YearSchema) and page_num (PageNumSchema).
    export const GetTeamsByYearKeysInputSchema = z.object({
      year: YearSchema,
      page_num: PageNumSchema,
    });
  • src/tools.ts:299-303 (registration)
    Registration of get_teams_by_year_keys tool with its name, description, input schema, and annotations.
    name: 'get_teams_by_year_keys',
    description:
      'Paginated list of team keys that competed in a given FRC season year. Lightest variant; ideal for building per-year team indices or driving downstream per-team lookups.',
    inputSchema: toMCPSchema(GetTeamsByYearKeysInputSchema),
    annotations: { ...READ_ONLY_API, title: 'List FRC Team Keys by Year' },
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description mentions pagination and 'lightest variant', but pagination behavior is already detailed in the schema's page_num parameter description. No additional behavioral traits beyond annotations and schema.

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?

Two sentences, concise and front-loaded with key information. Every word adds value with no redundancy.

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 paginated list tool with two well-documented parameters and comprehensive annotations, the description sufficiently covers what an agent needs to know. No output schema exists, but the return type (team keys) is implied and commonly understood.

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%, with both year and page_num clearly documented. The description adds use-case context ('lightest variant') but does not add new semantic meaning to the parameters beyond what the schema provides.

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 clearly states 'Paginated list of team keys that competed in a given FRC season year', specifying verb (list), resource (team keys), and scope (by year, paginated). It also labels itself as 'lightest variant', distinguishing it from siblings like get_teams_by_year and get_teams_by_year_simple.

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

Usage Guidelines4/5

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

The description indicates ideal usage: 'ideal for building per-year team indices or driving downstream per-team lookups'. This implies when to use it, though it does not explicitly mention when not to use or name alternatives. The sibling context provides differentiation.

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

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