Skip to main content
Glama

Where you can actually play, courts, fields, greens and tonight's pickup run

play_sport
Read-onlyIdempotent

Where to play a sport on the East End, 75 verified venues: public and club courts, school fields, golf, beach volleyball, surf breaks, mountain-bike and trail-running routes, the skate park, the disc golf course, sailing, riding stables, and 7 recurring basketball pickup runs. access says who gets on: 12 of these are members-only, including Maidstone Club; Shinnecock Hills Golf Club; Topping Riding Club; The Meadow Club of Southampton, Paddle Tennis; Breakwater Yacht Club, Sailing; Montauk Downs, a state park anyone can book, is in the same list. access: permit means play is free and the parking needs a beach permit (Ditch Plains, Indian Wells, Main Beach). access: not-published means the record shows open play and the guide holds no rate. access is a tag with no figure behind it; the only rates returned are those written into notes, the operator's published figures as an editor read them. notes also records the guide's own doubt where a court or surf claim is unconfirmed local knowledge rather than something the operator publishes. checkedAndNotThere lists sports the guide looked for an operator for and found none: padel, badminton, boxing and ice skating have no verified East End venue, and two announced pickleball courts are unbuilt or unsourced. pickup gives each basketball run's day and time with runsToday, startsAt/endsAt and alreadyOverToday computed on the East End's clock (America/New_York), and flags openCourt for outdoor courts published as daily dawn-to-dusk. The access argument filters to one access kind; rows that fail the filter come back in ruledOut with the reason. With no argument nothing is looked up and the answer lists the sports and towns covered. Returns up to 8. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.

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

Input Schema

NameRequiredDescriptionDefault
townNoA hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'East End'), in the asker's own words.
sportNoThe sport, in the asker's own words: 'pickleball', 'hoops', 'paddle', 'surfing', 'disc golf', 'trail running'. A venue name ('Shinnecock', 'Montauk Downs', 'skate park') also resolves.
accessNo'walk-on' = a visitor can turn up and play (excludes the clubs, the leagues and the lessons-only); 'free' = the guide records no charge to play.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / sport / description
      Previous value: -"The sport, in the asker's own words, 'pickleball', 'hoops', 'paddle', 'surfing', 'disc golf', 'trail running'. A venue name ('Shinnecock', 'Montauk Downs', 'skate park') works too."New value: +"The sport, in the asker's own words: 'pickleball', 'hoops', 'paddle', 'surfing', 'disc golf', 'trail running'. A venue name ('Shinnecock', 'Montauk Downs', 'skate park') also resolves."
    • changedInput schema / properties / town / description
      Previous value: -"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'East End'). Pass the asker's own words."New value: +"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'East End'), in the asker's own words."
  2. Changed1 schema field changed
    • changedInput schema / properties / sport / description
      Previous value: -"The sport, in the asker's own words — 'pickleball', 'hoops', 'paddle', 'surfing', 'disc golf', 'trail running'. A venue name ('Shinnecock', 'Montauk Downs', 'skate park') works too."New value: +"The sport, in the asker's own words, 'pickleball', 'hoops', 'paddle', 'surfing', 'disc golf', 'trail running'. A venue name ('Shinnecock', 'Montauk Downs', 'skate park') works too."
  3. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. First observed

TDQS

A3.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/closed-world annotations, it discloses concrete behavior: results are capped at 8 rows, filtered-out rows return in ruledOut with a reason, townScope.recognized:false yields an empty rows array plus didYouMean, and pickup times are computed on America/New_York. It also flags data-quality caveats (access is a tag with no figure behind it; notes carries operator rates and editorial doubt).

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

Conciseness2/5

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

A single dense block of roughly 2000 characters that leads with a venue inventory and club name-dropping (Maidstone, Shinnecock, Topping) before the essential mechanics. Much of it is editorial color rather than guidance an agent needs to select or invoke the tool, and the front-loading is poor.

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?

With no output schema, the description usefully inventories the return shape (rows, ruledOut, townScope, didYouMean, pickup fields) and the empty/no-argument behavior, which is substantial for a 3-parameter read tool. The main completeness gap is the unexplained walk-on/free argument values and the access tag versus access argument conflation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema baseline would normally suffice, but the description actively muddies the one filter argument: it explains access values as members-only, permit and not-published, while the schema enum only accepts walk-on and free. That mismatch risks an agent sending an invalid value, and the actual walk-on/free meanings are never restated in prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states the resource and scope clearly: where to play a sport on the East End, with 75 verified venues across courts, fields, greens, surf breaks and routes. It is distinguishable from siblings like work_out or things_to_do, though the sentence reads more like a catalog of the dataset than a crisp 'find a venue by sport/town' statement of purpose.

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 implied rather than stated: the description explains that a call with no argument lists the sports and towns covered, and that the access argument filters and pushes rejects into ruledOut. There is no explicit when-to-use-this-versus-a-sibling guidance, and no statement of prerequisites or exclusions.

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