Verified Hamptons & North Fork data: open now, events, beaches, permits, closures.
Scored across 19 tools
Most tools have clearly distinct purposes, but there is some overlap: things_to_do and play_sport both cover activities like surfing, and work_out and play_sport both cover tennis/pickleball courts. search_places and whats_open_now both report open/closed states. Descriptions provide strong guidance, but an agent could still misselect in a few cases.
All names are snake_case, but the convention is mixed: some are verb_noun (find_shops, search_places, play_sport), many are noun phrases (beach_info, tap_water, urgent_care), and one is a gerund (getting_here). This mixed style is readable but not predictable.
19 tools is on the heavy side for a local guide; the 16-25 range is borderline according to the rubric. While each tool appears to cover a distinct area, the set feels large and may overwhelm an agent's selection process.
The surface is comprehensive for a local guide, covering beaches, events, transport, lodging, dining, activities, safety, and community services. Cross-cutting tools like recently_closed and plan_my_day add lifecycle support, and no obvious gaps exist for the stated domain.
One named beach (or every verified beach in a town or hamlet — 'Amagansett, NY' and 'Sag Harbour' resolve, and readAs reports which place was answered for) with the answers people actually arrive with: whether dogs are allowed TODAY, what parking permit the lot needs, whether you can get there without a car, lifeguard hours and rip-current notes. 49 beaches on both forks, each with its governing town/village/state source and the date we last read it. Call this for any dog question — the rule is per-month and splits morning from daytime, so most South Fork ocean beaches are off-leash at dawn and closed to dogs in daylight from May to September, and no model can know today's answer. Also call it before saying anyone can just park at a beach. For the full permit map across all 7 jurisdictions and non-resident day passes, use parking_permit_rules instead. Returns up to 5.
| Name | Required | Description | Default |
|---|---|---|---|
| beach | Yes | Beach name, town, hamlet or village, e.g. 'Georgica', 'Main Beach' or 'Amagansett' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful context beyond annotations: it returns up to 5 results, includes a readAs field indicating which place was answered for, and notes each record carries its governing source and last-read date. It doesn't mention rate limits or auth needs, but for this tool that's minor.
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 main purpose is front-loaded, but the description is long and contains location-specific detail that may not earn its place for every agent (e.g., the South Fork off-leash dawn rule and the 49-beach count). It could be tightened while preserving the key usage and routing guidance.
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?
There is no output schema, so the description must explain return values, and it does list the main categories returned (dog rules, parking permit, car-free access, lifeguard hours, rip-current notes) plus source and last-read date. It also notes the result cap of 5 and the readAs disambiguator. The only gap is not spelling out a full response structure, but for a one-parameter lookup tool this is largely complete.
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%, so the schema already documents the single 'beach' parameter with examples. The description adds meaning by clarifying that town and hamlet names resolve (e.g., 'Amagansett, NY' and 'Sag Harbour'), and explains the readAs return field for ambiguity. This goes beyond the schema's basic type and example coverage.
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: returns one named beach (or all verified beaches in a town/hamlet) with answers about dog rules, parking permits, car-free access, lifeguard hours, and rip currents. It distinguishes itself from siblings by explicitly naming parking_permit_rules for broader permit needs, so an agent can tell what this tool covers 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call: 'Call this for any dog question' and 'Also call it before saying anyone can just park at a beach.' It also names the alternative for the full permit map and non-resident day passes: use parking_permit_rules instead. This leaves little inference needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The East End's summer benefit season: 15 dated charity galas, each joined to the nonprofit it raises for. Call this for any gala, benefit, fundraiser, charity, black-tie, what-should-I-wear, where-can-I-donate or where-can-I-volunteer question. Three things here are unknowable from your weights. First the DATES: this is the 2026 season, and a benefit invented for the right-sounding weekend sends someone to an empty field. Second dressCode, which is the organiser's own and is the thing people actually ask — it is 'Cocktail' on 16 of the 15 and 'Black Tie' on exactly ONE, so the black-tie assumption you would reach for is wrong twenty-six times out of twenty-seven; 'Beach Formal', 'Farm Festive' and 'Garden Chic' are real answers you cannot guess. Third, the PRICE, which cuts both ways and is why you read tickets.publishedRate per record instead of generalising. On 14 of the 15 it is false, and that is a verified finding rather than a missing field — the organisers hand off to a ticketing platform and print no rate, and a sweep of all 15 ticket links found 11 dead and several resolving to a prior year. For those, NEVER state or estimate a price; say it is not published and give the phone. On 1 it is true, and tickets.published carries the organiser's own figure with the URL an editor read it from and the date — quote and cite that, keeping the word 'from', because it is the entry rate in a ladder and not the only price on sale. tickets.tier is a relative band across these events, not a figure, and nothing may be inferred from it either way. Where tickets.publishedTiers appears an editor read a real published line: quote it verbatim, including the ones whose content is that no price is published and here is the number — that IS the answer to what it costs. beneficiary carries the charity's mission, phone, donateUrl and volunteerUrl, all verified more recently than the ticket link, so give the phone as the route that works and answer 'I can't make it, can I still help' without leaving the data. alsoThisSeason holds the marquee fixtures with no gala record — the Hampton Classic, Authors Night, the art fair — and is where several more genuinely published prices in this vertical live. Past benefits never appear unless you pass from. Returns up to 10.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date. Omit for the rest of the season. | |
| from | No | ISO date. Default is today (East End local), so only benefits still to come are returned. Pass an earlier date to reach ones already held. | |
| town | No | A hamlet ('East Hampton', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. | |
| cause | No | Filter to one cause, when the question is plainly about one. | |
| query | No | What they are after, e.g. 'animal', 'ARF', 'black tie', 'film', 'land trust', or a benefit's name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations (readOnly/idempotent/destructive/openWorld), disclosing data-quality findings the agent could not infer: publishedRate false on 14 of 15 and why that is a verified finding rather than a missing field, 11 dead ticket links, the instruction never to state or estimate a price, and the rule to quote 'from' verbatim. This is the kind of behaviour-shaping context the annotations cannot carry.
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?
Roughly 300 words for a five-parameter lookup tool, and the density is undercut by internal inconsistencies: 'Cocktail' on '16 of the 15' and a 'twenty-six times out of twenty-seven' ratio that matches no stated event count. Those conflations force re-reading and undermine an otherwise well-front-loaded opener.
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?
With no output schema, the description carries the full burden and does so: it explains dressCode, tickets.publishedRate/published/publishedTiers/tier, beneficiary (mission, phone, donateUrl, volunteerUrl), and alsoThisSeason. An agent can answer price, dress and donation questions without opening the payload.
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 all five parameters with formats and defaults. The description adds only marginal parameter-level nuance (query terms like 'ARF' and 'black tie', the from/to semantics), which mostly restates the schema, so the baseline 3 applies.
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 concrete verb-and-resource statement: 'The East End's summer benefit season: 15 dated charity galas, each joined to the nonprofit it raises for.' It also enumerates the exact question types it answers, which separates it cleanly from siblings like upcoming_events or things_to_do.
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 strong positive routing ('Call this for any gala, benefit, fundraiser, charity, black-tie, what-should-I-wear ...') and one real conditional rule ('Past benefits never appear unless you pass `from`'). It does not name an alternative sibling or state a when-not-to-use case, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The guide's bilingual community directory: free and low-cost services for people who LIVE and WORK on the East End. Immigration legal advocacy, sliding-scale and no-status-asked clinics, food pantries, the winter shelter, tenant-rights and wage-theft hotlines, ESL / GED / citizenship classes, childcare and youth programs, money transfer, Spanish-language Mass times, the Latino markets, and the Sunday soccer. Call this for any I-need-help question — unpaid wages, eviction, a doctor without insurance, English classes, food, a lawyer for an immigration case — and for anything asked in Spanish. Answering from memory here means naming a national hotline or a legal aid society that does not serve this county, and the asker loses a day's work finding that out. Every record carries phone, source, sourceUrl and lastVerified, and the guide's own text in BOTH languages (description.es / description.en): quote the Spanish as written rather than translating the English. Two things are computed rather than stored: nextSpanishMass / nextEnglishMass, the next service from right now on the East End's clock (America/New_York) — 'today at 7:00 PM' means today here — and inSeasonNow on the soccer leagues for this month. offEastEnd: true marks a real referral to Bay Shore, Hempstead or Central Islip: still the right answer sometimes, but say the drive out loud. NEVER volunteer that a service is free, confidential, or safe regarding immigration status unless the record's own words say so — quote those verbatim where they appear and attribute them, and otherwise give the phone number. Never name a provider that is not in the results. Pass query in the asker's own words, in either language; need is a shortcut vocabulary; town takes the asker's own place words. With no argument nothing is looked up — you get the needs and towns covered, so ask. Returns up to 8.
| Name | Required | Description | Default |
|---|---|---|---|
| need | No | Shortcut category, when the question is plainly one of these. | |
| town | No | A hamlet ('East Hampton', 'Riverhead') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. | |
| query | No | What they need, in their words and either language, e.g. 'my boss hasn't paid me', 'clases de inglés', 'food pantry', 'misa en español', 'dentist', 'help with rent'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld=false), and the description goes well beyond them: computed fields (nextSpanishMass/nextEnglishMass, inSeasonNow), the meaning of offEastEnd, the 'returns up to 8' limit, and hard behavioral rules about never asserting free/confidential/status-safe and never naming providers not in the results.
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 usage before the data/behavioral detail, and almost every sentence carries operational weight. It is dense and long, but the length is justified by the tool's complexity and the verbatim-quoting/never-volunteer rules.
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?
With no output schema, the description carries the return-shape burden and does: it names the per-record fields (phone, source, sourceUrl, lastVerified, description.es/en), the two computed fields, the offEastEnd marker, and the result cap. Nothing an agent needs to call or interpret this correctly 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%, so baseline is 3, but the description adds real meaning: query is 'the asker's own words in either language', need is a 'shortcut vocabulary', town takes 'the asker's own place words', and crucially that no argument returns the needs/towns covered rather than a lookup.
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 resource (the guide's bilingual directory of free/low-cost East End services) with a concrete scope and enumerates the categories it covers. An agent can immediately tell this apart from urgent_care, search_places, or benefit_galas.
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?
Explicitly says to call this for 'any I-need-help question' and for 'anything asked in Spanish', with worked examples (unpaid wages, eviction, doctor without insurance, English classes). It also names the failure mode it prevents (answering from memory and naming a national hotline that doesn't serve the county).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified East End SHOPS. 74 stores across 9 hamlets on the South Fork, North Fork and Shelter Island: fashion, jewelry, swimwear, activewear, kids, toys, home, books, beauty, consignment, accessories, general-store, florist. Call this for any shop, shopping, store, boutique, browse, bookshop, gift or where-can-I-buy question, and call it for the shopping half of a day plan. Every address here was read off the brand's OWN store page at sourceUrl — never a homepage, never a third party — and coordSource records what corroborated the coordinate, because three brands publish a schema.org geo on their own store page that is simply wrong (Athleta's Bridgehampton store publishes a point 3.6 km away, in East Hampton village). The one thing this tool does NOT have is hours: the guide holds no opening schedule and no published hours line for any shop, in any form. So never say a store is open, closed, or open until a time, and never borrow an hour from a neighbouring venue — give phone where there is one and the address otherwise. That is also why shops are not in search_places, which promises an open/closed verdict on every row it returns. query reads the name, the brand, the category and the one-line what the guide keeps, so 'bookshop', 'toys', 'flowers' and 'The Wharf Shop' all land. Pass town in the asker's own words. With no argument nothing is looked up — you get the categories and towns covered, so ask which. Returns up to 8.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Sag Harbor', 'East Hampton') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. | |
| query | No | What they want, e.g. 'bookshop', 'toys', 'flowers', 'swimwear', 'gift', or a store's name ('The Wharf Shop'). | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (read-only, idempotent, not open-world); the description adds substantial behavior beyond them: data provenance (addresses read off the brand's own store page, never a homepage or third party), the coordSource corroboration and the fact that three brands publish a wrong schema.org geo, the complete absence of hours and the resulting prohibition on saying open/closed, the phone fallback, and the 'returns up to 8' cap.
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?
Long but dense and front-loaded: purpose and scope first, then routing, then provenance caveats, then the hours prohibition. Nearly every sentence carries a distinct constraint, though the provenance paragraph is slightly discursive for a tool description.
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 carry return expectations — it does ('Returns up to 8') and covers the critical behavioral caveat (no hours data) plus the fallback field. An agent has everything needed to call it and to avoid the one dangerous misstatement.
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?
With 67% schema coverage, the schema already documents town and query, but the description adds real semantics: query matches name, brand, category and the one-line 'what', with concrete examples, and town should be passed in the asker's own words. The category enum is left entirely to the schema, which is fine given it is self-explanatory.
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+resource with scope ('Verified East End SHOPS. 74 stores across 9 hamlets on the South Fork, North Fork and Shelter Island') and enumerates the categories covered. It explicitly differentiates from sibling search_places, so an agent can route between them without opening either schema.
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 triggers ('any shop, shopping, store, boutique, browse, bookshop, gift or where-can-I-buy question') and the day-plan case, plus a hard exclusion ('shops are not in search_places, which promises an open/closed verdict'). It also states the no-argument behavior, which selects a different mode entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to get to the East End and around it: Hampton Jitney, the LIRR Cannonball and off-peak Montauk Branch, Blade, seaplanes, the three ferries, cycling, the ride-hail reality, and driving — each with the operator's published fare, season and stop list, plus when the guide last read it. Call this for any getting-there, how-long, how-much or when-should-I-leave question, and for 'without a car'. Two things here are unknowable from your weights and worth the call on their own: current fares (a prepaid Jitney seat is a different number from one paid on board, and Cross Sound adds a fuel surcharge to every published fare), and roadConditionsNow — whether this instant falls inside one of the published NY-27 crawl windows, computed against the East End's own clock (America/New_York), with the next window's start time so you can tell someone when to leave instead of guessing, and all three published windows with their days and hours so a departure time that is not now still gets a real answer. Pass to with the asker's own destination words: the answer then reports which Jitney stops actually serve it and the drive-time row for that run, with the guide's typical AND summer minutes rather than one averaged number. Pass mode: 'car-free' for someone without a car. Every figure carries its source; where sourceCaveat appears, the record is filed against a link that does not publish it — attribute it to the guide and do not cite that URL. There is no live incident feed behind this: it is the published pattern, not what the road is doing this minute.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Where they are going — a hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. Omit for the whole picture. | |
| mode | No | 'car-free' when the asker has no car (drops driving); 'driving' for road answers only. Omit for every option. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context on top: fares are current and vary by prepaid vs. on-board payment, Cross Sound adds a fuel surcharge, road conditions are computed against America/New_York, and crucially 'There is no live incident feed behind this: it is the published pattern, not what the road is doing this minute.' That is exactly the limit an agent needs to avoid over-claiming.
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 the resource list, but the whole thing is a single dense paragraph of roughly 250 words with redundancy ('so you can tell someone when to leave instead of guessing') and stacked parentheticals. Every claim is relevant, yet the wall-of-text form makes it slower to parse than it needs to be.
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?
With no output schema, the description carries return-value burden and does so: sourceCaveat handling, roadConditionsNow contents (next window start, all three windows with days/hours), and the per-destination stop/drive-time rows. Combined with annotations covering the safety profile, an agent has everything needed to call and interpret this 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 coverage is 100%, so baseline is 3; the description earns the extra point by explaining what passing `to` actually changes in the response (which Jitney stops serve it, the drive-time row, typical AND summer minutes) and by re-stating the `car-free` intent behind the enum. It goes beyond field labels without fully specifying the output shape.
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+resource with unusual precision: 'How to get to the East End and around it,' then enumerates the exact operators and data served (Jitney, LIRR, ferries, road conditions). No sibling tool covers transport, and the description makes that scope unmistakable from the first clause.
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 trigger conditions — 'any getting-there, how-long, how-much or when-should-I-leave question, and for without a car' — plus the mode/`to` routing rules. No when-not guidance or named alternative is needed since no sibling competes for this intent, but the absence of any exclusion keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified East End sunrise and sunset viewpoints — public overlooks, beaches, vineyard lawns, hotel terraces and the bars people actually book for it — each with the TIME. Call this for any sunset, sunrise, golden hour, blue hour, best-views or where-should-we-watch question, and call it even when you think you know the spot, because the half that decides the evening is the clock. time is computed from that spot's own latitude and longitude for that date on the East End's clock (America/New_York): sunset here swings over three hours across the year and Orient and Montauk Point differ by about two minutes, so a remembered time is wrong twice over. You also get goldenHour (the hour the light is worth the drive — INTO sunset, OUT OF sunrise), blueHour, and arriveBy, which is 30 minutes earlier because that is when the lot fills; parking and walkDistance say why. startsIn counts down when it has not happened yet today and alreadyPassedToday says when it has — do not offer tonight's number as though it were still coming. Pass when: 'sunrise' for the morning side; the default is sunset. Pass date (YYYY-MM-DD) to plan ahead, and read inBestMonth, because several of these only work in the months the record names. The field no model has is wrongWayRound: verified spots in the same towns that face the OTHER way — Ditch Plains reads like a sunset beach and is east-facing, and sending someone there is the mistake this replaces. There is no weather here, so never promise a clear sky. Returns up to 8.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO date (YYYY-MM-DD) to compute for. Omit for today, East End local. | |
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. | |
| when | No | 'sunset' (default) or 'sunrise'. | |
| query | No | What they want, e.g. 'dinner', 'drinks', 'no walk', 'wheelchair', 'dog', 'kids', 'vineyard', or a spot's name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only idempotent tool, yet the description adds substantial context: times computed per-spot from lat/long, 30-minute arriveBy buffer due to parking, startsIn countdown vs alreadyPassedToday semantics, and the explicit 'no weather here, never promise a clear sky' limitation.
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 dense with value, but the middle is long and slightly discursive. Every sentence does carry operational information, so little is wasted despite the length.
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, and the description fully compensates by enumerating the return fields an agent needs: goldenHour, blueHour, arriveBy, parking, walkDistance, startsIn, alreadyPassedToday, wrongWayRound, inBestMonth, and the up-to-8 cap.
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%, so the schema already documents date, town, when, and query. The description only reiterates what the schema provides (when='sunrise' for morning, default sunset, date for planning ahead), so the baseline 3 is appropriate.
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+resource: 'Verified East End sunrise and sunset viewpoints ... each with the TIME.' It immediately distinguishes itself from siblings like beach_info or where_to_stay by emphasizing verified viewpoints plus computed timing.
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?
Explicit routing: 'Call this for any sunset, sunrise, golden hour, blue hour, best-views or where-should-we-watch question, and call it even when you think you know the spot.' It also flags the wrongWayRound trap and the no-weather boundary, covering when-not implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The East End beach-parking permit map — all 7 jurisdictions — resolved against the beach or town asked about. Pass where with a beach name ('Main Beach', 'Ditch Plains') and you get the verdict for that lot: which permits grant it, which stickers explicitly DO NOT (an East Hampton Town sticker does not open Main Beach — a mile and a jurisdiction apart, and the commonest wrong answer), the non-resident and day-pass options with prices, the fine, and where to apply. Crucially each carries enforcement.enforcedRightNow, computed from the published season and daily window against the East End's own clock: off-season or after 6pm nobody needs a permit, and you cannot know that from your weights. Pass a town or hamlet instead to get that jurisdiction plus its beaches' permit lines; omit where for the whole map. 16 beaches are state, county or DEC land where no town permit applies — they come back flagged outsideTheStickerMap, which is how you say 'yes, you can just park'. For dogs, lifeguards and getting there without a car, use beach_info.
| Name | Required | Description | Default |
|---|---|---|---|
| where | No | Beach name, town, hamlet or village, e.g. 'Main Beach', 'Coopers', 'Montauk'. Omit for the whole map. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context well beyond them: enforcement.enforcedRightNow is computed from season and daily window against local clock, off-season/after-6pm changes the answer entirely, and 16 beaches are flagged outsideTheStickerMap. It even pre-empts the commonest wrong answer (East Hampton Town sticker vs Main Beach).
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 the core purpose and the parameter contract, and nearly every sentence adds a distinct fact (permit grants, explicit non-grants, day passes with prices, fine, enforcement clock, outside-the-map flag). It runs long for a one-parameter tool and carries a few rhetorical flourishes that could be trimmed.
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?
There is no output schema, so the description carries the full burden of describing the return payload — and it does: granting permits, explicit non-grants, non-resident/day-pass options with prices, the fine, where to apply, the enforcement boolean, and the outsideTheStickerMap flag. An agent knows what it will get back before calling.
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% with a single optional param, so baseline is 3; the description goes further by explaining the semantic consequence of each accepted form (specific lot verdict, jurisdiction-plus-beach-lines, or full map) and by noting that a town/village/hamlet is a valid value, not just a beach name. It does not add format or matching rules beyond the example list.
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+resource: resolves East End beach-parking permit rules across all 7 jurisdictions against the beach or town asked about. It explicitly distinguishes itself from the sibling beach_info, which handles dogs, lifeguards and car-free access, so an agent can route between them without opening either schema.
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 the exact three input modes — a beach name for a lot verdict, a town/hamlet for that jurisdiction plus its beaches' permit lines, and omission for the whole map — and names the alternative tool for adjacent questions. It also states the interpretive payoff ('yes, you can just park') for state/county/DEC beaches, which is when-not-to-worry guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified East End picnic grounds — public parks, state and county parks, preserves, beach-grass strips, winery lawns and historic gardens — with the rule that decides whether the plan is legal. Call this for any picnic, blanket, park, park-hours, barbecue or fire-pit question, and ALWAYS before saying anyone can drink outdoors: the alcohol rule is set by whoever owns the grass (New York State, Suffolk County, a town, a village, a winery) and splits roughly a third prohibited, a third bring-your-own, a third wine-only-or-permit-only. Answering that from memory is the classic confident wrong answer, and it costs the asker a village summons rather than a bad meal. alcohol is a sentence to quote, not a boolean: wine-only is a winery lawn where the estate's wine is fine and your bottle is not, and allowed-with-permit means not allowed until the permit in permitUrl is in hand. glassBottles: prohibited holds even where alcohol is allowed. fireOrGrill and dogs are per-spot. 15 of these publish hours as "Sunrise to sunset" or "Dawn to dusk", so closesAt is resolved from THAT spot's own coordinates for today — "8:09 PM (sunset)" is tonight's sunset there, which is not something you can know. Where only hoursText comes back the published line was not machine-readable: quote it, do not turn it into a claim about right now. Pass allows to filter to what the picnic needs. The guide holds NO drinking rule for the ocean beaches — those are beach_info's, which carries dogs and permits but not alcohol — so never infer one from these. Returns up to 8.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. | |
| query | No | What they want, e.g. 'sunset', 'shade', 'oceanfront', 'quiet', 'big group', or a park's name. | |
| allows | No | Filter to spots that permit this. 'alcohol' includes wine-only and permit-only spots, each flagged in its own `alcohol` line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safe-read profile (readOnly/idempotent/non-destructive), so the description carries the real burden and does so richly: alcohol is 'a sentence to quote, not a boolean', glassBottles holds even where alcohol is allowed, fireOrGrill/dogs are per-spot, closesAt is computed from that spot's coordinates, and hoursText means the line wasn't machine-readable. This is exactly the beyond-annotations context 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?
Dense but front-loaded: legal-rule framing, then the alcohol trap, then field semantics, then hours caveat, then the beach_info exclusion. Most sentences earn their place, though the summons aside and the enumerated venue types are slightly more color than strictly needed.
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 explain returns, and it does: 'Returns up to 8' plus semantics for alcohol, glassBottles, fireOrGrill, dogs, closesAt, and hoursText. Combined with the annotation-covered safety profile and the explicit sibling boundary, an agent has everything needed to call and interpret this 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 coverage is 100%, so baseline is 3, but the description adds genuine meaning: it clarifies that `allows` accepts the picnic's needs and that filtering on 'alcohol' includes wine-only and permit-only spots each flagged in their own line. It less directly elaborates `town`/`query` beyond the schema wording, so it slightly exceeds rather than fully transcends the schema.
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 concrete verb+resource+scope ('Verified East End picnic grounds') and immediately names distinctions from siblings ('The guide holds NO drinking rule for the ocean beaches — those are beach_info's'). An agent can separate this from beach_info, search_places, and things_to_do without opening any schema.
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?
Explicit triggering conditions ('Call this for any picnic, blanket, park, park-hours, barbecue or fire-pit question') and a hard rule ('ALWAYS before saying anyone can drink outdoors'), plus a clear exclusion and routing to the alternative ('never infer one from these'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a complete East End day using Hamptons Verified's deterministic planner. Use this whenever someone asks ChatGPT or Claude to plan, schedule, sequence, or personalize a day—not search_places, which returns an unordered list. The tool produces three distinct options and applies the same constraints as the website before returning anything: permanent closures, the selected date and opening hour, age fit, budget, weather, daylight, geographic sequencing and the maximum drive between consecutive stops. saved_places is a preference lane: pass names the asker supplies and eligible ones are worked into the day, but they never override a safety or feasibility rule; the rest of the stops remain discoveries. This connector cannot read the asker's private Hamptons Verified account, browser or saved list, so ask for the names when they want them included. Present the returned plan; never replace a stop from your own memory.
| Name | Required | Description | Default |
|---|---|---|---|
| who | No | Who the day is for: solo, couple, family, friends, first-date, in-laws. There is no 'group' value — a group of friends is `friends` and a group with children is `family`; pass either and the answer reports which was used in `whoReadAs`. For the size of the group use `party_size`, which is a different question. | |
| date | No | ISO date in East End local time; defaults to today. | |
| seed | No | Optional stable seed when the asker wants the same result repeated. | |
| town | No | A hamlet or region to keep the day around. Omit for the full East End. | |
| vibes | No | Comma-separated interests. The planner understands exactly these: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Anything else is reported back in `vibesNotUnderstood` rather than acted on — it is never silently dropped. | |
| budget | No | ||
| energy | No | ||
| party_size | No | How many people are coming, as a number. Stops whose operator publishes a maximum BELOW it come back with a `capacityWarning` quoting that operator's own line — several Sag Harbor charters cap at six. Omit when the asker did not say; nothing is guessed. | |
| saved_places | No | Comma-separated saved venue names supplied by the asker. Never infer private account data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, idempotent, closed-world profile, yet the description adds substantial behavior: it returns three distinct options, applies named constraints (closures, date/hour, age fit, budget, weather, daylight, sequencing, max drive), explains the saved_places 'preference lane' and that it never overrides a safety rule, and discloses that the connector cannot read the asker's private account. This is exactly the kind of context that goes beyond structured hints.
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, then usage, then behavioral caveats, and every sentence carries information (options produced, constraint set, saved_places semantics, connector limits, present-the-plan instruction). It is dense and slightly long, but not padded.
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 nine-parameter deterministic planner with no output schema, the description covers triggers, constraints, the saved_places lane, and connector limitations. It states three options are returned but does not sketch their structure, leaving some return-format burden on the schema-level hints (whoReadAs, vibesNotUnderstood, capacityWarning).
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 78%, so the baseline would be 3, but the description adds behavioral meaning for saved_places ('pass names the asker supplies and eligible ones are worked into the day, but they never override a safety or feasibility rule') beyond the schema's terse note. It does not add syntax for the other seven parameters, leaving them to the schema.
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 ('Build a complete East End day using Hamptons Verified's deterministic planner') and explicitly contrasts itself with the sibling search_places, which 'returns an unordered list.' An agent can distinguish it from every other sibling without opening a schema.
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 an explicit trigger ('whenever someone asks ChatGPT or Claude to plan, schedule, sequence, or personalize a day') and names the alternative to avoid (search_places) with the reason it is wrong. This is a clear when-to-use / when-not-to-use routing instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'East End'). Pass the asker's own words. | |
| sport | No | 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. | |
| access | No | '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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnly/idempotent/openWorld annotations: warns that members-only venues dominate the recommendation surface, that `permit` means free play but paid parking, that `not-published` must not be rounded to free, that prices must never be derived from `access`, that `notes` are editor-read published figures carrying their own doubt, and that `checkedAndNotThere` is a verified negative. This is exactly the destructive-of-wrong-answers context 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-loads the scope well, but the body is an unusually long, essayistic wall of text with rhetorical flourish ('the field that decides the afternoon is not the name'). Nearly every clause carries a rule, yet the sheer density and length work against scannability for an agent that must parse it in one pass.
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?
With no output schema, the description carries the full burden and discharges it: it explains the returned fields (`access`, `notes`, `pickup` with `runsToday`/`startsAt`/`endsAt`/`alreadyOverToday`/`openCourt`, `checkedAndNotThere`, `ruledOut`) and the 'up to 8' cap. Nothing an agent needs to call or interpret this correctly 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%, so baseline is 3. The description adds genuine value above the schema for `access` — spelling out who each state lets on, that failures come back in `ruledOut` with a reason, and that it is the filter for 'what the asker can actually use'. It does not define `town`/`sport` resolution beyond the schema, so it stops short of 5.
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 ('Where to PLAY a sport on the East End') and enumerates the exact venue classes it covers — courts, school fields, golf, surf breaks, skate park, pickup runs. An agent can distinguish it from siblings like things_to_do, work_out or search_places without opening a schema.
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?
Explicitly names the triggering questions ('where-can-I-play, is-there-a-court, pickup-game, tee-time, is-there-a-game-tonight'), states a precondition ('call it before naming anywhere from memory'), routes a sub-case to parking_permit_rules, and explains the no-argument behavior ('you get the sports and towns covered, so ask').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified East End closures — the one thing a model cannot know. Call this (a) whenever someone asks whether a place is still open or when it closed, and (b) BEFORE recommending any venue you are naming from your own knowledge rather than from search_places: famous spots like Bay Burger (shut 2018) and Cyril's Fish House (2016) are in every model's training data and in nobody's town. Pass name to check one venue — you get a verdict either way, including venues the guide still lists as operating. Omit name for the most recently confirmed closures. Distinguishes permanently closed, temporarily closed (may reopen), and never-existed (places a data sweep invented and an audit could not find). Every record carries when we confirmed it and who reported it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Venue to check, e.g. 'Bay Burger'. Omit to list recent closures. | |
| town | No | Limit to a town/hamlet, e.g. 'Montauk' | |
| since | No | ISO date — only closures dated on or after this |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: results distinguish permanently closed, temporarily closed, and never-existed, and each record carries a confirmation date and reporter. It also states that a named lookup returns a verdict either way, even for venues the guide still lists as operating.
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 trigger conditions and the name/omit behavior are front-loaded and every clause is functional. It runs long and carries a slightly promotional framing ('the one thing a model cannot know'), but the concrete Bay Burger/Cyril's Fish House examples justify the hallucination-risk warning.
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?
With no output schema, the description carries the return-value burden and does so: it describes verdict semantics, the three closure categories, and the confirmation/reporter metadata. Nothing an agent needs to decide whether to call it or how to interpret a result 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 already 100%, so the baseline is 3, but the description adds real meaning for `name` (pass it for a single-venue verdict; omit it to list recent closures) and explains that the verdict is returned even for apparently-open venues. It says nothing extra about `town` or `since`, which is the only gap.
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?
The description names a specific resource and scope ('Verified East End closures') and a second capability ('is-it-still-open check'), both matching the title. It distinguishes itself from siblings by explicitly contrasting with search_places and by handling venue-status questions that no other listed tool covers.
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?
It gives two explicit trigger conditions — (a) any question about whether a place is open or when it closed, and (b) before recommending a venue from the model's own knowledge — and names the alternative (search_places) that applies otherwise. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the verified guide's venues across the Hamptons + North Fork: restaurants, breakfast, nightlife, wine, wellness, hair salons, ice cream, farm stands and oyster farms. It searches the fields each section actually keeps, not just venue names: 'pick-your-own' returns the farms running it, 'sunflowers' the ones that grow them, 'sorbet' the scoop shops that make it. Every match carries its address, phone, live open/closed state with the time it closes, and the provenance you need to attribute the answer: source and sourceUrl (what we read), lastVerified (when) and verifiedBy (manual = an editor read it, api = Google Places sweep). Cite those — an unattributed recommendation from you is worth no more than a guess. Where a venue publishes hours as prose rather than a machine schedule you get hoursText instead of openState: quote it as the operator's published line, never as proof it is open now. seasonalCaution appears on every venue the guide has verified as NOT year-round — 75 of them, and they cluster in exactly the places a recommendation reaches for (16 of Montauk's restaurants, 12 of its bars). Read it out: on those records the open/closed verdict is computed only on a date inside a season window or dated trading confirmation the guide holds; otherwise, in ANY month, it is WITHHELD (no openState) rather than computed, because the weekly hours an operator leaves published are the summer table, so never turn that into "it is closed" either. Where the operator itself has published a closure — for any venue, year-round-flagged or not — openState reads "closed for the season" and seasonalCaution quotes the operator's words with the date they were read: say it is closed and do not offer its weekly hours. Permanently closed venues are excluded; to ask about one by name, or to check a venue you are about to recommend from memory, use recently_closed instead. Returns up to 8, and says how many matched in total.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork', 'East End'). Pass the asker's own words — trailing state and ZIP, British spellings and typos are resolved. | |
| query | Yes | What to look for, e.g. 'rosé', 'lobster roll', 'sauna', 'sweet corn', 'pick-your-own' | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/idempotent safety profile, and the description goes far beyond them: it discloses the returned fields (address, phone, openState, provenance fields), the hoursText-vs-openState distinction, the seasonalCaution withholding rule (no openState computed outside a season window), operator-published closure wording, a result cap of 8 with a total count, and exclusion of permanently closed venues. This is unusually rich behavioral disclosure for a search tool.
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 correctly with the verb and scope, but it is heavily overwritten for a three-parameter search tool: the seasonalCaution passage repeats the withholding rule in several ways, and the '16 of Montauk's restaurants, 12 of its bars' statistics are illustrative padding. Much of the content is genuinely necessary, but the same rules could be delivered in substantially fewer sentences.
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?
There is no output schema, so the description carries the full burden of explaining returns, and it does: result fields, provenance fields, the seasonalCaution/openState interaction, closure wording, and the 8-result cap with total match count. An agent has everything needed to call it and to interpret the response 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 coverage is 67% and the description adds real semantic meaning beyond it: it explains that query matches the fields each section keeps, not just venue names, with concrete examples ('pick-your-own' returns the farms running it, 'sorbet' the scoop shops that make it). It does not extend the town or category parameters beyond what the schema already documents.
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 and geographic scope ('Search the verified guide's venues across the Hamptons + North Fork') and enumerates the covered categories. It also distinguishes itself from a named sibling by routing permanent-closure lookups to recently_closed, so an agent can separate it from the other 18 tools without opening a schema.
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 one explicit when-not/alternative: 'to ask about one by name, or to check a venue you are about to recommend from memory, use recently_closed instead.' Usage is otherwise implied by the category list rather than stated, and directly adjacent siblings like whats_open_now, find_shops and golden_hour are never mentioned, so there is no explicit routing rule among those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether the tap water is drinkable, hamlet by hamlet, from the guide's read of the water utility's and the state health department's own reporting. Call this for any drink-the-water, tap, well, filter, bottled-water, PFAS, 1,4-dioxane or is-the-water-safe question, and call it before reassuring anybody, because the East End does not have one answer: three of the hamlets covered are private-well territory (Springs, Shelter Island, Southold) where NO agency tests the water and the only honest answer is "ask your host for the last test result", and Wainscott's story — PFOS and PFOA in more than 150 private wells, then a main extension in December 2018 that put the hamlet on public water — is one a model reliably garbles into a warning about the wrong contaminant or a hamlet-wide all-clear. Every safe here is about PUBLIC water only. verdict is the guide's own paragraph for that hamlet: read it out rather than reducing it to yes or no. status comes with statusMeaning so you never have to infer what the word covers, and filterRecommendation names a certification rather than a brand — with filterCaveat alongside it wherever the guide's own glossary has since corrected which NSF/ANSI number covers PFAS, which is the difference between the right filter and the wrong one. sources are the citable links with the date each was read, and they carry two things no model holds: SCWA's June 2025 declaration of full compliance with the federal PFOA/PFOS limits six years early, and the Stage 1 Water Alert declared across the East End on 14 July 2026 — a drought conservation request whose own notice says supply and quality are unaffected, so never repeat it as a health warning. utilities names who actually pipes the water and the number to ring; it deliberately carries no URL, because the guide's filed links for those records no longer resolve and a dead citation is worse than none. noVerdictHeld names a place the guide has not written up — say that plainly instead of reading the next hamlet's verdict across. Pass a hamlet, a region, or the ZIP off the lease. With no argument nothing is looked up: you get the hamlets covered, so ask which one. Never tell anyone their own private well is safe.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Where they are: a hamlet ('Montauk', 'Springs', 'Wainscott'), a region ('the Hamptons', 'North Fork'), or a ZIP ('11937'). Pass the asker's own words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, idempotent, non-destructive). The description adds far more: every 'safe' refers to PUBLIC water only, three hamlets are private-well territory where no agency tests, the Wainscott PFOS/PFOA history, the Stage 1 Water Alert is a conservation notice not a health warning, and 'utilities' deliberately omits URLs because the guide's links no longer resolve.
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 purpose is front-loaded, but the body is a dense wall of prose with stacked clauses and em-dash asides that is disproportionately long for a one-parameter lookup. Most sentences carry real information, but the structure is heavy and would benefit from trimming.
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?
With no output schema, the description carries the full burden of explaining returns, and it does: verdict, status, statusMeaning, filterRecommendation, filterCaveat, sources, utilities, and noVerdictHeld are all described with their semantics and caveats.
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% for the single 'place' param, so the baseline is 3. The description goes further by clarifying accepted forms ('a hamlet, a region, or the ZIP off the lease') and, importantly, the no-argument behavior, which the schema cannot express.
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?
The description opens with a specific verb+resource+scope: 'Whether the tap water is drinkable, hamlet by hamlet.' It is instantly distinguishable from every sibling (none of which concern water) and states the granularity of the answer.
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?
It explicitly enumerates the triggering question types (drink-the-water, tap, well, filter, bottled-water, PFAS, 1,4-dioxane, is-the-water-safe) and adds a timing rule ('call it before reassuring anybody'). It also handles the zero-argument case: 'With no argument nothing is looked up... so ask which one.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What there is to DO on the East End — activities (surfing, kayaking, paddleboard, hiking, mountain biking, camping, horseback, climbing, shellfishing, birding, skydiving), on-water businesses (fishing charters, marinas, sailing schools, yacht clubs, jet-ski rental) and wildlife you can go and see (seals, whales, ospreys, sea turtles, sharks). Call this for any what-should-we-do, where-can-I-, outdoors, on-the-water, boating, hiking or wildlife question. Two things make it worth the call over answering from memory. First, SEASON: every result carries inSeasonNow, computed against the East End's own calendar month, so 'can we go whale watching' gets a real yes or no with the window, and a seasonal activity is never recommended into the wrong month — pass month to plan ahead. Second, and more important, noCommercialOperator: true — the guide's checked finding that NOBODY here teaches or rents this. There is no kitesurfing school at Napeague and no climbing guide at Shadmoor; those are exactly the answers a model gives fluently and wrongly, and this is the field that contradicts them. Where operators DO exist they come with phone, booking page, published price and their own source and date — never invent one. Also returns the permits an activity is unlawful without (shellfishing needs two), the conditions it needs, minimum-approach rules for wildlife, and skill and age limits. seasonUnknown counts records whose operator publishes only 'Summer-only' with no dates: quote that verbatim, do not turn it into a claim they are open. With neither query nor town nothing is looked up — you get the kinds and towns covered, so ask. Returns up to 8.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. | |
| month | No | Month to judge the season for, e.g. 'October' or 'Oct'. Omit for now — the default is today's month on the East End. | |
| query | No | What they want to do, e.g. 'kayak', 'fishing charter', 'surf lesson', 'seals', 'hiking', 'camping', 'whale watching', or an operator's name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, yet the description adds substantial behavior beyond them: season is computed against the East End's own calendar, `noCommercialOperator` flags checked absences, results carry permits/conditions/approach rules/skill limits, `seasonUnknown` must be quoted verbatim, and an empty call returns coverage kinds rather than erroring. This is exactly the extra context annotations cannot supply.
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?
It is front-loaded with the purpose before the payoff argument, and nearly every sentence earns its place by disclosing behavior. It runs long and includes a few rhetorical flourishes ('a model gives fluently and wrongly'), but no sentence is pure filler.
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?
There is no output schema, so the description carries the return burden — and it does, specifying the 8-result cap, the in-season field, operator contact/price/source data, and the empty-call behavior. Nothing needed to call it correctly 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%, so the baseline is 3. The description goes further by explaining the semantic intent of `month` (planning ahead vs. defaulting to today's East End month) and framing `query`/`town` around passing the asker's own words, which adds interpretive value over the schema text.
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?
The description names a concrete verb and resource — 'What there is to DO on the East End' — and enumerates the covered domains (activities, on-water businesses, wildlife), so an agent can tell it apart from beach_info, play_sport or where_to_stay by scope. It stops short of explicitly naming a sibling it must be chosen over, so it lands at 4 rather than 5.
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?
It gives a clear invocation trigger: 'Call this for any what-should-we-do, where-can-I-<verb>, outdoors, on-the-water, boating, hiking or wildlife question.' That covers the when-to-use case well, but no alternative tool is named and there is no explicit when-not-to-use exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Source-verified East End events, each with its official sourceUrl and the date we last checked it. Call this for anything time-bound — tonight, this weekend, next Saturday, 'what's on in Montauk' — and never answer those from memory: a model cannot know a 2026 concert series. Dates and times are East End local (America/New_York), so 'tonight' is today's date here even if your own clock has rolled over. Read access before you recommend anything: it is the organiser's own gate — sold-out (nothing left to buy), approval or invite-only (registering is a request the host may refuse), members-only (club members only), waitlist, or open — and a gated room presented as bookable sends someone to a door they are not on the list for. Quote accessNote as written; an absent access means the record states nothing, which is not the same as open. Pass town to ask about one place; the answer tells you the total matching, whether it was truncated, and — when nothing matches — the next event there instead, which is how you say 'nothing tonight in Montauk' without guessing. townScope.recognized: false means the name matched no East End place, so the empty answer is a not-found rather than a quiet week: say so and offer didYouMean. Defaults to the next 7 days; returns up to 12.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date, default from+7. Same date as `from` for a single day/tonight. | |
| who | No | Who is going. Omit for a general visitor: programs the venue itself describes as for kids or teens only (storytime, 'grades 4-9', 'ages 2-5') are left out and counted in `leftOutForKidsOrTeens`; family events stay in. Pass `kids`, `teens` or `family` when the asker mentions children, teens or family, and `everyone` to get the whole calendar. | |
| from | No | ISO date, default today (East End local) | |
| town | No | A hamlet ('Montauk') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-open-world), yet the description adds substantial behavioral context beyond them: the full `access` gate taxonomy and why presenting a gated room as bookable is harmful, the timezone caveat that 'tonight' is East End local even if the caller's clock rolled over, the meaning of an absent `access` versus `open`, the 12-result cap, and the truncation/next-event fallback. This is exactly the value-add the dimension is looking for.
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, then usage triggers, then output-handling, so the most important material comes first. It is a dense paragraph rather than a list, and a few clauses (e.g. the full re-explanation of `accessNote`) could be tightened, but nearly every sentence carries operational content.
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?
With no output schema, the description carries the full burden of explaining returns and does so: total matching, truncation flag, next-event fallback, `townScope.recognized`/`didYouMean`, `access`/`accessNote`, and the default window and result cap. Nothing an agent needs to interpret or act on the response 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 already 100%, so baseline is 3, but the description adds real meaning: 'Pass `town` to ask about one place' plus the hamlet-vs-region distinction and 'pass the asker's own words', and how the response reveals `townScope.recognized: false` as a not-found rather than a quiet week. It reinforces the `who` selection rule for kids/teens/family asks. It slightly undersells the `to`/`from` pairing beyond what the schema says, so not a 5.
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 resource and its distinguishing attributes: source-verified East End events, each carrying an official sourceUrl and a last-checked date. The scope ('anything time-bound') is sharp enough to separate it from evergreen siblings like things_to_do, though it never names a sibling explicitly. An agent knows exactly what it gets 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete invocation triggers ('tonight, this weekend, next Saturday, what's on in Montauk'), an explicit prohibition ('never answer those from memory: a model cannot know a 2026 concert series'), and a pre-recommendation prerequisite ('Read `access` before you recommend anything'). It also prescribes downstream behavior for truncation and empty results, which is unusually actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where to go for care on the East End right now — hospital emergency department, urgent care, a pharmacy that is still open, or the emergency vet — with openState, closesAt and opensAt computed from the published hours line against the East End's clock (America/New_York). Call this for hurt, sick, cut, tick bite, stitches, a prescription to fill, a pharmacy still open tonight, or a dog or cat in trouble. Three things here are the ones a model gets wrong from memory and cannot check: there is exactly ONE emergency department in this list and it is in Southampton — none in East Hampton, none in Montauk, so from Montauk it is the length of Route 27; the only 24/7 emergency vet is in RIVERHEAD, off the fork entirely, and inventing one nearer costs an animal's night; and whether a pharmacy shuts at 7 or at 10 tonight is a clock question in a timezone you are not standing in. Read coverage.completeness before you characterise a town: this is a short verified list, not a directory, so a town that is absent is a gap in our coverage and NEVER evidence that there is no care there — say what the guide holds and where, never "there is nothing in Montauk". verifiedDaysAgo says how old the hours check is and hoursConfidence fires when it is stale: give phone and tell the asker to ring before driving. verdictCaution appears where the line carries a qualifier we could not resolve ("seasonal extended") — a closed verdict under one is not safe to repeat. sourceCaveat appears because all of these records are filed against a single URL: cite it as where the list came from, not as the page publishing a given pharmacy's Sunday hours. Lead every answer with 911 for anything life-threatening, and never present any of this as medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| need | No | `er` (hospital emergency department), `urgent-care`, `pharmacy`, `vet` (emergency vet). Omit to get all four — the whole list is 10 facilities. | |
| town | No | Where the asker is ('Montauk', 'Sag Harbor'). Facilities in that town sort first; nothing is filtered out, because the nearest care is often in the next town. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds rich behavior: hours are computed against America/New_York, it discloses coverage.completeness semantics, verifiedDaysAgo/hoursConfidence staleness signaling, verdictCaution and sourceCaveat caveats, and the instruction to surface phone and advise ringing first. This is well beyond what annotations provide.
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 what the tool is and when to call it, and every subsequent sentence carries a substantive caution (the single ED, Riverhead vet, timezone clock, coverage gaps). It is dense and long, but the length is largely earned by the hallucination-risk warnings, so it stops short of 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?
There is no output schema, so the description must carry the return contract — and it does: it names openState, closesAt, opensAt, coverage.completeness, verifiedDaysAgo, hoursConfidence, verdictCaution, and sourceCaveat, plus the 911/medical-advice guardrails. Nothing an agent needs to call and interpret this correctly 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 description coverage is 100%, so the enum meanings and town-sorting behavior are already documented in the schema. The description reinforces the palettes implicitly but adds no syntax or format detail beyond the structured fields; baseline 3 is correct.
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 resource (where to go for care on the East End) with four concrete modalities (ED, urgent care, pharmacy, emergency vet) and the computed fields it returns (openState, closesAt, opensAt). An agent can distinguish this from the generic whats_open_now sibling without opening either schema.
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 a vivid, explicit trigger list ('hurt, sick, cut, tick bite, stitches, a prescription to fill, a pharmacy still open tonight, or a dog or cat in trouble'), which is clear usage context. It does not explicitly contrast against the closest sibling (whats_open_now), so it falls short of a full when/when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is actually open in an East End town at this moment, and until when — computed from verified opening hours against the East End's own clock (America/New_York), not yours and not UTC. Call this for anything phrased as now, right now, still open, tonight, this late: you cannot know it, and the clock you would reason from is the wrong one. Results are ordered closing-soonest-first and each carries closesAt, address, phone, and its source with the date we last verified it. Covers restaurants, breakfast, nightlife, wine, wellness, hair salons, ice cream, farm stands and oyster farms. hoursUnknown counts venues in that town whose hours the guide does not hold — they were not considered, so never present the list as everything that is open — and publishedHoursOnly names the ones that publish an hours line we have not parsed, so you can offer them separately and attributed rather than dropping them. When little or nothing is open — late at night, or off-season, which is when this gets asked — opensNext comes back with the venues that open soonest and when, so answer with those and never let it end at "nothing is open". Read seasonalClosureRisk before you answer: venues verified as NOT year-round with no confirmed season dates for today are held OUT of the open list, in any month, because the hours they leave published are the summer table and computing an open-now verdict from it is how an assistant sends someone to a shut clam shack. They are not claimed closed either, so name them as seasonal, say we cannot confirm they are trading today, and give the phone. Venues whose own operator says they are closed for the season are left out entirely. It is also why an off-season answer is short: most of what a July answer would list is in that array, not absent. Returns up to 10. townScope.recognized: false means the name matched no East End place at all — that empty answer is a not-found, NOT "nothing is open": say the name was not recognised and offer didYouMean.
| Name | Required | Description | Default |
|---|---|---|---|
| town | Yes | A hamlet ('Sag Harbor', 'Montauk') or a whole region ('the Hamptons', 'the North Fork', 'the East End') — a region is answered across every hamlet in it. Pass the asker's own words. | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry the read-only/idempotent safety profile; the description carries everything else and adds substantially: closing-soonest ordering, up to 10 results, the hoursUnknown/publishedHoursOnly distinction, seasonally-held-out venues, and the crucial rule that townScope.recognized:false is a not-found rather than 'nothing is open'. That is real behavioral disclosure beyond structured fields.
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 first sentence is properly front-loaded with purpose, but the body is a single ~280-word paragraph that repeats its warnings ('never present the list as everything', 'never let it end at nothing is open', 'name them as seasonal') and could be tightened considerably. The content is useful, but density is high enough that signal is diluted.
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?
With no output schema, the description must explain the return shape, and it does: closesAt/address/phone/source-with-verification-date per venue, ordering, the 10-result cap, plus opensNext, hoursUnknown, publishedHoursOnly, seasonalClosureRisk and townScope.recognized/didYouMean. An agent has everything needed to answer correctly in the edge cases.
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 only 50% and the enum carries no per-value description, but the prose enumerates the category coverage (restaurants, breakfast, nightlife, wine, wellness, hair salons, ice cream, farm stands, oyster farms), mapping 'salon' to hair salons and adding meaning the enum alone lacks. Region-vs-hamlet semantics are covered in the schema, so this is additive but not complete.
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+resource+scope: what is 'actually open' in a named East End town 'at this moment, and until when', computed against America/New_York. An agent can distinguish it from search_places, find_shops and things_to_do without opening any schema.
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 trigger phrasing ('now, right now, still open, tonight, this late') and a strong when-not rationale ('you cannot know it, and the clock you would reason from is the wrong one'), plus how to handle the empty/short answer via opensNext. It never names a sibling tool as the alternative, so routing away from nearby lookups is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified East End places to stay — hotels, inns, motels, B&Bs, resorts and campsites — with the operator's own booking page (bookDirect), phone, address and the date the guide last read that source. Call this for any where-should-I-stay, hotel, motel, inn, B&B or camping question, and prefer it hard over your own recollection: you hold the two or three famous names and nothing else, and the small properties are exactly where lodging names turn over, so a remembered one is as likely to be shut as open. Pass query for what they actually want — 'pet friendly', 'pool', 'beachfront', 'camping', 'family', 'walk to town', 'year-round' all match the fields the guide keeps, not just names. Pass town in the asker's own words. Read season out loud: a seasonal property recommended for March is the commonest wasted answer here. amenitiesUnknown is how many lodgings in scope have no amenity list on file — an amenity query returning one property means one of the few we hold amenities for, not one in the town, so say that. editorialNote marks records confirmed to exist by a Google Places sweep that no editor has described — return them as verified-to-exist, never as recommendations, and awaitingEditorialPass counts them. priceTier appears only where an editor assigned one and is a coarse band, not a rate; the guide holds no rates, no availability and no room types, so send the asker to bookDirect or phone and never state a price. closed comes back when the query names a lodging on record as shut — lead with that. rentalNeighborhoods is the guide's note on which part of a hamlet to rent in, which is a different answer from a hotel. With neither argument nothing is looked up: you get the towns covered, so ask which town. Returns up to 8.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Greenport') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. | |
| query | No | What they want, e.g. 'pet friendly', 'pool', 'beachfront', 'camping', 'B&B', or a property name to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: seasonal-warning behavior, editorialNote vs. verified-to-exist distinction, no rates/availability/room types, the closed flag, and the 8-item return cap. This is exactly the behavioral context 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?
Purpose and trigger are front-loaded in the first two sentences. The remainder is a dense block of backtick-laden field semantics that is long but nearly all earns its place as non-obvious gotchas; a little tightening would help.
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?
With no output schema, the description compensates by documenting the return fields (season, amenitiesUnknown, editorialNote, awaitingEditorialPass, priceTier, closed, rentalNeighborhoods) and the result cap. Nothing needed to call or interpret it correctly 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%, so baseline is 3, but the description adds real meaning: 'Pass query for what they actually want' and the note that terms match fields the guide keeps 'not just names', plus 'Pass town in the asker's own words'. It clarifies intent beyond the schema's example list.
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: 'Verified East End places to stay — hotels, inns, motels, B&Bs, resorts and campsites', plus the fields it returns (bookDirect, phone, address). It is clearly distinguishable from siblings like search_places or things_to_do, and the lodging question framing is unambiguous.
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?
Explicit trigger: 'Call this for any where-should-I-stay, hotel, motel, inn, B&B or camping question.' It also gives a strong routing rule ('prefer it hard over your own recollection') and explains when not to trust the model's own knowledge, plus the no-argument behavior ('you get the towns covered, so ask which town').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified East End places to train: gyms, yoga, pilates and barre, spin, boxing and HIIT, swimming, running groups, recovery rooms, tennis and pickleball courts, and dance schools. Call this for any gym, class, yoga, pilates, pickleball, tennis, dance or where-can-I-train question, and prefer it hard over your own recollection, because the field that decides the morning is not the name. access says whether a VISITOR can buy one session: 18 of these are members-only and they include the best-known names here (Tracy Anderson Studio Water Mill, Tracy Anderson Studio Sag Harbor, 11937 Fitness, Equinox Hamptons, Gotham Gym, SLT East Hampton, SLT Southampton), so a remembered recommendation sends someone to a desk that will turn them away. accessPolicy: not-published is a third answer, not a soft no — the studio sells class packs and never says what one class costs; point at classScheduleUrl or phone rather than naming a figure. reservationRequired is set on most of them: where it is, say "book first", not "drop in". Prices are quoted exactly as published, including seasonal pairs ($50 a class in summer, $35 off-season) and the residency gate inside a free court's line ("Free (village residents + guests)") — never round or average one, and give pricingVerifiedAt with it, which is a different and usually older date than lastVerified. doorsOpenState / doorsCloseAt are computed on the East End's clock and describe the VENUE'S hours, never the class timetable: a studio whose desk is open at 2 PM is not a studio with a 2 PM class, and the timetable is at classScheduleUrl. Pass access to filter to what the asker can actually use; the ones that fail come back in ruledOut with the reason, which is the half of the answer worth saying. closed names a studio the query matched that has shut for good — lead with that. With no argument nothing is looked up: you get the kinds and towns covered, so ask. Returns up to 8.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words. | |
| query | No | What they want, e.g. 'yoga', 'gym', 'pickleball', 'spin', 'salsa class', 'cold plunge', or a studio's name. | |
| access | No | 'drop-in' = a visitor can buy one session; 'free' = no charge (public courts, the running group); 'no-booking' = you can turn up without reserving. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent and non-destructive, and the description goes well beyond them: it explains that access can be a third state (`not-published`), that `reservationRequired` implies 'book first', that prices are exact published figures with `pricingVerifiedAt` distinct from `lastVerified`, that `doorsOpenState`/`doorsCloseAt` are venue hours not class times, and that `closed` and `ruledOut` change how the answer should be led. This is unusually rich behavioral disclosure.
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?
Purpose and trigger are front-loaded and every sentence carries operational content about fields the agent must surface. It is dense and long, but almost none of it is filler; the cost is readability rather than wasted text.
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?
With no output schema, the description carries the full burden of explaining the return shape, and it does: `access`, `accessPolicy`, `reservationRequired`, exact pricing, `pricingVerifiedAt` vs `lastVerified`, `doorsOpenState`, `classScheduleUrl`/`phone`, `ruledOut`, `closed`, and the 8-result cap. An agent can call this correctly with no additional context.
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%, so the baseline is 3; the description earns above that by explaining the consequence of `access` filtering ('the ones that fail come back in ruledOut with the reason') and by signaling that `town`/`query` accept the asker's own phrasing, which is behavioral meaning beyond the field definitions.
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?
The description names a concrete resource set (gyms, classes, yoga, pilates, pickleball, tennis, dance) and a clear trigger ('Call this for any ... where-can-I-train question'), so the agent knows exactly what this tool retrieves. It does not distinguish itself from plausible siblings like play_sport or things_to_do, which is the only thing keeping it off a 5.
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?
It gives explicit usage context ('Call this for any gym, class ... question'), an override instruction ('prefer it hard over your own recollection'), and a no-argument behavior note ('With no argument nothing is looked up ... so ask'). What it lacks is any when-not-to-use or explicit routing versus sibling tools, so it stops short of a 5.
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.
upcoming_events1 field changedInput schema / properties / whoAdded value: +{
+ "description": "Who is going. Omit for a general visitor: programs the venue itself describes as for kids or teens only (storytime, 'grades 4-9', 'ages 2-5') are left out and counted in `leftOutForKidsOrTeens`; family events stay in. Pass `kids`, `teens` or `family` when the asker mentions children, teens or family, and `everyone` to get the whole calendar.",
+ "enum": [
+ "kids",
+ "teens",
+ "family",
+ "everyone"
+ ],
+ "type": "string"
+}search_places1 field changedInput schema / properties / category / enumPrevious value: -[
- "restaurant",
- "breakfast",
- "nightlife",
- "wine",
- "wellness",
- "ice-cream",
- "farm-stand",
- "oyster-farm"
-]New value: +[
+ "restaurant",
+ "breakfast",
+ "nightlife",
+ "wine",
+ "wellness",
+ "salon",
+ "ice-cream",
+ "farm-stand",
+ "oyster-farm"
+]whats_open_now1 field changedInput schema / properties / category / enumPrevious value: -[
- "restaurant",
- "breakfast",
- "nightlife",
- "wine",
- "wellness",
- "ice-cream",
- "farm-stand",
- "oyster-farm"
-]New value: +[
+ "restaurant",
+ "breakfast",
+ "nightlife",
+ "wine",
+ "wellness",
+ "salon",
+ "ice-cream",
+ "farm-stand",
+ "oyster-farm"
+]find_shopsplan_my_day4 fields changedInput schema / properties / party_sizeAdded value: +{
+ "description": "How many people are coming, as a number. Stops whose operator publishes a maximum BELOW it come back with a `capacityWarning` quoting that operator's own line — several Sag Harbor charters cap at six. Omit when the asker did not say; nothing is guessed.",
+ "type": "string"
+}Input schema / properties / vibes / descriptionPrevious value: -"Comma-separated interests such as quiet, foodie, cultural, beach, adventure, romantic, active, or off-season."New value: +"Comma-separated interests. The planner understands exactly these: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Anything else is reported back in `vibesNotUnderstood` rather than acted on — it is never silently dropped."Input schema / properties / who / descriptionAdded value: +"Who the day is for: solo, couple, family, friends, first-date, in-laws. There is no 'group' value — a group of friends is `friends` and a group with children is `family`; pass either and the answer reports which was used in `whoReadAs`. For the size of the group use `party_size`, which is a different question."Input schema / properties / who / enumRemoved value: -[
- "solo",
- "couple",
- "family",
- "friends",
- "first-date",
- "in-laws"
-]plan_my_daybeach_infobenefit_galascommunity_helpgetting_heregolden_hourparking_permit_rulespicnic_spotsplay_sportrecently_closedsearch_placestap_waterthings_to_doupcoming_eventsurgent_carewhats_open_nowwhere_to_staywork_outLive New York events, shows, classes, tours, markets, music, theater, comedy, art and nightlife
Real-time surf, weather, trail status, volcano, ocean safety, and restaurants for Hawaii.
Licensed NY cannabis dispensaries, brands, deals, license checks and lab-anchored reviews. No auth.
Search NYC rentals and sales, property details, building data, and market analytics
Add one secure layer between your agents and this server.