Hamptons Verified

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

With no annotations, the description carries the full burden and does so well: it discloses that town/hamlet queries return multiple beaches, that readAs reports the resolved place, that results include source and date, and that output is capped at 5. It doesn't cover every edge case, but the main behavioral traits are clearly conveyed.

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 fairly long but dense with necessary detail. It is front-loaded with the main purpose, then adds resolution behavior, usage guidance, and a sibling alternative. Every sentence contributes, though some tightening could make it even more scannable.

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 simple single-parameter schema and lack of annotations or output schema, the description is remarkably complete: it covers what results are returned, the dynamic dog-rule aspect, the parking permit scope, source/date metadata, output limit, and when to use an alternative. The agent has enough to invoke the tool correctly in context.

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

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

The schema covers the parameter name and example inputs, but the description adds meaning beyond that by explaining how town/hamlet names resolve, that readAs reports the matched place, and that multiple results (up to 5) are possible. This is useful context the schema alone does not provide.

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 that the tool returns beach-specific information (dog rules today, parking permit, car-free access, lifeguards, rip currents) for one named beach or all verified beaches in a town. It explicitly distinguishes itself from sibling tools by naming parking_permit_rules as the alternative for permit maps.

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 direct invocation guidance: 'Call this for any dog question' and 'Also call it before saying anyone can just park at a beach.' It also states when to use parking_permit_rules instead, providing a clear exclusion and alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden of behavioral disclosure, and it is remarkably forthcoming about quirks: dead ticket links, unpublished rates, the need to quote verbatim from `publishedTiers`, and the 'from' parameter gating past events. However, a few numerical inconsistencies (e.g., 'Cocktail' on 16 of 15 events, 'wrong twenty-six times out of twenty-seven') introduce confusion in an otherwise transparent account.

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 densely packed with essential caveats, but it is also overlong and at times convoluted (e.g., 'unknowable from your weights', 'cuts both ways', 'the black-tie assumption you would reach for is wrong twenty-six times out of twenty-seven'). While front-loaded with purpose and usage, several sentences could be tightened without losing meaning, and the internal contradictions undermine clarity.

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 tool's complex data model (ticket pricing nuances, dress codes, beneficiary info, seasonal fixtures) and the absence of an output schema, the description is remarkably complete. It tells the agent what fields exist, what to quote, what to avoid estimating, how to handle donation/volunteer questions, and how to interpret edge cases like dead links and unpublished rates.

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?

Although the schema already covers all five parameters, the description adds substantial semantic value beyond the field names: it explains the meaning of `tickets.publishedRate`, `tickets.tier`, `tickets.publishedTiers`, `beneficiary`, and `alsoThisSeason`, and it operationalizes the `from` parameter ('Past benefits never appear unless you pass `from`'). This goes far beyond the schema's minimal descriptions.

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 tool's domain: '15 dated charity galas, each joined to the nonprofit it raises for.' It goes beyond the title by explicitly enumerating the question types it answers ('gala, benefit, fundraiser, charity, black-tie, what-should-I-wear, where-can-I-donate or where-can-I-volunteer'), making it easy to distinguish from sibling tools like `upcoming_events` or `community_help`.

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 gives explicit, actionable guidance on exactly when to invoke the tool: 'Call this for any gala, benefit, fundraiser, charity, black-tie, what-should-I-wear, where-can-I-donate or where-can-I-volunteer question.' It also provides strong negative guidance, e.g., 'NEVER state or estimate a price' when `tickets.publishedRate` is false, and explains the `from` parameter's role for accessing past benefits.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

