purdue-mcp

Next Purdue games across all sports

athletics_upcoming

Retrieve upcoming Purdue Boilermaker games across all varsity sports, sorted by soonest start. Filter by time window, result count, or home games only.

Instructions

The next Boilermaker games across every varsity sport, soonest first — what to go watch this week. Source: purduesports.com (official athletics site API).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "athletics_upcoming"
  }
}

Input Schema

Name	Required	Description
`days`	No	Window in days. Default 14.
`limit`	No	Default 20.
`home_only`	No	Only home games.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Aug 18, 2026

TDQS

A3.9/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 burden. It discloses the source and sorting order but does not mention rate limits, data freshness, whether results are cached, or if live updates occur. Without annotations, more behavioral detail would be helpful.

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

Conciseness4/5

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

The description is two sentences, front-loading the purpose and adding a source note. It is efficient and clear, but the source note could be integrated into the first sentence to reduce slight redundancy.

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 no output schema and moderate tool complexity (3 optional params), the description provides enough context for an agent to select and invoke the tool for its intended purpose. It lacks return format details, but the list nature of the tool makes this somewhat acceptable.

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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of the tool (upcoming games, sorted soonest) and implicitly ties parameters to filtering. However, it does not elaborate on each parameter's specific behavior beyond what the schema already provides. The description earns a 4 for contextual framing rather than parameter-specific details.

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 the tool lists upcoming Purdue athletics games across all sports, sorted by soonest first, and specifies the data source (purduesports.com API). This distinguishes it from siblings like athletics_sports or athletics_schedule.

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?

The description implies it's for finding games to watch this week, but does not explicitly compare with siblings (e.g., athletics_schedule for a specific sport) or provide when-not-to-use guidance. Usage context is implied by the content, but no alternative tools are mentioned.

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