Skip to main content
Glama

get_team_years_participated

Read-onlyIdempotent

Retrieve a list of all FRC competition years for a team to analyze their participation history and determine rookie year.

Instructions

Retrieve every season year in which a team has competed in FRC, sorted ascending. Returns a flat array of year integers. Use to bound year-based queries, drive per-year iteration, or determine a team's longevity and rookie year.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
team_keyYesFRC team key formatted as 'frc' followed by the team number with no leading zeros (e.g., 'frc86', 'frc254', 'frc1114'). Uniquely identifies a FIRST Robotics Competition team on The Blue Alliance.

Implementation Reference

  • Handler for 'get_team_years_participated' tool. Parses team_key from args, calls the Blue Alliance API endpoint /team/{team_key}/years_participated, validates that the response is an array of numbers, and returns the years as JSON text.
    case 'get_team_years_participated': {
      const { team_key } = z.object({ team_key: TeamKeySchema }).parse(args);
      const data = await makeApiRequest(`/team/${team_key}/years_participated`);
      const years = z.array(z.number()).parse(data);
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(years, null, 2),
          },
        ],
      };
    }
  • Zod input schema for get_team_years_participated - requires team_key validated against TeamKeySchema (format 'frcXXXX').
    export const GetTeamYearsParticipatedInputSchema = z.object({
      team_key: TeamKeySchema,
    });
  • src/tools.ts:165-171 (registration)
    Tool registration definition. Declares name 'get_team_years_participated' with description and input schema binding. Uses READ_ONLY_API annotations and has title 'Get Team Years Participated'.
    {
      name: 'get_team_years_participated',
      description:
        "Retrieve every season year in which a team has competed in FRC, sorted ascending. Returns a flat array of year integers. Use to bound year-based queries, drive per-year iteration, or determine a team's longevity and rookie year.",
      inputSchema: toMCPSchema(GetTeamYearsParticipatedInputSchema),
      annotations: { ...READ_ONLY_API, title: 'Get Team Years Participated' },
    },
  • Import of GetTeamYearsParticipatedInputSchema from schemas.ts into tools.ts for use in the tool registration.
    GetTeamYearsParticipatedInputSchema,
    GetTeamDistrictsInputSchema,
    GetTeamRobotsInputSchema,
    GetTeamMediaInputSchema,
    GetTeamEventMatchesInputSchema,
    GetTeamsInputSchema,
    GetStatusInputSchema,
    GetMatchInputSchema,
    GetEventOprsInputSchema,
    GetEventAwardsInputSchema,
    GetTeamAwardsAllInputSchema,
    GetTeamEventsAllInputSchema,
    GetTeamEventStatusInputSchema,
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, no destruction. Description adds value by confirming return format (flat array of integers) and ordering (ascending). No contradictions. Could mention error handling, but not critical for a simple read operation.

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: first defines operation, second lists use cases. No fluff, front-loaded with essential information. 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?

Given the simple nature (single required param, no output schema, annotations present), the description provides enough context: purpose, return format, and usage guidance. Minor omission of error scenarios, but overall complete.

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?

Input schema has 100% coverage with a clear description of 'team_key'. The tool description does not add extra parameter details, but schema coverage is high, so baseline 3 is appropriate.

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?

Clearly states the verb 'retrieve' and resource 'season years in which a team has competed in FRC', specifies sorting ascending, and describes the return structure (flat array of year integers). Uniquely distinct from siblings which return events, matches, or team info, not a simple year list.

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?

Explicitly tells when to use: 'bound year-based queries, drive per-year iteration, determine longevity/rookie year'. Does not mention alternatives or when not to use, but given the narrow scope, the guidance is clear and sufficient.

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