Skip to main content
Glama

Search courts

search_courts
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude of the search point (use with lon).
litNoOnly courts with lighting.
lonNoLongitude of the search point (use with lat).
cityNoA 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.
freeNoOnly courts mapped with no fee (fee=no).
limitNo
sportNoSport: tennis, padel or pickleball. Omit for any.
offsetNoSkip this many results (paging).
countryNoCountry 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).
settingNo'outdoor' = open-air courts; 'indoor' = indoor or covered.any
radius_kmNoSearch radius around lat/lon, km.
min_courtsNoMinimum number of courts at the venue.
match_unknownNoAlso return courts where a filtered property is not mapped (unknown).
open_to_publicNoOnly 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / free / description
      Previous value: -"Only courts mapped as free of charge (fee=no)."New value: +"Only courts mapped with no fee (fee=no)."
    • changedInput schema / properties / open_to_public / description
      Previous 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."
  2. Changed1 schema field changed
    • changedInput schema / properties / city / description
      Previous 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."
  3. Changed1 schema field changed
    • changedInput schema / properties / open_to_public / description
      Previous 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."
  4. Changed1 schema field changed
    • removedInput schema / properties / include_private
      Removed 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"
      -}
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources