Tennis, pickleball and padel courts from OpenStreetMap: surface, lighting, access, fee. Read-only.
Scored across 3 tools
Each tool has a clearly distinct role: search_courts finds venues, get_court retrieves one venue by id, and list_coverage enumerates covered places. The descriptions actively reinforce the boundaries (list_coverage explicitly says it does not list courts and points to search_courts), leaving no realistic misselection path.
All three tools follow a consistent snake_case verb_noun pattern (search_courts, get_court, list_coverage) with predictable verb semantics (search/get/list). No mixed conventions or vague verb-only names.
Three tools is on the lean side, but each maps to a genuine need (discovery, detail lookup, coverage reference) for a read-only OSM court directory. It is slightly thin — get_court is arguably a convenience wrapper over search_courts output — but nothing is redundant.
The read-only lifecycle (find venues, inspect a venue, discover coverage) is fully covered, including necessary caveats like unknown properties, alternatives, and attribution. Minor gaps remain, such as pagination/result limits or a way to enumerate supported sports or filter values, but agents can work around these.
Get the details of one court venue by its id from search_courts: courts per sport, surface, lighting, access, fee, website, opening hours, OpenStreetMap links, source, data date and caveats.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Venue id, e.g. 'way-123456'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description need not repeat safety traits. It adds useful context by enumerating the returned details including source, data date, and caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence with no wasted preamble. The colon-separated field list is long but earns its place by summarizing returned data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only detail lookup with no output schema, the description provides enough return-field context for an agent to know what it will receive. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'id' parameter is already documented with an example. The description adds that the id comes from search_courts, which is mildly useful but does not substantially expand parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), resource ('details of one court venue'), and identifying parameter ('by its id from search_courts'). This clearly distinguishes it from the sibling list and search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by its id from search_courts' makes the intended workflow clear: obtain an id via search_courts, then retrieve full details. It does not explicitly state exclusions, but the context is strong enough to guide correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the covered cities and metro areas with the number of venues in each, grouped by country. It does not list courts: to find courts, call search_courts with city=. Pass 'country' (e.g. 'Spain') to list one country; 'detail'=true adds per-city counts by sport (larger answer). The counts are mapped venues, not a quality measure.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Per-city counts by sport and hidden-private counts (much larger answer). | |
| country | No | Only this country, name or ISO code, e.g. 'Spain' or 'ES'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description still adds real value beyond them: 'detail'=true yields a 'larger answer' (a cost/size hint) and the counts are 'mapped venues, not a quality measure', which prevents misinterpreting the numbers. It stops short of noting result size limits or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences, front-loaded with what is listed, followed by the sibling exclusion, then the parameter behavior. Every sentence carries new information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must describe the return shape — it does: cities/metro areas with venue counts, grouped by country, optionally split per sport. Combined with the caveat about what the counts mean and the pointer to search_courts, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters, including the ISO-code option and the hidden-private counts. The description's 'country (e.g. Spain)' and 'detail=true adds per-city counts by sport' largely restate the schema, adding only the 'larger answer' framing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the covered cities and metro areas with the number of venues in each, grouped by country'), including the unit of aggregation. It also explicitly distinguishes itself from the sibling search_courts, which lists courts, so an agent can pick the right tool without reading schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing: 'It does not list courts: to find courts, call search_courts with city=<a name from this list>', which even describes the correct handoff workflow. It also states how to narrow with country and when to opt into detail, so both usage modes are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search mapped tennis, pickleball and padel courts in a covered city or metro area, or around a point. Pass 'city' (e.g. 'Austin, TX', 'Lisbon', 'Los Angeles area'; add 'country' if the name is ambiguous) or 'lat'+'lon' (+'radius_km'). Optional filters: sport, setting (outdoor or indoor), lit, open_to_public, free (mapped as no fee), min_courts. Each result is a venue with the number of courts ('courts' is the total at the venue, 'matched_sport_courts' the number for the requested sport), lighting, surface, access, the nearest park or street ('near'), a map link and the source. Results list courts open to the public first and clubs last; check each result's open_to_public, access_note and 'near'. 'unknown' means not mapped. If fewer than 3 courts match and others were left out only because a property is unmapped, they are added and marked 'matched_unknown'. If no court of the requested sport is mapped, the nearest tennis courts are returned in 'alternatives' (tennis, not the sport asked for). A place that is not covered returns an error; list_coverage shows the covered places. Mapped facts only: no bookings or live availability. Data comes from OpenStreetMap (ODbL), is often incomplete, and every answer carries the data date and attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the search point (use with lon). | |
| lit | No | Only courts with lighting. | |
| lon | No | Longitude of the search point (use with lat). | |
| city | No | A covered city, e.g. 'Austin, TX', 'Long Beach' or 'Tbilisi' (also any city inside a metro area, e.g. 'Santa Monica' or 'Huntington Beach'), or a whole metro area, e.g. 'Los Angeles area' (all of Los Angeles and Orange counties) or 'New York area'. See list_coverage. | |
| free | No | Only courts mapped with no fee (fee=no). | |
| limit | No | ||
| sport | No | Sport: tennis, padel or pickleball. Omit for any. | |
| offset | No | Skip this many results (paging). | |
| country | No | Country name or ISO code, e.g. 'Georgia', 'GE', 'US'. Use it when the same city name exists in several countries; with lat/lon it limits the search to that country. Distances are in miles for the US and metres/kilometres elsewhere (distance_km is always given). | |
| setting | No | 'outdoor' = open-air courts; 'indoor' = indoor or covered. | any |
| radius_km | No | Search radius around lat/lon, km. | |
| min_courts | No | Minimum number of courts at the venue. | |
| match_unknown | No | Also return courts where a filtered property is not mapped (unknown). | |
| open_to_public | No | Only courts open to everyone. Returns courts mapped as public, with no fee or inside a park (open_to_public yes) and courts with no restriction mapped (open_to_public probably, with a note). Clubs, private courts and school grounds are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: result ordering (public first, clubs last), 'unknown' semantics, the matched_unknown backfill rule below 3 matches, the alternatives fallback returning tennis instead of the requested sport, the uncovered-place error, and data-quality caveats (OSM, often incomplete, dated attribution). That is exactly the non-obvious behavior an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and location mode, and nearly every sentence carries a behavioral rule that could not be inferred elsewhere. It is, however, one dense ~230-word block with several distinct rules (ordering, backfill, alternatives, coverage error) that would be easier to scan as short separated statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter, zero-required, no-output-schema tool, the description fills the critical gaps: it explains what each result contains (courts, matched_sport_courts, lighting, surface, access, 'near', map link, source), how results are ordered, and how partial/unknown data is surfaced. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 93%, so the schema carries most semantics (baseline 3). The description still adds value: the free filter is glossed as 'mapped as no fee', country is framed as an ambiguity resolver and a lat/lon limiter, and the location parameter pairing is spelled out. It does not explain limit/offset paging or match_unknown, which are the two remaining gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource plus scope: 'Search mapped tennis, pickleball and padel courts in a covered city or metro area, or around a point.' That cleanly separates it from get_court (single-venue lookup) and list_coverage (coverage listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit invocation modes ('city' OR 'lat'+'lon'), a disambiguation rule ('add country if the name is ambiguous'), a routing pointer to the sibling ('list_coverage shows the covered places'), and a hard exclusion ('Mapped facts only: no bookings or live availability'). An agent knows when to use this and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_courts2 fields changedInput schema / properties / free / descriptionPrevious value: -"Only courts mapped as free of charge (fee=no)."New value: +"Only courts mapped with no fee (fee=no)."Input schema / properties / open_to_public / descriptionPrevious value: -"Only courts open to everyone. Returns courts mapped as public, free of charge or inside a park (open_to_public yes) and courts with no restriction mapped (open_to_public probably, with a note). Clubs, private courts and school grounds are excluded."New value: +"Only courts open to everyone. Returns courts mapped as public, with no fee or inside a park (open_to_public yes) and courts with no restriction mapped (open_to_public probably, with a note). Clubs, private courts and school grounds are excluded."list_coverage2 fields changedInput schema / properties / countryAdded value: +{
+ "description": "Only this country, name or ISO code, e.g. 'Spain' or 'ES'.",
+ "type": "string"
+}Input schema / properties / detailAdded value: +{
+ "default": false,
+ "description": "Per-city counts by sport and hidden-private counts (much larger answer).",
+ "type": "boolean"
+}search_courts1 field changedInput schema / properties / city / descriptionPrevious value: -"A covered city, e.g. 'Austin, TX', 'Long Beach' or 'Tbilisi', or a whole metro area, e.g. 'Los Angeles area' (all of Los Angeles and Orange counties) or 'New York area'. See list_coverage."New value: +"A covered city, e.g. 'Austin, TX', 'Long Beach' or 'Tbilisi' (also any city inside a metro area, e.g. 'Santa Monica' or 'Huntington Beach'), or a whole metro area, e.g. 'Los Angeles area' (all of Los Angeles and Orange counties) or 'New York area'. See list_coverage."search_courts1 field changedInput schema / properties / open_to_public / descriptionPrevious value: -"Only courts anyone can use: access is public, or free of charge, or inside a park. Clubs (access_status club), private and likely private courts are excluded."New value: +"Only courts open to everyone. Returns courts mapped as public, free of charge or inside a park (open_to_public yes) and courts with no restriction mapped (open_to_public probably, with a note). Clubs, private courts and school grounds are excluded."search_courts1 field changedInput schema / properties / include_privateRemoved value: -{
- "default": false,
- "description": "Also return courts that are private (access_status private: marked so in OpenStreetMap) or likely private (access_status likely_private: unnamed courts next to houses or in residential areas). Hidden by default; each comes with access_status and the warning 'Possibly private — check before you go'.",
- "type": "boolean"
-}get_courtlist_coveragesearch_courtsOverture Maps places — business and point-of-interest locations (name, category, confidence…
ATP and WTA tennis since 2007: sets, draws, rankings, head to head, surface Elo, sportsbook lines.
OpenStreetMap queries, maps/styles, search, routing, terrain, analysis, pipelines, and rendering.
US outdoor recreation: 37k+ trails, 30k+ campgrounds, parks, weather + wildfire safety. Read-only.
Add one secure layer between your agents and this server.