There are no annotations, so the description carries the full burden. It discloses the risk of answering from memory ('the asker loses a day's work finding that out'), explains computed fields with timezone handling, describes the offEastEnd flag and its required communication, and sets strict rules about not naming unlisted providers. This is exceptionally transparent.

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 lengthy but justified given the tool's complexity. Every sentence contributes, from the list of services to the rules about quoting Spanish and not naming out-of-results providers. It could be slightly more structured with bullet points, but it remains efficient and well-ordered.

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?

The description fully covers the tool's behavior: returns up to 8 records each containing phone, source, sourceUrl, lastVerified, and bilingual text; explains computed fields (next masses, inSeasonNow) with timezone; and handles edge cases like offEastEnd and no-argument calls. Since there is no output schema, this level of detail is necessary and sufficient.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful guidance beyond the schema: passing the asker's own words for query and town, 'need' as a shortcut vocabulary, and the no-argument behavior where nothing is looked up but needs/towns are returned. This enriches understanding without being exhaustive.

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 the tool is a bilingual community directory for free and low-cost services on the East End, and explicitly says 'Call this for any I-need-help question' with a list of examples. It distinguishes itself from sibling tools by covering a broad range of social services rather than specific topics like beaches or 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 provides explicit when-to-use guidance: 'Call this for any I-need-help question' and lists concrete scenarios such as unpaid wages, eviction, medical care, and English classes. It also gives contextual rules like quoting Spanish verbatim and never volunteering safety claims unless the record states them, which clarifies appropriate usage versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description fully discloses behavior: it uses published fares with source timestamps, computes `roadConditionsNow` against America/New_York, explains source caveats for links that don't publish data, and clearly states the tool provides published patterns not live incidents. This is thorough and honest about limitations.

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 a single, dense paragraph of ~300 words. It is front-loaded with an overview and contains valuable details, but it lacks clear structure or brevity. Some sentences could be trimmed (e.g., the repeated emphasis on 'without a car'). It earns its place content-wise but is not concise or easy to scan.

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?

Despite no output schema, the description gives a comprehensive picture: what modes are covered, how fare data is sourced, how `roadConditionsNow` works, how `to` affects output, and explicit caveats about source attribution and lack of live data. For a tool with this complexity, the description is remarkably 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?

The schema provides descriptions for both parameters, and the description adds meaningful details beyond them. For `to`, it explains the output effect (reports Jitney stops and drive-time rows with typical AND summer minutes). For `mode`, it mostly restates the schema but reinforces 'car-free' as the right choice for without a car. This is helpful but not a huge leap beyond the structured data.

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 the tool's purpose: how to get to the East End and around it, covering specific transit modes (Hampton Jitney, LIRR, ferries, etc.) and driving. It explicitly says to call this for any getting-there, how-long, how-much, or when-should-I-leave question, distinguishing it from sibling tools about beaches, parking, or events.

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 gives explicit usage guidance: call for any travel question, pass `to` with the asker's own destination words, pass `mode: 'car-free'` for someone without a car. It also clarifies when NOT to use the tool ('There is no live incident feed behind this'), preventing misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are present, so the description carries the full burden. It discloses computation logic ('time is computed from that spot's own latitude and longitude'), derived fields ('goldenHour', 'blueHour', 'arriveBy'), countdown semantics ('startsIn counts down... alreadyPassedToday'), a unique warning field ('wrongWayRound'), a hard cap ('Returns up to 8'), and an exclusion (weather). This is exemplary transparency.

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 long but dense with necessary nuance; every sentence introduces behavior or guidance that the schema and annotations do not provide. It is not tautological or padded. Minor redundancy exists (multiple mentions of the clock/timing), but the structure is front-loaded and each clause serves a purpose.

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 tool with 4 parameters, no output schema, and no annotations, the description covers the essential behavioral context: return fields, field meanings, timing semantics, edge cases ('alreadyPassedToday'), and a warning against a common mistake ('wrongWayRound'). It even cautions about weather and seasonal availability. This is complete enough for an agent to invoke 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 baseline is 3. The description adds real value beyond the schema by explaining the implications of `when` ('Pass when: 'sunrise' for the morning side; the default is sunset'), `date` ('to plan ahead... read inBestMonth'), and `query` via examples. It stops short of enumerating every parameter, but its guidance enriches the schema sufficiently.

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

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

The description opens with a specific scope: 'Verified East End sunrise and sunset viewpoints' with named venue types. It clearly identifies the tool's job via 'Call this for any sunset, sunrise, golden hour, blue hour, best-views or where-should-we-watch question', differentiating it from sibling tools like beach_info or whats_open_now.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit invocation triggers are given: 'Call this for any sunset, sunrise, golden hour, blue hour...' and even 'call it even when you think you know the spot'. It also states an exclusion: 'There is no weather here, so never promise a clear sky,' giving clear when-not-to-use guidance. No alternative tools are named, but the context is unmistakable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses time-aware enforcement (enforcement.enforcedRightNow) computed from season/daily window, flags 16 state/county/DEC beaches with outsideTheStickerMap, and explains the common wrong sticker assumption. This goes well beyond a typical description.

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 long but dense with valuable information. Every sentence adds context, from the permit-line resolution to enforcement timing and the outside-the-sticker-map flag. The illustrative example about East Hampton sticker is useful, not fluff. It could be tightened slightly, but it is well-structured and front-loaded with the core purpose.

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?

