Places, opening hours, events, beaches, parking permits and closures across the Hamptons and North Fork, from hamptonsverified.com. 19 read-only tools. No account or key needed.
Scored across 19 tools
Each tool maps to a distinct content vertical (beaches, parking permits, events, shops, dining, lodging, sports, fitness, water, care, transport), and descriptions explicitly fence overlaps off ("the data covers parking only: no dog rules, lifeguard hours or car-free access"). A few pairs remain genuinely confusable: things_to_do vs play_sport (surfing, hiking, tennis), search_places vs whats_open_now vs find_shops, and benefit_galas vs upcoming_events.
All 19 names are lower snake_case and topic-titled, so the surface reads predictably. The only deviation is verb-first vs noun-phrase style — find_shops, search_places, play_sport, work_out, plan_my_day, getting_here against beach_info, picnic_spots, urgent_care, tap_water — which is readable but not a single uniform convention.
19 tools is at the high end, but the server covers an entire regional guide (South and North Fork) where each vertical — beaches, permits, events, dining, lodging, fitness, water safety, urgent care — genuinely needs its own retrieval surface. Slightly over the ideal band but nearly every tool earns its place.
Coverage is unusually thorough for a read-only editorial guide: discovery search, per-venue detail, open-now state, closures, transport, safety, and a planning tool that composes the rest. Minor gaps remain — no weather or tide data (explicitly absent from golden_hour), and cross-vertical needs like reservations or saved-account features are out of scope by design.
One named beach, or every verified beach in a town, village or hamlet ('Amagansett, NY' and 'Sag Harbour' resolve, and readAs reports which place was answered for). 49 beaches on both forks, each with: whether dogs are allowed today (the rule is per month and splits morning from daytime; most South Fork ocean beaches are off-leash at dawn and closed to dogs in daylight from May to September), the parking permit the lot needs, whether it is reachable without a car, lifeguard hours, rip-current notes, the governing town, village or state source, and the date it was last read. Permit information here is the line for each named beach only; it does not include non-resident day passes or the permit map by jurisdiction. Returns up to 5. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantially more: a fixed corpus of 49 beaches, a hard 'returns up to 5' cap, data freshness via a last-read date, and explicit failure behavior (`townScope.recognized: false` yields empty rows plus `didYouMean`). It also discloses that the dog rule is month-based and split morning/daytime, so an agent knows the answer is date-sensitive rather than static.
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 scope are front-loaded and every clause carries information — return cap, field list, permit boundary, failure mode. It is a single dense paragraph, though, and the parenthetical detail about South Fork off-leash dawn rules is more color than routing signal; splitting the return-contract sentences out would improve scanability.
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 enumerates the returned attributes, states the 5-row cap, and explains the `readAs`/`townScope`/`didYouMean` envelopes including the empty-rows case. For a one-parameter lookup over a bounded dataset, nothing an agent needs in order to call it or interpret 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 100% and the single parameter is already documented, so the baseline would be 3. The description earns more by explaining resolution semantics the schema does not: 'Amagansett, NY' and 'Sag Harbour' both resolve, `readAs` reports which place was answered, and near-miss names produce `didYouMean` — meaning an agent learns the argument is fuzzy-matched place text, not an exact key.
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 opening sentence names a specific resource and scope: one named beach, or every verified beach in a town/village/hamlet, and it lists the concrete fields returned (dog rule today, parking permit, car-free access, lifeguard hours, rip currents, governing source, last-read date). It also bounds the permit scope ('the line for each named beach only; it does not include non-resident day passes or the permit map by jurisdiction'), which separates it from the parking_permit_rules sibling without needing to open 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?
The description makes the selection condition explicit — pass a beach name, or a town/hamlet/village to get all verified beaches there — and states a clear exclusion for permit data that lives elsewhere (day passes, permit map by jurisdiction). It stops short of naming the sibling tool to use instead, so the routing is implied rather than spelled out.
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 2026 benefit season: 15 dated charity galas, each joined to the nonprofit it raises for. dressCode is the organiser's own: it is 'Cocktail' on 9 of the 15 and 'Black Tie' on 1; the codes on file are Black Tie, Casual, Cocktail, Garden Casual, Hamptons Chic, Rodeo Glam. tickets.publishedRate is per record: false on 14 of the 15, a verified finding that the organiser hands off to a ticketing platform and prints no rate; true on 1, where tickets.published carries the organiser's own figure with the URL an editor read it from and the date, as the entry rate ('from') of a ladder. tickets.tier is a relative band across these events, not a figure. tickets.publishedTiers, where present, is a published line an editor read, including lines that say no price is published and give a phone number. beneficiary carries the charity's mission, phone, donateUrl and volunteerUrl, verified more recently than the ticket link. alsoThisSeason holds marquee fixtures with no dated gala record (the Hampton Classic, Authors Night, the art fair). Past benefits appear only when from is an earlier date. Returns up to 10. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| 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'), in the asker's own words. | |
| cause | No | Filter to one cause, when the question is plainly about one. | |
| query | No | What to look for, 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?
Annotations already declare readOnly/idempotent/closed-world, yet the description still adds substantial behavioral context: results cap at 10, `townScope` reports how the place argument was read, unrecognized towns yield an empty rows array plus `didYouMean`, and ticket-rate fields carry provenance about who published them. The `publishedRate` false/true semantics and the warning that `tickets.tier` is a relative band rather than a figure are exactly the kind of disclosure an agent needs to avoid misreading 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?
The resource and scope are front-loaded, and nearly every clause carries a distinct fact about a returned field rather than restating the name. It is dense and run-on in places, packing many field-level claims into one paragraph, but little is genuinely redundant given there is no output schema to carry them.
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 and five optional filters, the description does the heavy lifting: it describes the returned record's structure (`tickets.published`, `publishedTiers`, `beneficiary` with donateUrl/volunteerUrl, `alsoThisSeason`), the 10-row cap, and the empty-result path. An agent could call this correctly and interpret the response without further documentation.
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, but the description adds real meaning beyond the schema: it explains how the `town` argument is interpreted (via `townScope`, with near-match fallback) and that `from` reaching into the past is the only way to surface held benefits. It doesn't add syntax detail for `query` or `cause` beyond what the schema already says, which keeps it from 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?
The description names a specific resource and scope: 'The East End's 2026 benefit season: 15 dated charity galas, each joined to the nonprofit it raises for.' That is concrete enough to separate it from generic siblings like upcoming_events or things_to_do, and the closing note about past benefits makes the temporal boundary explicit.
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?
Usage is implied rather than stated up front: past events appear only when `from` is an earlier date and `townScope.recognized: false` explains empty results. But the description never plainly says when to pick this over upcoming_events or things_to_do, nor does it state the intent ('charity galas' vs general events) as a selection rule; the when-to-use conditions live mostly in the schema text.
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 leagues. Every record carries phone, source, sourceUrl, lastVerified, and the guide's own text in both languages (description.es / description.en). Two fields are computed rather than stored: nextSpanishMass / nextEnglishMass, the next service from now on the East End's clock (America/New_York), and inSeasonNow on the soccer leagues for this month. offEastEnd: true marks a referral to Bay Shore, Hempstead or Central Islip. A record states that a service is free, confidential or safe regarding immigration status only where the provider's own published words state it, and those words are quoted. query takes either language; need is a shortcut vocabulary. With no argument nothing is looked up and the answer lists the needs and towns covered. Returns up to 8. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| 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'), in the asker's own words. | |
| query | No | The need, in the asker's 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 safety (readOnly, idempotent, non-destructive, closed-world), and the description still adds substantial behavior: computed fields (nextSpanishMass/nextEnglishMass on America/New_York clock, inSeasonNow), the offEastEnd referral flag, an editorial policy of quoting provider language rather than asserting safety, a cap of 8 results, and the townScope.recognized:false → empty rows + didYouMean path.
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 directory contains, then record shape, then computed fields, then query mechanics, then the empty-result path — a sensible order. It is a single dense paragraph, though, and the field-policy and townScope material would scan better as separate sentences or fragments.
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?
All three optional parameters are accounted for, no-argument behavior is defined, the 8-row cap is stated, and the failure mode of an unrecognized town is fully described. With no output schema present, the description carries the record shape (`phone`, `source`, `lastVerified`, bilingual `description`) and does so adequately.
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, but the description adds meaning the schema doesn't: 'query' accepts either language and free-form phrasing, 'need' is a shortcut vocabulary rather than a filter, and the town argument is fuzzy-matched with recognition feedback and near-match suggestions when it fails. That last point materially changes how an agent should supply and recover from the town parameter.
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 (the guide's bilingual community directory of free and low-cost services) and enumerates the domains it covers — legal aid, food, shelter, classes, worship, soccer. An agent can tell instantly this is the social-services directory call, distinct from siblings like search_places or urgent_care.
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 clear operating context: 'query' for a free-form need in either language, 'need' as a shortcut vocabulary, 'town' for a hamlet or region, and explicit no-argument behavior (lists needs and towns covered). It stops short of naming when to prefer a sibling tool such as urgent_care for a medical question, so no exclusion guidance is present.
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: 86 stores across 15 hamlets on the South Fork, North Fork and Shelter Island, in these categories: fashion, jewelry, swimwear, activewear, kids, toys, home, books, beauty, consignment, accessories, general-store, florist, antiques. Each row carries the address read off the brand's own store page at sourceUrl, a cross-checked coordinate with coordSource recording what corroborated it, phone where one is published, and the one-line what the guide keeps. The guide holds no opening hours for any shop, so no row carries an open/closed state or an hours line. query matches the name, the brand, the category and what, so 'bookshop', 'toys', 'flowers' and 'The Wharf Shop' all resolve. With no arguments nothing is looked up and the answer lists the categories and towns covered. Returns up to 8. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Sag Harbor', 'East Hampton') or a region ('the Hamptons', 'North Fork'), in the asker's own words. | |
| query | No | What to look for, 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 already declare read-only, idempotent, non-destructive, closed-world. The description adds genuinely non-derivable traits: no opening hours exist so no open/closed state is returned, results are capped at 8, unrecognized towns yield an empty rows array plus didYouMean, and townScope explains how the place argument was interpreted.
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 scope and coverage, then provenance, then lookup semantics, then return-shape and edge-case behavior. Dense but nearly every clause carries information; the one weak spot is that the block is a single run-on paragraph rather than segmented.
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 cover return values and does: row fields (sourceUrl, coordSource, phone, what), the 8-row cap, townScope, rows array and didYouMean. It does not describe the full response envelope or ordering of rows, but an agent has enough to call and interpret results 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 compensates well for the undocumented parts: it specifies that query matches name, brand, category and the `what` field, and that town accepts hamlets or regions in the asker's own words with townScope reporting the interpretation. The category enum is not re-explained beyond the schema, keeping it from 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?
States a specific verb and resource — verified East End shops (86 stores across 15 hamlets) — plus the exact categories and the fields each row carries. An agent can immediately tell this is a curated shop directory rather than a general place lookup like search_places or a lodging tool.
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?
Explains the query semantics ('bookshop', 'toys', 'flowers', 'The Wharf Shop' all resolve) and defines the no-argument behavior as a coverage summary, which tells the agent when a bare call is appropriate. It does not explicitly name alternatives or exclusions (e.g., when to prefer search_places), 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.
How to reach the East End and move around it: Hampton Jitney, the LIRR Cannonball and off-peak Montauk Branch, Blade, seaplanes, the three ferries, cycling, ride-hail, and driving, each with the operator's published fare, season and stop list and the date the guide last read it. Fares are as published, including the prepaid versus on-board Jitney difference and Cross Sound's fuel surcharge. roadConditionsNow reports whether this instant falls inside one of the published NY-27 crawl windows, computed against the East End's clock (America/New_York), with the next window's start time and all three published windows with their days and hours; it is the published pattern, not a live incident feed. With to, the answer also reports which Jitney stops serve that destination and the drive-time row for that run, with typical and summer minutes. Every figure carries its source; where sourceCaveat appears, the record is filed against a link that does not publish the figure and the figure is the guide's own. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | The destination, a hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words. Omit for the whole picture. | |
| mode | No | 'car-free' drops driving; 'driving' returns road answers only. Omit for every option. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, idempotent, non-destructive annotations, the description discloses important behavioral traits: road results are a published pattern, not a live incident feed, and are computed against America/New_York; every figure carries a source; `sourceCaveat` marks figures not published at the linked source; and `townScope.recognized: false` explains an empty rows array plus possible `didYouMean` matches.
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 core purpose is front-loaded, but the description is a dense, run-on paragraph that packs fares, surcharges, timezone logic, source caveats, and place-resolution edge cases together. Much of the detail is useful, but the structure makes it harder to scan than a shorter or segmented definition would 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 the burden of explaining return concepts and does so thoroughly: it names the fare and schedule fields, describes `roadConditionsNow`, explains `sourceCaveat`, and specifies the `townScope` failure behavior. For a complex read-only guide with only two optional parameters, this is sufficient context to call and interpret the tool.
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, but the description adds real meaning about how `to` affects the result: it reports which Jitney stops serve that destination and the relevant drive-time row with typical and summer minutes. It also explains how the place argument is interpreted via `townScope`, though `mode` itself is mostly left 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?
The description clearly states a specific resource and activity: reaching the East End and moving around by named transport modes, with fares and road-window answers. It is distinct from siblings such as parking_permit_rules or where_to_stay, but it does not explicitly compare itself to any sibling, so it falls short of 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?
Usage is implied for trip-planning and local transport questions, and the description explains that omitting `to` gives the whole picture while supplying `to` enriches results with Jitney stops and drive times. However, it gives no explicit when-not-to-use guidance or named alternatives among the many sibling tools.
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, 31 in all: public overlooks, beaches, vineyard lawns, hotel terraces and bars, each with the time. time is computed from that spot's own latitude and longitude for the 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. Each row also carries goldenHour (the hour into sunset, or out of sunrise), blueHour, arriveBy (30 minutes earlier, when the lot fills), parking and walkDistance. startsIn counts down when it has not happened yet today; alreadyPassedToday is set when it has. when: 'sunrise' gives the morning side; the default is sunset. date (YYYY-MM-DD) computes for another day, and inBestMonth says whether that date falls in the months the record names. wrongWayRound lists verified spots in the same towns that face the other way (Ditch Plains is east-facing). The data holds no weather. Returns up to 8. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| 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'), in the asker's own words. | |
| when | No | 'sunset' (default) or 'sunrise'. | |
| query | No | What to look for, 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 establish the safe read-only profile, and the description adds substantial behavioral context: computed local times, return limit of 8, no weather data, empty rows on unrecognized towns, and `didYouMean` fallback behavior. It also explains edge cases like `startsIn`, `alreadyPassedToday`, and `wrongWayRound`.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the purpose and packs necessary output-field details into a single dense paragraph. Most of the detail earns its place because there is no output schema, though ancillary facts like the three-hour seasonal swing and two-minute geographic difference are interesting rather than essential.
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?
Given the absence of an output schema, the description does a thorough job explaining return count, key output fields, timezone behavior, and failure modes such as unmatched towns. It gives an agent enough context to call and interpret the tool 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 the schema already documents all four parameters. The description adds meaningful interpretation for `town` by explaining `townScope.recognized` and `didYouMean`, and supplies context for `date` and `when`, though it mostly repeats the schema's parameter definitions and adds little for `query` beyond examples.
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 clearly identifies the resource and scope: verified East End sunrise and sunset viewpoints, with computed times and supporting fields. It is easy to tell this is a dedicated golden-hour lookup rather than generic place search, but it does not name a sibling tool or use an explicit verb like 'find' or 'list'.
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?
Usage is implied through parameter explanations such as `when: 'sunrise'` for the morning side and `date` for another day. However, there is no explicit guidance on when to choose this tool over siblings like `things_to_do`, `search_places`, or `beach_info`.
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 in where. For a beach name ('Main Beach', 'Ditch Plains') the answer is the verdict for that lot: which permits grant parking, which stickers explicitly do not (an East Hampton Town sticker does not open Main Beach, which is in East Hampton Village), the non-resident and day-pass options with prices, the fine, and where to apply. Each carries enforcement.enforcedRightNow, computed from the published season and daily window against the East End's clock (America/New_York), with the season and the daily hours it was computed from. For a town or hamlet the answer is that jurisdiction plus its beaches' permit lines; with where omitted, the whole map. 16 beaches are state, county or DEC land where no town permit applies; they come back flagged outsideTheStickerMap. The data covers parking only: no dog rules, lifeguard hours or car-free access. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| 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?
Beyond the read-only, idempotent annotations, the description discloses computed enforcement status using the published season and daily window against America/New_York, plus the season and hours used. It also explains that state, county, and DEC beaches are returned flagged `outsideTheStickerMap`, and that `townScope.recognized: false` yields empty rows and possible `didYouMean` suggestions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded, starting with the resource and map scope before covering beach lookups, town lookups, enforcement, exclusions, and unrecognized-place behavior. Every sentence carries operational information, and the length is appropriate for a domain with no output schema.
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 burden of explaining return behavior, and it does so thoroughly: permit verdicts, non-resident and day-pass options, fines, application locations, computed enforcement, season and hours, outlier flags, and recognition errors. An agent has enough context to call it correctly and understand the shape of the answer.
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?
The schema already fully describes `where`, so the baseline would be 3. The description adds meaning about how the argument is interpreted via `townScope`, what happens when no East End place matches, and how omissions behave, but the core accepted values are largely already present in 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?
The description states a specific resource and scope: the East End beach-parking permit map across seven jurisdictions, resolved against a beach or town in `where`. It clearly distinguishes itself from the broad local-information siblings by explaining that it returns permit, sticker, day-pass, fine, application, and enforcement verdicts for parking.
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 clear usage conditions: use a beach name for a lot-specific verdict, a town or hamlet for the jurisdiction plus its beaches, or omit `where` for the whole map. It also states the tool covers parking only and not dog rules, lifeguard hours, or car-free access, which is useful exclusion guidance, though it does not explicitly name alternative sibling tools.
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, 25 in all: public parks, state and county parks, preserves, beach-grass strips, winery lawns and historic gardens, each with the rules set by whoever owns the ground (New York State, Suffolk County, a town, a village, a winery). alcohol is a sentence per spot, not a boolean: wine-only is a winery lawn where only the estate's wine is permitted, and allowed-with-permit means a permit from permitUrl is required first. 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). Where only hoursText comes back the published line was not machine-readable and is given as published. allows filters to spots that permit it. The guide holds no drinking rule for the ocean beaches, so none is returned for them. Returns up to 8. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words. | |
| query | No | What to look for, 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?
Beyond the annotations, the description discloses many behavioral traits: alcohol is a sentence not a boolean, wine-only and allowed-with-permit have specific meanings, glassBottles prohibitions hold even where alcohol is allowed, closesAt is computed from coordinates for today, hoursText is used when sunrise/sunset text is not machine-readable, results cap at 8, and townScope.recognized false empties rows and returns didYouMean. These are substantial additions beyond the read-only/idempotent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loads the core purpose and scope, then layers in nuanced field semantics. Most sentences carry useful information, though the length and number of details make it heavier than typical tool descriptions.
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 behavior—and it does: result limit, how closesAt and hoursText are resolved, townScope reporting, empty rows with didYouMean, and the omission of drinking rules for ocean beaches. This is complete enough for an agent to call and interpret results 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 the schema already documents town, query and allows. The description reinforces how the town argument is read and clarifies that allows filtering includes wine-only and permit-only alcohol spots, but most of that is already stated in the schema's allows description. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly identifies the resource: verified East End picnic grounds, 25 in all, including public parks, preserves, beaches, winery lawns and historic gardens. It specifies the key attributes (alcohol, glass bottles, grills, dogs, hours) but does not explicitly contrast itself with sibling tools like beach_info 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?
Usage is implied through the filter parameter and the explanation of townScope and the ocean-beach exclusion, but there is no explicit when-to-use or when-not-to-use guidance versus alternatives. An agent can infer this is for picnic-rule lookup, yet the description never names a sibling tool or a decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Three distinct, ordered East End day plans built by Hamptons Verified's deterministic planner, the same rules engine as the website. Each plan is a time-ordered list of stops with time, block, name, town, reason, source, the guide's own listing url, and a mapsUrl directions link. Before a plan is returned the planner applies permanent closures, the selected date's opening hours, age fit, budget, weather, daylight, geographic sequencing and the maximum drive between consecutive stops. A stop that is a dated event carries an event object: its time is the organiser's published start, with access, accessNote, ticketing, source, sourceUrl and lastVerified. eventsOnThisDateNotInThePlan lists events the guide holds for that date and scope that were not used, each with whyNotInThePlan. saved_places is a preference lane: names supplied by the asker are worked in where eligible and never override a closure, hours, travel or safety rule; the tool has no access to any account, browser or saved list. The answer reports vibesUnderstood, vibesNotUnderstood, whoReadAs and partySize, and a stop whose operator publishes a maximum party size below party_size carries a capacityWarning quoting the operator's line. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| 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`, a group with children is `family`, and common aliases are resolved to the nearest value, which the answer reports in `whoReadAs`. Group size is `party_size`. | |
| date | No | ISO date (YYYY-MM-DD) in East End local time; defaults to today. | |
| seed | No | Optional stable seed; the same seed and inputs reproduce the same plans. | |
| town | No | A hamlet or region to keep the day around. Omit for the full East End. | |
| vibes | No | Comma-separated interests from: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Values outside this list do not influence the plan and are reported in `vibesNotUnderstood`. | |
| budget | No | ||
| energy | No | ||
| party_size | No | Number of people, as digits. Stops whose operator publishes a maximum below this number carry a `capacityWarning` quoting the operator's line. When omitted, no capacity check is made. | |
| saved_places | No | Comma-separated venue names the asker wants included, used as preferences only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent and non-destructive, but the description adds substantial behavior: the planner applies closures, hours, age, budget, weather, daylight, sequencing and drive limits before returning plans. It also discloses saved_places as preferences only with no account/browser access, and handles event objects, exclusions and unrecognized towns.
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 and most sentences carry field-level or rule-level detail rather than filler. It is dense and one long block, with several output-field lists packed together, so structure could be clearer, but it is not repetitive.
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?
Because there is no output schema, the description appropriately explains plan row fields, event details, excluded events, saved-place handling, reported reading fields, capacity warnings and townScope failure behavior. For a 9-parameter planner this is sufficiently 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 high (78%), so the baseline is 3; the description still adds meaning for saved_places, party_size capacity warnings, townScope recognition and didYouMean behavior. Budget and energy are not elaborated beyond their enums, but the description compensates where it matters.
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 by stating it builds three ordered East End day plans with a deterministic rules engine, so the verb and resource are unambiguous. It does not explicitly name sibling tools or contrast itself with search_places/things_to_do, so it falls short of full sibling differentiation.
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?
Use is implied by planning a day and by the mention of the same rules engine as the website, but there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer that this is the itinerary builder rather than a venue search.
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, 75 verified venues: public and club courts, school fields, golf, beach volleyball, surf breaks, mountain-bike and trail-running routes, the skate park, the disc golf course, sailing, riding stables, and 7 recurring basketball pickup runs. access says who gets on: 12 of these are members-only, including Maidstone Club; Shinnecock Hills Golf Club; Topping Riding Club; The Meadow Club of Southampton, Paddle Tennis; Breakwater Yacht Club, Sailing; Montauk Downs, a state park anyone can book, is in the same list. access: permit means play is free and the parking needs a beach permit (Ditch Plains, Indian Wells, Main Beach). access: not-published means the record shows open play and the guide holds no rate. access is a tag with no figure behind it; the only rates returned are those written into notes, the operator's published figures as an editor read them. notes also records the guide's own doubt where a court or surf claim is unconfirmed local knowledge rather than something the operator publishes. checkedAndNotThere lists sports the guide looked for an operator for and found none: padel, badminton, boxing and ice skating have no verified East End venue, and two announced pickleball courts are unbuilt or unsourced. pickup gives each basketball run's day and time with runsToday, startsAt/endsAt and alreadyOverToday computed on the East End's clock (America/New_York), and flags openCourt for outdoor courts published as daily dawn-to-dusk. The access argument filters to one access kind; rows that fail the filter come back in ruledOut with the reason. With no argument nothing is looked up and the answer lists the sports and towns covered. Returns up to 8. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'East End'), in 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') also resolves. | |
| 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?
Beyond the readOnly/idempotent/closed-world annotations, it discloses concrete behavior: results are capped at 8 rows, filtered-out rows return in ruledOut with a reason, townScope.recognized:false yields an empty rows array plus didYouMean, and pickup times are computed on America/New_York. It also flags data-quality caveats (access is a tag with no figure behind it; notes carries operator rates and editorial doubt).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense block of roughly 2000 characters that leads with a venue inventory and club name-dropping (Maidstone, Shinnecock, Topping) before the essential mechanics. Much of it is editorial color rather than guidance an agent needs to select or invoke the tool, and the front-loading is poor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully inventories the return shape (rows, ruledOut, townScope, didYouMean, pickup fields) and the empty/no-argument behavior, which is substantial for a 3-parameter read tool. The main completeness gap is the unexplained walk-on/free argument values and the access tag versus access argument conflation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema baseline would normally suffice, but the description actively muddies the one filter argument: it explains access values as members-only, permit and not-published, while the schema enum only accepts walk-on and free. That mismatch risks an agent sending an invalid value, and the actual walk-on/free meanings are never restated in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause states the resource and scope clearly: where to play a sport on the East End, with 75 verified venues across courts, fields, greens, surf breaks and routes. It is distinguishable from siblings like work_out or things_to_do, though the sentence reads more like a catalog of the dataset than a crisp 'find a venue by sport/town' statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the description explains that a call with no argument lists the sports and towns covered, and that the access argument filters and pushes rejects into ruledOut. There is no explicit when-to-use-this-versus-a-sibling guidance, and no statement of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified East End venue closures, with dates. With name, the answer is a verdict on that one venue either way, including venues the guide lists as operating. Without name, the answer is the most recently confirmed closures. Each closure is classed as permanently closed, temporarily closed (may reopen), or never-existed (a place a data sweep invented and an audit could not find), and carries the date the guide confirmed it and who reported it. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| 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?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description goes well beyond them. It discloses the classification taxonomy (permanently closed / temporarily closed / never-existed), that each row carries the confirming date and reporter, and the exact failure shape when `townScope.recognized` is false (empty rows plus `didYouMean`).
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 two operating modes are front-loaded before the classification detail, and nearly every clause carries information. It is a dense single block, though, and the taxonomy plus `townScope` explanation could be tightened without losing meaning.
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 takes on the burden of explaining return structure and does so: row classes, dates, reporters, and the unrecognized-place response with `didYouMean`. Nothing an agent needs to interpret the result or call it correctly appears to be 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 `name`, `town`, and `since` are already documented, including the 'omit to list' behavior. The description reinforces the dual-mode meaning of `name` but adds no new syntax or semantics for `town` or `since`, so it sits at the baseline for a fully described 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?
The description states a specific resource (verified East End venue closures) and explicitly splits the tool into two modes: a single-venue verdict when `name` is supplied, and a list of recent confirmed closures otherwise. It even clarifies that the verdict covers venues the guide lists as operating, which separates it from a plain closure feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The when-to-use rule is clear and stated up front: pass `name` for a single-venue verdict, omit it to list recent closures. It does not name alternatives (e.g. whats_open_now or search_places) or state exclusions, so an agent must infer the boundary with those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the guide's verified venues across the Hamptons and North Fork: restaurants, breakfast, nightlife, wine, wellness, hair salons, ice cream, farm stands and oyster farms. The search covers the fields each section keeps, not only venue names: 'pick-your-own' matches the farms that run it, 'sunflowers' the ones that grow them, 'sorbet' the scoop shops that make it. Each match carries address, phone, an open/closed state with closing time computed on the East End's clock (America/New_York), and provenance: source and sourceUrl (what was read), lastVerified (when) and verifiedBy (manual = an editor read it, api = Google Places sweep). Where a venue publishes hours as prose rather than a machine schedule the row carries hoursText, the operator's published line, instead of openState. seasonalCaution appears on every venue verified as not year-round, 76 in all (16 of Montauk's restaurants, 12 of its bars). On those rows openState is computed only on a date inside a season window or a dated trading confirmation the guide holds and is otherwise omitted in every month, because the weekly hours an operator leaves published are the summer table. Where the operator has published a closure, openState reads "closed for the season" and seasonalCaution quotes the operator's words with the date they were read. Permanently closed venues are excluded. Returns up to 8 matches and the total matched. Each venue row also carries mapUrl, a link to the guide's live map centred on that venue (hamptonsverified.com/near-me?focus=…), and the answer carries one top-level mapUrl for the whole list. The map asks for the reader's location on their own device; the link carries no position. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork', 'East End'), in the asker's own words: a 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 already cover safety (readOnly, idempotent, closed-world), yet the description still discloses genuinely non-obvious behavior: a hard cap of 8 matches plus a total, `openState` being omitted outside a season window on seasonal venues, `hoursText` substituting for `openState` when hours are prose, and `mapUrl` prompting for reader location with no position carried in the link. That is exactly the 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?
The first sentence is well front-loaded, but the body is a dense block mixing result-shape, provenance, seasonal logic and map behavior in long compound sentences. Details like '76 in all (16 of Montauk's restaurants, 12 of its bars)' are editorial color that does not help an agent decide or invoke.
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 so: fields per row (address, phone, openState/hoursText, provenance, mapUrl), the top-level mapUrl, the 8-result cap plus total, and the empty-rows/didYouMean failure mode. Nothing an agent needs to interpret a 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 67% (town and query documented, category enum undocumented but self-describing), and the description adds real meaning: the query matches section-specific fields such as pick-your-own, sunflowers and sorbet, not just names, and `townScope`/`didYouMean` explain how a failed place match is reported. Minor cost: it calls `town` 'the place argument', a naming mismatch that slightly obscures which parameter it describes.
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 ('Searches') and a scoped resource ('the guide's verified venues across the Hamptons and North Fork'), then enumerates the nine covered categories that map to the category enum. An agent can tell this apart from siblings like find_shops, things_to_do or whats_open_now without reading 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?
Usage is implied rather than stated: the category list and 'Permanently closed venues are excluded' indirectly route agents toward recently_closed or whats_open_now, but no sibling is named and no when-not condition is given. The description explains internal behavior (season windows, townScope) more than it explains tool selection.
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 (17 hamlets), from the guide's read of the water utility's and the state health department's own reporting. Three of the hamlets covered (Springs, Shelter Island, Southold) are private-well territory where no agency tests the water, and the record says so. Wainscott's record covers PFOS and PFOA found in more than 150 private wells and the December 2018 main extension that put the hamlet on public water. Every safe value refers to public water only; the guide holds no verdict on any private well. verdict is the guide's own paragraph for that hamlet. status comes with statusMeaning. filterRecommendation names a certification rather than a brand, with filterCaveat where the guide's glossary has corrected which NSF/ANSI number covers PFAS. sources are the citable links with the date each was read, including SCWA's June 2025 declaration of compliance with the federal PFOA/PFOS limits 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. utilities names who pipes the water and a phone number, with no URL because the guide's filed links for those records no longer resolve. noVerdictHeld names a place the guide has not written up. place takes a hamlet, a region, or a ZIP. With no argument nothing is looked up and the answer lists the hamlets covered. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | The place: a hamlet ('Montauk', 'Springs', 'Wainscott'), a region ('the Hamptons', 'North Fork'), or a ZIP ('11937'), in the asker's own words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-open-world, but the description adds substantive behavior beyond them: private wells are untested and carry no verdict, `safe` applies to public water only, `noVerdictHeld` flags unwritten places, `townScope.recognized: false` yields an empty rows array plus `didYouMean`, and `utilities` deliberately has no URL because filed links no longer resolve. The known-unknowns and failure-mode disclosure is unusually candid.
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 one undifferentiated block that drifts from dataset provenance into output-field narration, sources, utilities, and error semantics. Since there is no output schema, much of that content does earn its place, yet backtick-delineated field explanations buried mid-paragraph are slower to parse than a short structured layout would 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 and a single optional parameter, the description carries the full explanatory load and does so: it names the return fields (`verdict`, `status`/`statusMeaning`, `filterRecommendation`/`filterCaveat`, `sources`, `utilities`, `noVerdictHeld`, `townScope`) and explains the placeholder/empty-result conditions. An agent has everything it needs to call this correctly and to interpret the reply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single `place` description already lists hamlet/region/ZIP, so the schema does most of the work. The description nonetheless adds meaning the schema lacks: how the argument is interpreted is echoed back in `townScope`, and a miss produces an empty result set rather than an error, which changes how the agent should phrase and retry the call.
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?
Opening clause states a specific question-resource pair: 'Whether the tap water is drinkable, hamlet by hamlet (17 hamlets), from the guide's read of the water utility's and the state health department's own reporting.' Scope (17 hamlets), provenance, and the unit of granularity are all pinned down, and the tool is clearly distinguishable from the generic directory-style siblings.
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 tells the agent what argument forms are accepted (hamlet, region, ZIP) and explicitly covers the zero-argument case: 'With no argument nothing is looked up and the answer lists the hamlets covered.' That is real invocation guidance, though it never names an alternative sibling or states when *not* to reach for this tool.
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 and lessons for kids and adults from Optimist and Laser dinghies to ASA keelboat courses, yacht clubs, jet-ski rental) and wildlife to see (seals, whales, ospreys, sea turtles, sharks). Every result carries inSeasonNow, computed against the East End's calendar month, with the season window; month judges a different month. noCommercialOperator: true is the guide's checked finding that no business on the East End teaches or rents that activity (there is no kitesurfing school at Napeague and no climbing guide at Shadmoor). Where operators exist each carries phone, booking page, published price, source and date. Also returned: the permits an activity requires (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, quoted as published. A sailing school carries sailing (boats, small-boat or big-boat course, kids' ages, adults, certifications, members-only) and sailing.guide, the guide's page listing every school. With neither query nor town nothing is looked up and the answer lists the kinds and towns covered. Returns up to 8. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words. | |
| month | No | Month to judge the season for, e.g. 'October' or 'Oct'. Defaults to today's month on the East End. | |
| query | No | The activity, 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds substantial behavioral context: how `inSeasonNow` is computed, what `noCommercialOperator: true` actually asserts (a checked negative finding, with examples at Napeague and Shadmoor), how `seasonUnknown` is derived from 'Summer-only' listings, that results cap at 8, and exactly what happens when `townScope.recognized` is false (empty rows plus `didYouMean`). None of this is recoverable from the annotations or schema.
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?
Content is front-loaded and nearly every sentence carries information, but it is a single dense paragraph with heavy backtick fragments and a trailing run-on list ('the permits an activity requires, the conditions it needs, minimum-approach rules for wildlife, and skill and age limits') that reads as an afterthought. It is efficient in information density but not in structure or readability.
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 complex, zero-required-parameter tool with no output schema, the description does the heavy lifting well: it documents season semantics, the meaning of empty results, the recognized/recognized-false town path, and the 8-row cap. The remaining gap is what to do when the cap is hit — no pagination or narrowing instruction is given, which matters for a tool that can easily match more than 8 records.
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, but the description adds meaning the schema does not: `month` is framed as judging a different month than the default East End calendar month used by `inSeasonNow`, and `town`/`query` are described via the returned `townScope` interpretation and the fallback-to-capability-list behavior when both are omitted. It stops short of undocumented syntax or matching rules, but the added semantic depth is real.
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 'What there is to do on the East End' and then enumerates the exact resource classes covered: activities, on-water businesses, and wildlife sightings, with concrete examples ('fishing charters, marinas, sailing schools', 'seals, whales, ospreys'). An agent can immediately tell this is a curated East End recreation/operator lookup rather than a generic place search like search_places or a single-sport tool like play_sport.
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?
Usage is implied through behavioral rules rather than explicit routing: 'With neither query nor town nothing is looked up and the answer lists the kinds and towns covered' tells the agent this doubles as a capability overview, and 'month judges a different month' clarifies the default. However, there is no statement of when to prefer this over sibling play_sport or beach_info, and no explicit when-not guidance, leaving overlap with activity-related siblings to inference.
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 in a date window, each with its official sourceUrl and the date the guide last checked it. Dates and times are East End local (America/New_York). Each event carries access, 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, waitlist, or open; accessNote is the organiser's wording; an absent access means the record states nothing. The answer reports the total matching, whether the list was truncated, and, when nothing matches in the window, the next event in scope. Defaults to the next 7 days; returns up to 12. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date, default from+7. The same date as `from` gives a single day. | |
| who | No | Who is going. When omitted, 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. `kids`, `teens` or `family` include those programs; `everyone` returns the whole calendar. | |
| from | No | ISO date, default today (East End local) | |
| town | No | A hamlet ('Montauk') or a region ('the Hamptons', 'North Fork'), in the asker's own words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-open-world and non-destructive, so the safety profile is covered. On top of that the description discloses genuinely non-obvious behavior: the `access` gate vocabulary and what an absent value means, truncation reporting, the empty-window fallback to the next event, and the `townScope.recognized: false` failure mode with `didYouMean`. That is substantive disclosure beyond the annotations, though it never states rate limits or latency.
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 is front-loaded in the first clause and the remainder is dense but load-bearing detail about return shape. It is a single long paragraph with several clauses chained by semicolons, which is efficient but makes the access-gate enumeration harder to scan than a short list would 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?
There is no output schema, so the description carries the full burden of describing the return value, and it does: total matching count, truncation flag, per-row `sourceUrl` and check date, `access`/`accessNote`, `townScope`, and `didYouMean` on empty results. For a 4-parameter, zero-required read tool with annotations already covering safety, nothing an agent needs in order to call it and interpret the answer 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, but the description earns extra credit by explaining how the `town` argument is interpreted (`townScope` reporting, near-match `didYouMean` when the name resolves to no East End place) and the effective result cap of 12, neither of which is in the schema. It does not elaborate on the `who` enum beyond what the schema description already says.
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 opening sentence names a specific resource (East End events) inside a specific scope (a date window) and states the verification property of each row (`sourceUrl` plus last-checked date). That is enough to distinguish it from vague siblings like things_to_do or plan_my_day on substance, but it never explicitly contrasts itself with those calendar-adjacent siblings, so the agent must infer the split.
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?
Usage context is implied rather than stated: the window defaults to the next 7 days, returns up to 12 rows, and falls back to the next in-scope event when nothing matches. There is no explicit when-to-use-this-instead-of guidance (e.g. versus things_to_do or whats_open_now), so the agent gets operational framing but no routing rule.
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, 10 verified facilities: the hospital emergency department, urgent care, pharmacies and the emergency vet, each with openState, closesAt and opensAt computed from the published hours line against the East End's clock (America/New_York), and phone. The list holds one emergency department, in Southampton, and one 24/7 emergency vet, in Riverhead. coverage.completeness describes how complete the list is: it is a short verified list, not a directory, so a town absent from it is a gap in coverage, not evidence that there is no care there. verifiedDaysAgo is the age of the hours check and hoursConfidence flags a stale one. verdictCaution appears where the hours line carries a qualifier the guide could not resolve ("seasonal extended"). sourceCaveat appears because all records are filed against a single source URL. Nothing returned is medical advice. With town, facilities in that town sort first and nothing is filtered out. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| need | No | `er` (hospital emergency department), `urgent-care`, `pharmacy`, `vet` (emergency vet). Omit for all four. | |
| town | No | The asker's town or hamlet ('Montauk', 'Sag Harbor'). Facilities in that town sort first; nothing is filtered out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (read-only, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond that: openState/closesAt/opensAt are computed against America/New_York, verifiedDaysAgo is the age of the hours check, hoursConfidence flags staleness, verdictCaution marks unresolved qualifiers, and sourceCaveat exists because all records share one source URL. It also discloses the closed-world list limit (one ED in Southampton, one 24/7 vet in Riverhead) and that a missing town is a coverage gap, which is exactly the kind of caveat 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?
The purpose is front-loaded and nearly every sentence carries non-redundant information, which matters because there is no output schema to document the return shape. It loses a point for density: long comma-chained sentences pack field-level documentation into a single block, making it slower to scan than necessary.
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 and no annotation detail on return values, the description supplies the full picture: which fields appear, how they are computed, what the caveat fields signal, and how filtering versus sorting behaves. Nothing an agent needs in order to call this correctly and interpret 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 100% and both parameters are already documented, so the baseline would be 3. The description goes further by explaining how `town` is actually read: matching places sort first and nothing is filtered out, and townScope.recognized:false means the rows array is empty with didYouMean near matches — semantics an agent cannot infer from the schema alone.
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 first clause names a concrete task and resource: 'Where to go for care on the East End', then enumerates the four facility types and the count (10 verified facilities). That is enough for an agent to separate it from generic siblings like whats_open_now or find_shops, though no sibling is named explicitly, which keeps it short of 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?
The use case is implied by 'Where to go for care' and the coverage caveat warns that absent towns are a gap rather than proof of no care, which is real guidance on interpretation. However, there is no explicit when-to-use/when-not-to-use routing against siblings such as whats_open_now, and no statement that a true emergency should not be resolved via this tool beyond the 'not medical advice' disclaimer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is open in an East End town at this moment and until when, computed from verified opening hours against the East End's clock (America/New_York). Covers restaurants, breakfast, nightlife, wine, wellness, hair salons, ice cream, farm stands and oyster farms. places is ordered closing-soonest-first; each row carries closesAt, address, phone, source and the date last verified. hoursUnknown counts venues in scope whose hours the guide does not hold; they are not in places. publishedHoursOnly lists venues that publish an hours line the guide has not parsed, with that line. opensNext lists the venues that open soonest and when. seasonalClosureRisk lists venues verified as not year-round with no confirmed season dates for today; they are held out of places in every month because the weekly hours they leave published are the summer table, they are not reported as closed either, and each carries its phone. Venues whose operator has published a seasonal closure are omitted. Returns up to 10. Each venue row also carries mapUrl, a link to the guide's live map centred on that venue (hamptonsverified.com/near-me?focus=…), and the answer carries one top-level mapUrl for the whole list. The map asks for the reader's location on their own device; the link carries no position. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| town | Yes | A hamlet ('Sag Harbor', 'Montauk') or a whole region ('the Hamptons', 'the North Fork', 'the East End'), in the asker's own words; a region is answered across every hamlet in it. | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent, non-destructive and closed-world, so the safety bar is low, yet the description still adds real behavioral context: results are ordered closing-soonest-first, capped at 10, and venues with unparsed or unheld hours are excluded rather than reported as closed. It also discloses that each venue mapUrl triggers a location prompt on the reader's own device and carries no position, which is exactly the kind of side-effect detail annotations cannot express.
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 core capability is front-loaded in the first sentence and the field-level detail is justified because no output schema exists. It is nevertheless dense to the point of sprawl, particularly the seasonalClosureRisk sentence, which restates exclusion from `places` twice and could be tightened without losing meaning.
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 carry the entire return contract, and it does: it names every response bucket (places, hoursUnknown, publishedHoursOnly, opensNext, seasonalClosureRisk, townScope, mapUrl), the per-row fields, the row cap, and the empty-result behavior. Nothing an agent needs to call this correctly or interpret the answer 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 50%, with `town` well documented in-schema while `category` carries only an enum and no prose in either place. The description partly compensates by explaining that `town` is read in the asker's own words, that regions are answered across every hamlet, and that unrecognized names return empty rows with `didYouMean`; but the category parameter is never mapped to its enum values, leaving one of two parameters under-specified.
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 with scope: 'What is open in an East End town at this moment and until when', computed from verified hours against America/New_York. It also enumerates the venue categories covered, which lets an agent separate it from siblings like search_places (general lookup) and recently_closed (historical status) 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?
Usage context is implied rather than declared: 'at this moment' plus the category list tells an agent this is a real-time open/closed query, and the townScope notes explain how the place argument is read. However, no sibling is ever named and there is no explicit when-not guidance, so an agent must infer that static lookups belong in search_places and closed-venue questions in recently_closed.
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, each with the operator's own booking page (bookDirect), phone, address and the date the guide last read that source. query matches the fields the guide keeps, not only names: 'pet friendly', 'pool', 'beachfront', 'camping', 'family', 'walk to town' and 'year-round' all resolve. Each row carries season, whether the property is year-round or the months it operates. amenitiesUnknown counts lodgings in scope with no amenity list on file, so an amenity query is answered over the lodgings that have one. editorialNote marks records confirmed to exist by a Google Places sweep that no editor has described, and awaitingEditorialPass counts them. priceTier appears only where an editor assigned one and is a coarse band; the guide holds no rates, no availability and no room types. closed is returned when query names a lodging on record as shut. rentalNeighborhoods is the guide's note on which part of a hamlet to rent in. With neither argument nothing is looked up and the answer lists the towns covered. Returns up to 8. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Greenport') or a region ('the Hamptons', 'North Fork'), in the asker's own words. | |
| query | No | What to look for, e.g. 'pet friendly', 'pool', 'beachfront', 'camping', 'B&B', or a property name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds real behavioural context beyond it — a hard cap of 'Returns up to 8', empty rows plus `didYouMean` when `townScope.recognized` is false, `closed` records surfaced when the query names a shut property, and `amenitiesUnknown` explaining that amenity queries only span lodgings with a list on file. That last point is exactly the kind of caveat an agent needs to avoid overstating an amenity answer.
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 opening sentence is properly front-loaded with purpose, but the remainder is a single dense block of backticked field names (`editorialNote`, `awaitingEditorialPass`, `priceTier`, `rentalNeighborhoods`, `townScope`) with no grouping, and 'Returns up to 8' is buried mid-paragraph. For a two-parameter tool the prose is heavy; the content is largely substantive but would read far better split into lookup semantics versus result-field semantics.
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 return-value burden and does so: it explains every non-obvious field, states the 8-row cap, describes the empty-result/`didYouMean` path, and declares the boundaries of the dataset (no rates, no availability, no room types, coarse price bands). An agent has enough to call it correctly and to set expectations in its answer.
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 both parameters are already documented; the description still earns credit by explaining that `query` matches 'the fields the guide keeps, not only names' and by listing concrete resolvable terms ('pet friendly', 'pool', 'beachfront', 'camping', 'family', 'walk to town', 'year-round'). It also clarifies that `town` may be a hamlet or a region in the asker's own words and that `townScope` reports how it was interpreted.
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 and scope: 'Verified East End places to stay: hotels, inns, motels, B&Bs, resorts and campsites', including the operator booking page, phone and address it carries. That is clearly distinguishable from siblings like beach_info, things_to_do or urgent_care, but it never explicitly separates itself from the closest neighbour, search_places, which an agent could plausibly also pick.
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?
Usage is well framed: 'With neither argument nothing is looked up and the answer lists the towns covered' tells the agent what the argument-free call returns, and the explicit scope limit 'the guide holds no rates, no availability and no room types' rules out rate/availability questions before a call is wasted. What is missing is an explicit 'use this instead of search_places when the ask is lodging' routing statement.
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, 102 in all: gyms, yoga, pilates and barre, spin, boxing and HIIT, swimming, running groups, recovery rooms, tennis and pickleball courts, and dance schools. access says whether a visitor can buy one session: 18 of these are members-only, including Tracy Anderson Studio Water Mill, Tracy Anderson Studio Sag Harbor, 11937 Fitness, Equinox Hamptons, Gotham Gym, SLT East Hampton, SLT Southampton. accessPolicy: not-published means the studio sells class packs and publishes no single-class price; classScheduleUrl and phone are given instead. reservationRequired is set where booking ahead is required. Prices are quoted exactly as published, including seasonal pairs ($50 a class in summer, $35 off-season) and residency conditions ("Free (village residents + guests)"), with pricingVerifiedAt, the date the price was read, which is usually older than lastVerified. doorsOpenState / doorsCloseAt are computed on the East End's clock (America/New_York) and describe the venue's hours, not the class timetable, which is at classScheduleUrl. The access argument filters to one access kind; rows that fail the filter come back in ruledOut with the reason. closed names a studio the query matched that has shut for good. With no argument nothing is looked up and the answer lists the kinds and towns covered. Returns up to 8. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words. | |
| query | No | What to look for, 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?
Goes well past the annotations (readOnly/idempotent/non-destructive are already supplied) by disclosing a hard cap of 8 rows, that filtered-out rows return in `ruledOut` with a reason, that `closed` flags permanently shut studios, and that pricing carries `pricingVerifiedAt` which is usually older than `lastVerified`. It also states that `doorsOpenState`/`doorsCloseAt` are computed in America/New_York and describe venue hours, not the class timetable – exactly the kind of non-obvious detail an agent would otherwise misread.
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 subject, which is good, but it degrades into a dense backtick-heavy wall of run-on sentences mixing purpose, field glossary, filtering semantics and fallback behavior. The information mostly earns its place, but the structure makes it hard to scan for the operational facts.
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 a reasonable job: row cap, `ruledOut`, `closed`, `townScope.recognized`, `didYouMean`. Minor gap: only some row fields are named, so an agent can't fully anticipate the row shape, and the interaction between `town` and `query` is not spelled out.
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 defines all three parameters and the `access` enum values. The description still adds meaning: that the `access` filter is exclusive and produces `ruledOut` output, that `townScope` reports how the place argument was interpreted, and what happens when it isn't recognized (`rows` empty, `didYouMean` populated).
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?
Specific resource and scope: 'Verified East End places to train, 102 in all' followed by an enumeration of venue types (gyms, yoga, spin, courts, dance schools). It's clear what the tool returns, though it never distinguishes itself from the sibling `play_sport`, which plausibly overlaps on courts and sport.
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 usage behavior for arguments ('With no argument nothing is looked up and the answer lists the kinds and towns covered'; the `access` argument filters to one kind) but offers no when-to-use versus when-not guidance and never routes the agent to or away from siblings.
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.
benefit_galas2 fields changedInput schema / properties / query / descriptionPrevious value: -"What they are after, e.g. 'animal', 'ARF', 'black tie', 'film', 'land trust', or a benefit's name."New value: +"What to look for, e.g. 'animal', 'ARF', 'black tie', 'film', 'land trust', or a benefit's name."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('East Hampton', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words."New value: +"A hamlet ('East Hampton', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words."community_help2 fields changedInput schema / properties / query / descriptionPrevious value: -"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'."New value: +"The need, in the asker's 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'."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('East Hampton', 'Riverhead') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words."New value: +"A hamlet ('East Hampton', 'Riverhead') or a region ('the Hamptons', 'North Fork'), in the asker's own words."find_shops2 fields changedInput schema / properties / query / descriptionPrevious value: -"What they want, e.g. 'bookshop', 'toys', 'flowers', 'swimwear', 'gift', or a store's name ('The Wharf Shop')."New value: +"What to look for, e.g. 'bookshop', 'toys', 'flowers', 'swimwear', 'gift', or a store's name ('The Wharf Shop')."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('Sag Harbor', 'East Hampton') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words."New value: +"A hamlet ('Sag Harbor', 'East Hampton') or a region ('the Hamptons', 'North Fork'), in the asker's own words."getting_here2 fields changedInput schema / properties / mode / descriptionPrevious value: -"'car-free' when the asker has no car (drops driving); 'driving' for road answers only. Omit for every option."New value: +"'car-free' drops driving; 'driving' returns road answers only. Omit for every option."Input schema / properties / to / descriptionPrevious value: -"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."New value: +"The destination, a hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words. Omit for the whole picture."golden_hour2 fields changedInput schema / properties / query / descriptionPrevious value: -"What they want, e.g. 'dinner', 'drinks', 'no walk', 'wheelchair', 'dog', 'kids', 'vineyard', or a spot's name."New value: +"What to look for, e.g. 'dinner', 'drinks', 'no walk', 'wheelchair', 'dog', 'kids', 'vineyard', or a spot's name."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words."New value: +"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words."picnic_spots2 fields changedInput schema / properties / query / descriptionPrevious value: -"What they want, e.g. 'sunset', 'shade', 'oceanfront', 'quiet', 'big group', or a park's name."New value: +"What to look for, e.g. 'sunset', 'shade', 'oceanfront', 'quiet', 'big group', or a park's name."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words."New value: +"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words."plan_my_day6 fields changedInput schema / properties / date / descriptionPrevious value: -"ISO date in East End local time; defaults to today."New value: +"ISO date (YYYY-MM-DD) in East End local time; defaults to today."Input schema / properties / party_size / descriptionPrevious value: -"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."New value: +"Number of people, as digits. Stops whose operator publishes a maximum below this number carry a `capacityWarning` quoting the operator's line. When omitted, no capacity check is made."Input schema / properties / saved_places / descriptionPrevious value: -"Comma-separated saved venue names supplied by the asker. Never infer private account data."New value: +"Comma-separated venue names the asker wants included, used as preferences only."Input schema / properties / seed / descriptionPrevious value: -"Optional stable seed when the asker wants the same result repeated."New value: +"Optional stable seed; the same seed and inputs reproduce the same plans."Input schema / properties / vibes / descriptionPrevious 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."New value: +"Comma-separated interests from: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Values outside this list do not influence the plan and are reported in `vibesNotUnderstood`."Input schema / properties / who / descriptionPrevious 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."New 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`, a group with children is `family`, and common aliases are resolved to the nearest value, which the answer reports in `whoReadAs`. Group size is `party_size`."play_sport2 fields changedInput schema / properties / sport / descriptionPrevious value: -"The sport, in the asker's own words, 'pickleball', 'hoops', 'paddle', 'surfing', 'disc golf', 'trail running'. A venue name ('Shinnecock', 'Montauk Downs', 'skate park') works too."New value: +"The sport, in the asker's own words: 'pickleball', 'hoops', 'paddle', 'surfing', 'disc golf', 'trail running'. A venue name ('Shinnecock', 'Montauk Downs', 'skate park') also resolves."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'East End'). Pass the asker's own words."New value: +"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'East End'), in the asker's own words."search_places1 field changedInput schema / properties / town / descriptionPrevious value: -"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."New value: +"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork', 'East End'), in the asker's own words: a trailing state and ZIP, British spellings and typos are resolved."tap_water1 field changedInput schema / properties / place / descriptionPrevious value: -"Where they are: a hamlet ('Montauk', 'Springs', 'Wainscott'), a region ('the Hamptons', 'North Fork'), or a ZIP ('11937'). Pass the asker's own words."New value: +"The place: a hamlet ('Montauk', 'Springs', 'Wainscott'), a region ('the Hamptons', 'North Fork'), or a ZIP ('11937'), in the asker's own words."things_to_do3 fields changedInput schema / properties / month / descriptionPrevious value: -"Month to judge the season for, e.g. 'October' or 'Oct'. Omit for now, the default is today's month on the East End."New value: +"Month to judge the season for, e.g. 'October' or 'Oct'. Defaults to today's month on the East End."Input schema / properties / query / descriptionPrevious value: -"What they want to do, e.g. 'kayak', 'fishing charter', 'surf lesson', 'seals', 'hiking', 'camping', 'whale watching', or an operator's name."New value: +"The activity, e.g. 'kayak', 'fishing charter', 'surf lesson', 'seals', 'hiking', 'camping', 'whale watching', or an operator's name."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words."New value: +"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words."upcoming_events3 fields changedInput schema / properties / to / descriptionPrevious value: -"ISO date, default from+7. Same date as `from` for a single day/tonight."New value: +"ISO date, default from+7. The same date as `from` gives a single day."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('Montauk') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words."New value: +"A hamlet ('Montauk') or a region ('the Hamptons', 'North Fork'), in the asker's own words."Input schema / properties / who / descriptionPrevious value: -"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."New value: +"Who is going. When omitted, 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. `kids`, `teens` or `family` include those programs; `everyone` returns the whole calendar."urgent_care2 fields changedInput schema / properties / need / descriptionPrevious value: -"`er` (hospital emergency department), `urgent-care`, `pharmacy`, `vet` (emergency vet). Omit to get all four, the whole list is 10 facilities."New value: +"`er` (hospital emergency department), `urgent-care`, `pharmacy`, `vet` (emergency vet). Omit for all four."Input schema / properties / town / descriptionPrevious value: -"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."New value: +"The asker's town or hamlet ('Montauk', 'Sag Harbor'). Facilities in that town sort first; nothing is filtered out."whats_open_now1 field changedInput schema / properties / town / descriptionPrevious value: -"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."New value: +"A hamlet ('Sag Harbor', 'Montauk') or a whole region ('the Hamptons', 'the North Fork', 'the East End'), in the asker's own words; a region is answered across every hamlet in it."where_to_stay2 fields changedInput schema / properties / query / descriptionPrevious value: -"What they want, e.g. 'pet friendly', 'pool', 'beachfront', 'camping', 'B&B', or a property name to check."New value: +"What to look for, e.g. 'pet friendly', 'pool', 'beachfront', 'camping', 'B&B', or a property name."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('Montauk', 'Greenport') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words."New value: +"A hamlet ('Montauk', 'Greenport') or a region ('the Hamptons', 'North Fork'), in the asker's own words."work_out2 fields changedInput schema / properties / query / descriptionPrevious value: -"What they want, e.g. 'yoga', 'gym', 'pickleball', 'spin', 'salsa class', 'cold plunge', or a studio's name."New value: +"What to look for, e.g. 'yoga', 'gym', 'pickleball', 'spin', 'salsa class', 'cold plunge', or a studio's name."Input schema / properties / town / descriptionPrevious value: -"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words."New value: +"A hamlet ('Montauk', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'), in the asker's own words."getting_here1 field changedInput schema / properties / to / descriptionPrevious value: -"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."New value: +"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."plan_my_day3 fields changedInput schema / properties / party_size / descriptionPrevious value: -"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."New value: +"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."Input schema / properties / vibes / descriptionPrevious 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."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 / descriptionPrevious 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."New 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."play_sport1 field changedInput schema / properties / sport / descriptionPrevious value: -"The sport, in the asker's own words — 'pickleball', 'hoops', 'paddle', 'surfing', 'disc golf', 'trail running'. A venue name ('Shinnecock', 'Montauk Downs', 'skate park') works too."New value: +"The sport, in the asker's own words, 'pickleball', 'hoops', 'paddle', 'surfing', 'disc golf', 'trail running'. A venue name ('Shinnecock', 'Montauk Downs', 'skate park') works too."recently_closed1 field changedInput schema / properties / since / descriptionPrevious value: -"ISO date — only closures dated on or after this"New value: +"ISO date, only closures dated on or after this"search_places1 field changedInput schema / properties / town / descriptionPrevious value: -"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."New value: +"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."things_to_do1 field changedInput schema / properties / month / descriptionPrevious value: -"Month to judge the season for, e.g. 'October' or 'Oct'. Omit for now — the default is today's month on the East End."New value: +"Month to judge the season for, e.g. 'October' or 'Oct'. Omit for now, the default is today's month on the East End."urgent_care1 field changedInput schema / properties / need / descriptionPrevious value: -"`er` (hospital emergency department), `urgent-care`, `pharmacy`, `vet` (emergency vet). Omit to get all four — the whole list is 10 facilities."New value: +"`er` (hospital emergency department), `urgent-care`, `pharmacy`, `vet` (emergency vet). Omit to get all four, the whole list is 10 facilities."whats_open_now1 field changedInput schema / properties / town / descriptionPrevious value: -"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."New value: +"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."find_shops1 field changedInput schema / properties / category / enumPrevious value: -[
- "fashion",
- "jewelry",
- "swimwear",
- "activewear",
- "kids",
- "toys",
- "home",
- "books",
- "beauty",
- "consignment",
- "accessories",
- "general-store",
- "florist"
-]New value: +[
+ "fashion",
+ "jewelry",
+ "swimwear",
+ "activewear",
+ "kids",
+ "toys",
+ "home",
+ "books",
+ "beauty",
+ "consignment",
+ "accessories",
+ "general-store",
+ "florist",
+ "antiques"
+]beach_info1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"benefit_galas1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"community_help1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"find_shops1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"getting_here1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"golden_hour1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"parking_permit_rules1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"picnic_spots1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"plan_my_day1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"play_sport1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"recently_closed1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"search_places1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"tap_water1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"things_to_do1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"upcoming_events1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"urgent_care1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"whats_open_now1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"where_to_stay1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"work_out1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"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_dayRead-only tools: EMS protocols, courts and judges, NPI and FDA data, GPU fit for open models.
Live Las Vegas shows, restaurants, attractions and resorts. Read-only, no API key needed.
Read-only tools for current SofiaStage events, venues, cities, performers, and editorial.
Sights, events, opening hours, weather and tides; nearby sharing as currently reported.
Add one secure layer between your agents and this server.
