Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

maxpreps_request_enums

Retrieve all closed request enum values for MaxPreps routes—states, sport tokens, genders, levels, sort orders, and scoreboard contexts—to validate parameters locally without an upstream call.

Instructions

MaxPreps closed request enum values. Returns every closed request value set the MaxPreps routes validate locally: the 53 state codes, the 64 gender+sport tokens, the three genders, the three team levels, the two school-search sort orders and the seven scoreboard contexts with the identifier kind each context's id parameter must carry. Values were cold-replay verified on 2026-11-09 and are covered by exact-set tests. No upstream call is made.

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": "maxpreps_request_enums"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does well: it states no upstream call is made, that values were cold-replay verified on 2026-11-09, that exact-set tests cover them, and that scoreboard contexts carry the identifier kind their id parameter must accept. The one real gap is the return shape – it lists the contents but not whether they come back as one object with named keys or otherwise – which matters because there is no output schema.

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?

Two sentences, front-loaded with the resource and its contents, then the trust/behavioral footer. It is dense – the long enumeration with embedded counts is hard to skim – but every clause carries information, and nothing is redundant with structured fields.

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?

For a zero-parameter, no-output-schema tool, the description sensibly substitutes for the missing output schema by enumerating the returned sets with counts and by flagging the context/id-kind relationship. It falls short only on the exact return structure (key names, grouping), which an agent would otherwise have to discover by calling it.

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 tool takes zero parameters, so the baseline is 4. The description implicitly confirms nothing is needed to call it while conveying the semantic structure of the values returned, including the context-to-identifier-kind mapping, which is the most non-obvious piece of meaning here.

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?

States a specific verb and resource – 'Returns every closed request value set the MaxPreps routes validate locally' – and then enumerates exactly which sets (53 state codes, 64 gender+sport tokens, three genders, three team levels, two sort orders, seven scoreboard contexts). The closing 'No upstream call is made' separates it from the data-fetching siblings like maxpreps_states or maxpreps_scoreboard without needing to name them.

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?

Usage is only implied: because it is local and makes no upstream call, an agent can infer it is the cheap way to resolve valid enum values before calling other MaxPreps tools. There is no explicit 'call this before X' statement and no stated conditions or exclusions, so the guidance is implied rather than directed.

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

Deploy Server