Despite having no output schema and no annotations, the description completely covers the tool's behavior: input variations, output fields, time sensitivity, edge cases (16 beaches outside the map), and the alternative tool. It explains the key flags and result types, making it fully self-sufficient for an agent to decide when and how to invoke it.

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 already covers 100% of the single parameter, but the description adds meaningful semantics: it explains that passing a beach returns a lot verdict, passing a town/hamlet returns jurisdiction plus beaches' lines, and omitting returns the whole map. It enriches examples and clarifies output variations beyond the schema's basic type description.

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 it resolves parking permit rules for East End beaches across all 7 jurisdictions, with a specific verb and resource. It distinguishes from the sibling beach_info by explicitly redirecting dog, lifeguard, and transit questions to that 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?

Explicitly says to use beach_info for dogs, lifeguards, and getting there without a car. It also explains the different input modes (beach name vs town/hamlet vs omitting 'where') and what each returns, giving clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden and exceeds it. It discloses nuanced behaviors: the alcohol field is a sentence not a boolean, closesAt is computed from each spot's coordinates for today's sunset, hoursText should be quoted when not machine-readable, and results are capped at 8. It also alerts the agent to the legal stakes of guessing, which is critical context.

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 a dense paragraph, but every sentence carries substantive information—purpose, usage, alcohol rule details, time resolution logic, and exclusions. It is front-loaded with purpose and usage, though the lack of formatting (bullets or sections) makes it less scannable. Slightly verbose for a tool definition, but no word is wasted.

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?

Despite no output schema, the description provides a thorough mental model of the response: it mentions fields like `alcohol`, `glassBottles`, `fireOrGrill`, `dogs`, `closesAt`, `hoursText`, and `permitUrl`, and explains how to interpret them. It also covers edge cases (sunset-based closing times, non-machine-readable hours) and explicitly distinguishes from beach_info, making it complete for the tool's complexity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the `allows` filter behavior: 'Pass `allows` to filter to what the picnic needs' and clarifies that 'alcohol' includes wine-only and permit-only spots, each flagged in its own alcohol line. This semantic nuance improves the agent's ability to use the filter correctly.

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 explicitly defines the tool as 'Verified East End picnic grounds' with a clear scope (public parks, state and county parks, winery lawns, etc.) and a specific purpose: determining the legality of a picnic plan (alcohol, grill, dogs). It distinguishes itself from sibling tools by stating the ocean beaches are covered by 'beach_info's', not this 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?

The description gives explicit when-to-use guidance: 'Call this for any picnic, blanket, park, park-hours, barbecue or fire-pit question, and ALWAYS before saying anyone can drink outdoors.' It also provides a when-not-to-use exclusion: 'The guide holds NO drinking rule for the ocean beaches — those are beach_info's' and warns against relying on memory, making the usage conditions unmistakable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

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

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

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

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden. It discloses behavioral traits beyond a simple lookup: distinguishes permanently closed, temporarily closed, and never-existed, and states every record includes confirmation date and reporter. This provides valuable context about data provenance and classification, though it doesn't explicitly mention read-only safety or rate limits.

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 a single focused paragraph with all information earning its place. It front-loads usage guidance with (a) and (b). Some phrasing like 'in every model's training data and in nobody's town' is illustrative but slightly embellished; still, it remains compact and well-structured.

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 no output schema, the description adequately explains return behavior: a verdict, closure categories, and metadata (confirmation date and reporter). It covers edge cases (venues still listed as operating, never-existed places). For a simple check tool with three params, the description is complete and self-sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the semantic difference between passing 'name' (get a verdict) and omitting it (list recent closures), and notes the tool returns verdicts even for venues the guide still lists as operating. This enriches the primary parameter's semantics.

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 the tool checks whether a venue is still open or when it closed, with a specific verb ('check') and resource ('venues'). It explicitly distinguishes itself from search_places by instructing to use it before recommending any venue from model knowledge, making sibling differentiation strong.

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?

