Crawlora MCP

maxpreps_school_zip_search

Read-only

Get list MaxPreps schools near a ZIP code. Returns the MaxPreps schools around one five-digit US ZIP code with the same school record shape as maxpreps-school-search: identity, location, colours, mascot, enrollment and each school's sport-season ids. Offset pagination with startFrom; optional name, city and distance filters. Use it when a caller starts from a location rather than a school name.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "zipCode": "<zipCode>"
    },
    "name": "maxpreps_school_zip_search"
  }
}

Input Schema

Name	Required	Description
`zipCode`	Yes	Required five-digit US ZIP code.
`startFrom`	No	Optional zero-based offset for offset pagination. Defaults to 0.
`searchCity`	No	Optional city filter.
`searchText`	No	Optional school-name filter inside the ZIP radius.
`allSeasonId`	No	Optional all-season id from maxpreps-sports to scope the returned teams to one season.
`maxDistance`	No	Optional maximum distance in metres from the ZIP code.
`publishedOnly`	No	Optional published-only flag.
`searchByState`	No	Optional search-by-state flag.
`sportSeasonId`	No	Optional sport-season id to scope the returned teams to one team season.
`historicalOnly`	No	Optional historical-only flag.
`includeDeleted`	No	Optional include-deleted flag.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data scope are covered. The description adds pagination behavior ('Offset pagination with startFrom') and enumerates the returned fields, but says nothing about result caps, radius defaults, or ordering. With annotations carrying the safety profile, this is adequate but not rich.

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?

Three tight sentences, front-loaded with purpose, then return shape, then pagination/filters, then the disambiguation rule. The only mild repetition is restating 'five-digit US ZIP code,' which is minor padding rather than bloat.

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?

An output schema exists and annotations cover the read-only/open-world profile, so the description need not explain returns in depth. For an 11-parameter tool it covers the driving input, pagination, and the main optional filters, leaving the season and visibility flags to the schema. Complete enough to call correctly.

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%, so the baseline is 3 and the schema already explains every parameter. The description only echoes the startFrom offset and the name/city/distance filters, adding no new semantics for the season-scoping or visibility flags (allSeasonId, sportSeasonId, publishedOnly, historicalOnly).

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?

Leads with a specific verb and resource ('Get list MaxPreps schools near a ZIP code') and clarifies the record shape is identical to maxpreps-school-search. The closing line separates it from name-based siblings by stating it is for callers starting from a location, so an agent can pick it without opening the schema.

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 states the selection condition: 'Use it when a caller starts from a location rather than a school name,' which contrasts it with the name-based search sibling. It stops short of naming when-not-to-use cases or prerequisites, but the routing signal is clear.

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

All Crawlora MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.