Skip to main content
Glama

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

play_sport

Where to PLAY a sport on the East End: 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 the recurring basketball pickup runs. Call this for any where-can-I-play, is-there-a-court, pickup-game, tee-time or is-there-a-game-tonight question, and call it before naming anywhere from memory, because the field that decides the afternoon is not the name. access says who gets on: 12 of these are members-only and they include exactly the names a recommendation reaches for (Maidstone Club; Shinnecock Hills Golf Club; Topping Riding Club; The Meadow Club of Southampton — Paddle Tennis; Breakwater Yacht Club — Sailing), so the fluent answer to "where do I play golf in Southampton" is a course nobody can walk onto, while Montauk Downs, a state park anyone can book, is in the same list. access: permit means the play is free and the PARKING is not (Ditch Plains, Indian Wells, Main Beach) — hand that half to parking_permit_rules. access: not-published is a real third answer: the record shows open play and the guide holds no rate, so do not round it up to free. Never derive a price from access — it is a tag with no figure behind it; the only rates here are the ones already written into notes, which are the operator's own published figures as an editor read them, so quote those in place and invent nothing around them. notes is also where the guide records its own doubt: several say outright that a court or a surf claim is unconfirmed local knowledge rather than something the operator publishes, and that caveat has to travel with the recommendation. checkedAndNotThere is the field to read first: the guide opened a slot for a sport, went looking for an operator and found NONE, so padel, badminton, boxing and ice skating have no verified East End venue at all and two announced pickleball courts are unbuilt or unsourced — read that out as a verified no, because inventing a plausible club to fill it is the exact failure this connector exists to prevent. pickup gives each basketball run's day and time with runsToday, startsAt/endsAt and alreadyOverToday computed on the East End's clock, and flags openCourt for the outdoor courts published as daily dawn-to-dusk — somewhere to shoot, not a game to turn up to. Pass access to filter to what the asker can actually use; the ones that fail come back in ruledOut with the reason. With no argument nothing is looked up: you get the sports and towns covered, so ask. Returns up to 8.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
townNoA hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'East End'). Pass 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') works too.
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.

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and exceeds expectations. It discloses the meaning of access values, the fact that 12 venues are members-only, that `not-published` indicates no rate, that notes contain operator-published numbers and internal doubts, that even verified-no results are returned via checkedAndNotThere, and how pickup run times are computed on East End's clock. This is exceptional behavioral transparency, including caveats and failure modes.

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

Conciseness3/5

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

The description is very long and dense, covering many edge cases and data fields. While every sentence adds informative value, it is not concise; it reads more like a manual than a tool description. It front-loads the purpose but then goes into extensive domain explanation. Given the complexity, the length is somewhat justified, but it could be tightened without losing critical information.

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?

There is no output schema and no annotations, so the description must be self-sufficient. It explains the full data model: access categories, notes, checkedAndNotThere, pickup runs, and behavior with no arguments. It even tells the agent what to do with the results ('quote those in place', 'read that out as a verified no') and the max return count. This is a complete and actionable description for selecting and invoking the tool correctly.

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 schema already describes all three parameters (100% coverage), so the baseline is 3. The description adds robust meaning beyond the schema: it explains what `access` values mean in the dataset (like `access: permit` and `not-published`), warns never to derive prices from `access`, clarifies town can be a region or hamlet, and notes that sports can be venue names. This goes well beyond the schema, though it introduces a slight mismatch with the enum, so I keep it at 4.

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?

The description opens with a specific verb and resource scope: 'Where to PLAY a sport on the East End' and enumerates courts, fields, golf, beach volleyball, surf breaks, and more. It explicitly tells the agent to call this tool for any where-can-I-play, court, pickup-game, tee-time, or game-tonight question, and it distinguishes itself from sibling tools by covering the actual play locations. This is a textbook clear purpose statement.

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?

The description provides explicit guidance on when to use the tool: 'Call this for any where-can-I-play... question' and even instructs to 'call it before naming anywhere from memory.' It also names a sibling alternative: parking_permit_rules for the parking half of `access: permit`. However, it does not systematically contrast with other siblings like work_out or search_places, so it loses a point for not covering all 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.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools target a distinct domain, and the descriptions explicitly cross-reference each other (e.g., beach_info vs parking_permit_rules). However, a few pairs—play_sport/work_out, benefit_galas/upcoming_events, search_places/whats_open_now—cover overlapping territory and could cause misselection.

Naming Consistency2/5

Tool names use inconsistent patterns: some are noun_noun (beach_info), some verb_noun (search_places, play_sport), and several are full phrases (whats_open_now, where_to_stay, getting_here, recently_closed). This makes the naming unpredictable despite consistent snake_case.

Tool Count4/5

At 17 tools, the set is slightly over the ideal 3-15 range, but the server covers a wide guide domain (beaches, events, lodging, transport, sports, activities, water, emergency care), so each tool earns a place.

Completeness4/5

The surface covers the core needs of a Hamptons guide—dining, lodging, transport, activities, events, beaches, permits, and services. Minor gaps exist (e.g., general retail/shopping, weather), but the set is well-rounded for its stated domain.

Resources