Provides explicit usage conditions: call it whenever someone asks if a place is still open or when it closed, and before recommending any venue from own knowledge rather than search_places. It also specifies behavior for omitting vs. passing the 'name' parameter, giving clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries full responsibility, and it delivers thoroughly. It discloses search semantics (searches section fields, not just names), output fields (address, phone, open/closed, provenance), behavioral edge cases (seasonal caution with withheld verdicts, prose hours), and operational limitations (excludes closed venues, up to 8 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 description is a dense, single block of text with no fluff, but it is long. It is front-loaded with the core purpose and then systematically covers caveats, so it earns its length, though it could be better organized with bullets for 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?

No output schema exists, so the description must explain return values, and it does: it lists every match's fields, explains provenance, open/closed state, hoursText alternatives, seasonalCaution behavior, and the result limit. It is complete for a search tool with this complexity.

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%, so the schema already documents town and query. The description adds meaningful semantics for the query parameter by explaining it searches section-specific fields (e.g., 'pick-your-own' returns farms running it) and provides examples of valid content. It also implicitly covers category by listing venue types, though it does not explicitly map each category param.

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

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

The description opens with a clear verb and resource: 'Search the verified guide's venues across the Hamptons + North Fork' and enumerates categories. It also explicitly differentiates itself from the sibling tool recently_closed by stating closed venues are excluded and 'to ask about one by name... use recently_closed instead.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names an alternative (recently_closed) for closed-venue queries, and provides detailed guidance on when to cite provenance, how to treat hoursText vs. openState, and how to interpret seasonalCaution. This goes beyond implied usage to concrete do/don't instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description fully discloses behavior: it explains that 'safe' refers only to public water, identifies private-well hamlets, warns about model-garbling of Wainscott's story, and details what each output field contains. It also clarifies the Stage 1 Water Alert is not a health warning and gives the rationale for omitting URLs in `utilities`. This goes far beyond a typical description.

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 long but well-structured and front-loaded with the core purpose. Each section adds value, though some redundancy exists (e.g., repeating the private-well warning in different forms). It earns a 4 rather than 5 due to its length and some repetitive phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema means the description must explain return values, and it does thoroughly: `verdict`, `status`/`statusMeaning`, `filterRecommendation`/`filterCaveat`, `sources`, `utilities`, and `noVerdictHeld` are all described. It also covers edge cases like private wells and unsupported places, making it complete for complex real-world queries.

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 provides thorough documentation for the single `place` parameter, including examples and instruction to pass the asker's words. The description reinforces the optionality and adds a usage note ('With no argument...'), but does not add significant new semantic information beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a precise statement: 'Whether the tap water is drinkable, hamlet by hamlet, from the guide's read of the water utility's and the state health department's own reporting.' It further lists explicit trigger phrases ('drink-the-water, tap, well, filter...'), distinguishing it from siblings like beach_info or whats_open_now.

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 provides explicit when-to-use guidance: 'Call this for any drink-the-water, tap, well, filter, bottled-water, PFAS, 1,4-dioxane or is-the-water-safe question, and call it before reassuring anybody.' It also instructs on the no-argument case: 'With no argument nothing is looked up: you get the hamlets covered, so ask which one.' This is strong usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden. It discloses key behaviors: every result carries `inSeasonNow`, `noCommercialOperator: true` means no operator exists, operators are never invented, `seasonUnknown` must be quoted verbatim, and results are capped at 8. This is a rich, honest disclosure of how the tool behaves beyond just 'what it does.'

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 long, but every sentence adds value—scope, usage, key features, special flags, and limits. It is front-loaded with the main purpose and structured logically. Slightly verbose, but the density of critical information justifies the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, the description is remarkably complete. It covers what is returned, seasonality logic, the no-commercial-operator edge case, permits, conditions, skill limits, and the empty-query response. Agents have enough context to invoke it 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%, but the description adds substantial meaning beyond the schema. It explains month defaults to current, gives query examples, and specifies that passing neither query nor town returns kinds and towns instead of looking up. This contextual information helps the agent use parameters correctly.

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 what the tool does: 'What there is to DO on the East End' and enumerates activities, businesses, and wildlife. It explicitly directs agents to 'Call this for any what-should-we-do, where-can-I-<verb>, outdoors, on-the-water, boating, hiking or wildlife question,' distinguishing it from siblings like beach_info or 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?

Provides explicit when-to-use guidance: 'Call this for any what-should-we-do...' and explains the fallback when no query or town is given. It also differentiates from answering from memory by highlighting the tool's specialized seasonality and no-commercial-operator verification, giving clear context for preference over alternative approaches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description fully carries the behavioral burden. It discloses source verification, access gating (sold-out, approval, invite-only), timezone handling, defaults (next 7 days, up to 12 results), and the meaning of townScope.recognized: false. It even warns about the current gated-event count, giving the model concrete context beyond 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?

Although long, the description is dense and purpose-driven. It front-loads the core purpose, then logically walks through access, town handling, and defaults. Every sentence contributes critical nuance, and the structure follows the user's decision flow (what, how, when, edge cases).

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?

Despite no output schema or annotations, the description covers all essential aspects: return values (access, sourceUrl, townScope), pagination/truncation, not-found behavior, timezone, and default scoping. It is complete enough for an agent to invoke the tool correctly and interpret results in all described scenarios.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it clarifies that 'to' same as 'from' means a single day, explains the 'town' behavior (matching, truncation, next-event fallback), and ties parameters to real-world use. It adds value without repeating 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 opens with a specific, actionable purpose: 'Source-verified East End events' and explicitly enumerates the use cases ('tonight, this weekend, next Saturday, what's on in Montauk'). It distinguishes this tool from siblings like 'things_to_do' or 'whats_open_now' by focusing on time-bound event discovery with verification.

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 when-to-use guidance: 'Call this for anything time-bound' and instructs never to answer from memory. It also explains how to handle town-specific queries and empty results. However, it does not explicitly name alternative tools for non-time-bound questions or state when not to use it, missing the highest bar for exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description fully discloses behavioral traits: timezone-aware computation, single ER location, 24/7 vet location, staleness indicators, verdict cautions, source caveat, and safety instructions. It warns against common model errors and explains how to interpret fields like coverage.completeness and hoursConfidence.

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 lengthy but front-loaded with purpose and packed with essential caveats. Each sentence adds value, though some phrasing could be tightened (e.g., 'a pharmacy still open tonight' repeats earlier 'pharmacy that is still open'). Overall, it is well-structured for an AI agent needing critical context.

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?

Despite no output schema, the description covers returned fields (openState, closesAt, opensAt, verifiedDaysAgo, hoursConfidence, verdictCaution, sourceCaveat), handles edge cases (towns absent, stale hours, qualifiers), and gives action guidance (give phone, cite source, lead with 911). This is comprehensive for the tool's complexity.

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

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

Schema coverage is 100% for both parameters. The description adds little beyond what the schema already provides; it maps needs to use cases but does not elaborate on parameter values or formats. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource statement: 'Where to go for care on the East End right now — hospital emergency department, urgent care, a pharmacy that is still open, or the emergency vet.' It clearly distinguishes from siblings like whats_open_now and search_places by focusing on urgent/medical care facilities with computed open status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance is provided: 'Call this for hurt, sick, cut, tick bite, stitches, a prescription to fill, a pharmacy still open tonight, or a dog or cat in trouble.' This gives a clear trigger list, though it does not name specific alternative tools or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries full burden and does so thoroughly. It discloses timezone handling, result ordering, response fields (closesAt, address, phone, source), the meaning of hoursUnknown and publishedHoursOnly, seasonalClosureRisk behavior from November to April, the fact that seasonal venues are excluded but not claimed closed, and the 10-result limit. This is exemplary transparency.

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 long but dense and front-loaded. The first sentence delivers the core purpose and timezone; subsequent paragraphs add necessary edge cases. Every sentence earns its place, with no fluff or repetition, and the structure moves logically from general behavior to specific warnings.

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?

Despite having no output schema, the description thoroughly explains return fields, ordering, unknown/parsed hours handling, seasonal exclusions, opensNext fallback, and unrecognized-town semantics. It covers all critical behaviors an agent needs for correct invocation and response interpretation, making it complete for this tool's complexity.

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% (only town has a description). The description compensates somewhat by listing covered categories ('restaurants, breakfast, nightlife, wine, wellness, ice cream, farm stands and oyster farms'), which mirrors the category enum. However, it does not explain region handling for town, category optionality, or how to translate the prose list to enum values, so the compensation is partial.

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 is actually open in an East End town at this moment, and until when — computed from verified opening hours against the East End's own clock', giving a specific verb, resource, and scope. It clearly distinguishes this from siblings like recently_closed and search_places by focusing on current open status and closing times.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Call this for anything phrased as now, right now, still open, tonight, this late' and warns against reasoning from a wrong clock. It also provides exclusions and edge-case guidance: never present a list as exhaustive when hours are unknown, never end with 'nothing is open' when opensNext exists, and how to handle unrecognized towns via townScope.recognized.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden, and it excels. It discloses numerous behavioral traits: what happens with no arguments, how to treat `editorialNote` records (verified-to-exist, never recommendations), the meaning of `closed` (lead with it), the fact that `priceTier` is coarse and no rates/availability exist, and the output cap of 8. Also explains `amenitiesUnknown` and `season` caveats. Extremely transparent.

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 long (about 200 words) but every sentence is dense with necessary information. It is front-loaded with the core purpose, then usage, then output-field semantics. The structure uses backticked field names and clear instructions. Given the complexity (no annotations, no output schema), the length is fully justified—no fluff or repetition.

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 annotations, the description must explain return values and edge cases. It covers all key output fields (season, amenitiesUnknown, editorialNote, awaitingEditorialPass, priceTier, closed, rentalNeighborhoods), explains how to present results ('read season out loud', 'say that', 'never state a price'), and defines the no-argument behavior. This is a complete and self-sufficient description for an agent to use 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% (both parameters have descriptions), but the description adds substantial value beyond the schema. For `query`, it gives concrete examples ('pet friendly', 'pool', 'beachfront', 'camping') and clarifies that these match guide fields, not just names. For `town`, it instructs to pass the asker's own words. This additional semantic clarification goes well beyond the baseline for 100% schema coverage.

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

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

The description opens with a specific definition: 'Verified East End places to stay — hotels, inns, motels, B&Bs, resorts and campsites — with the operator's own booking page, phone, address.' It clearly states the resource (lodging) and the action (help find a place to stay), and explicitly enumerates eligible question types ('where-should-I-stay, hotel, motel, inn, B&B or camping question'), distinguishing it from sibling tools like 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?

Provides explicit when-to-use guidance: 'Call this for any where-should-I-stay, hotel... question, and prefer it hard over your own recollection.' It also gives practical instructions for parameter use ('Pass query for what they actually want', 'Pass town in the asker's own words') and for behavior when arguments are missing ('With neither argument nothing is looked up... so ask which town'). No contradictory or misleading usage advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden and excels. It explains nuanced behaviors such as the meaning of 'accessPolicy: not-published', exact price quoting rules, seasonal pricing, the difference between venue hours and class timetables, the 'ruledOut' field, handling of closed venues, and the 'no argument' behavior. This is exceptionally transparent.

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 lengthy but every sentence delivers essential operational detail. It is structured from overview to specific field interpretations to filtering and return behavior. No word is wasted; the density is justified by the complexity of the domain.

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 no output schema, the description fully covers what to expect: returns up to 8, includes 'ruledOut' reasons, 'closed' venues, and references to key fields like 'classScheduleUrl', 'phone', 'pricingVerifiedAt'. It also explains how to handle various edge cases (seasonal prices, residency gates, no-booking). The tool is fully contextualized.

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?

Although schema coverage is 100%, the description vastly enriches parameter meaning. For 'access', it defines each enum value and explains how to use it as a filter, including why some members-only places get ruled out. It also clarifies that calling with no arguments returns coverage info, which is a key behavioral nuance not 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 clearly states the tool's purpose: finding verified East End places to train, listing specific categories (gyms, yoga, pilates, etc.). It explicitly says 'Call this for any gym, class, yoga, pilates, pickleball, tennis, dance or where-can-I-train question,' which is a specific verb+resource and distinguishes it from generic search tools.

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 gives explicit trigger conditions ('Call this for any gym... question') and behavioral guidance like preferring this tool over memory and passing 'access' to filter. However, it does not mention alternatives or when not to use this tool, so it falls short of a perfect 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.