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 carries the full burden and does so richly: provenance of addresses (brand's own store page, never a homepage or third party), coordSource corroboration, three brands publishing wrong schema.org geo, a hard 'no hours' constraint with instructions never to claim open/closed, a fallback to `phone`, and a result cap of 8. This is exactly the behavioral context an agent needs.

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

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

Front-loaded with the verb, resource, and coverage counts before any caveats. The provenance and hours passages are long but each prevents a concrete failure (hallucinated addresses, fabricated opening hours), so they earn their place; the text could still be tightened slightly.

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 and no annotations, so the description must cover returns and limits — it states 'Returns up to 8' and the no-argument fallback. For a 3-parameter lookup tool it leaves no material gap an agent would need before invoking 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 coverage is 67%, and the description adds real meaning: `query` 'reads the name, the brand, the category and the one-line `what` the guide keeps', confirming fuzzy multi-field matching beyond the schema's example list. It also documents the no-argument behavior (returns categories and towns), which is parameter-adjacent semantics the schema cannot express.

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

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

States a specific resource (verified East End shops) with concrete scope — 74 stores across 9 hamlets on the South Fork, North Fork and Shelter Island — and enumerates the covered categories. It also explicitly distinguishes itself from the sibling `search_places`, so an agent can route without opening a schema.

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

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

Gives explicit trigger vocabulary ('any shop, shopping, store, boutique, browse, bookshop, gift or where-can-I-buy question') and a second use case ('the shopping half of a day plan'). It also names the condition that excludes it from a sibling: shops lack hours, which is why `search_places` is used instead.

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 provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly: it discloses determinism, that three options are produced, the full constraint set applied before returning (closures, date/opening hour, age, budget, weather, daylight, geographic sequencing, max drive), that saved_places is a preference lane that never overrides safety rules, and that the connector cannot read private account data. This is rich behavioral context beyond any structured field.

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 (~200 words) but dense — every sentence carries operational meaning and there is no fluff. The usage-vs-alternative guidance is front-loaded in the first sentence, and later sentences each add a distinct behavioral fact. For a 9-parameter planner, the length is justified; a minor trim of the saved_places sentence could tighten it, but it is not bloated.

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 carry the full contract, and it does: it pre-announces return shape (three distinct options), reports fields (whoReadAs, vibesNotUnderstood, capacityWarning), covers privacy limitations, and states the deterministic constraint set. For a complex 9-param tool with zero structural safety nets, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 78%, so the schema already documents most parameters; the description adds genuine value on top for key ones: saved_places is explained as a preference lane that never overrides rules, party_size gains the capacityWarning behavior with a concrete Sag Harbor example, and vibes gains the vibesNotUnderstood non-silent-drop behavior. A few params (town, energy, budget) rely on the schema alone, but the description compensates where behavior matters most.

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 (build/plan), a concrete resource (a complete East End day), and immediately distinguishes itself from the sibling search_places ('which returns an unordered list'). The title reinforces scope. An agent can tell exactly what this tool produces and how it differs from nearby tools without opening the schema.

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

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

Explicitly names the trigger condition ('whenever someone asks... to plan, schedule, sequence, or personalize a day') and names the alternative it is not (search_places). It also gives operational guidance for saved_places — ask the user for names when they want them included — and instructs the agent to present rather than substitute stops. Nothing is left to inference.

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

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?

No annotations are provided, so the description carries the full burden and does so richly: it discloses that closed venues are excluded, a default page size of 8 plus a total match count, the withheld open/closed verdict for seasonal venues from Nov-Apr, the substitute hoursText field with an instruction to quote not assert, and the seasonalCaution flag with concrete counts. These are exactly the behavioral traits an agent cannot infer from 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?

Front-loaded with the core capability in the first clause, and most sentences carry distinct high-value content. It is dense and long, with some statistical asides (counts of Montauk venues) that sit close to the line between useful signal and bulk, so not a perfect 5.

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 annotations and no output schema, the description must explain both the safety/scope profile and the return shape, and it does: matched fields (address, phone, open state, provenance), attribution requirements, the hoursText fallback, and the seasonal nuance. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 67%, and the description adds meaning beyond it by explaining that query matches underlying section fields rather than just names, with illustrative examples ('pick-your-own', 'sunflowers', 'sorbet') that show the intended query style. The town and category parameters are already documented in the schema, so the description need not repeat them.

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 (search) and resource (the verified guide's venues across the Hamptons + North Fork), enumerates the covered sections, and explicitly distinguishes itself from the sibling recently_closed. An agent can route between the two without opening either schema.

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

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

Gives explicit when-to-use conditions ('check a venue you are about to recommend from memory') and names the alternative (recently_closed) for the one case this tool cannot serve (asking about a shut place by name). The semantic-search framing ('it searches the fields each section actually keeps') tells the agent what kind of query to send.

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 carries full responsibility for disclosing behavior. It thoroughly explains that results are source-verified with sourceUrl and a last-checked date, handles timezone conversions (America/New_York), explains the semantics of `access` values, and describes the `townScope` behavior including the distinction between not-found and quiet week. It even details defaults (7-day window, 12 results). 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 densely packed with necessary information—every sentence adds value. It is front-loaded with the core purpose, then expands into usage nuances, timezone handling, access field semantics, town handling, and defaults. Despite its length, it remains structured and efficient, avoiding redundancies.

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 complexity (3 optional parameters, no output schema, no annotations), the description is exceptionally complete. It covers all invocation scenarios, edge cases (like `townScope.recognized: false`), and interpretation of results (like `access` values). It provides everything an agent needs to use and respond correctly, including how to phrase responses in specific situations.

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 covers all three parameters, the description adds significant meaning: it explains that `from` defaults to today (East End local), `to` defaults to from+7, and using the same date for a single day/tonight. It instructs to pass the asker's own words for `town` and explains the meaning of `townScope.recognized: false` and `didYouMean`. This goes well beyond the schema's basic definitions.

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

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

The description clearly states the tool's purpose: providing source-verified East End events for time-bound queries. It explicitly mentions specific use cases like 'tonight, this weekend, next Saturday' and distinguishes from memory-based answers. This makes it distinct from sibling tools like 'things_to_do' or 'whats_open_now' by focusing on verified, time-bound event data.

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 explicitly says when to use this tool ('for anything time-bound') and when not to ('never answer those from memory'). It also provides detailed guidance on interpreting the `access` field before recommending an event, and how to handle `townScope.recognized: false` and empty results. This is more than just context; it gives clear instructions for correct usage.

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 the full burden and does so richly: result ordering (closing-soonest-first), returned fields (closesAt, address, phone, source + verified date), result cap of 10, and precise semantics for hoursUnknown, publishedHoursOnly, opensNext, seasonalClosureRisk, and townScope. It even explains the reasoning behind seasonal exclusion (stale summer hours).

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

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

Dense and long, but front-loaded with the core purpose and usage trigger, then layered with edge-case handling. Nearly every sentence earns its place, though the seasonal-closure passage is somewhat sprawling and could be tightened.

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 the return shape — and it does, covering ordering, fields, counts, and fallback arrays. Combined with the usage routing and seasonal caveats, an agent has everything needed to call and interpret this 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 50%, and the description compensates well: it describes townScope.recognized/didYouMean behavior for the town parameter and confirms region-vs-hamlet handling. It lists categories that map to the enum, adding little beyond the schema there, but the town-side semantics exceed the schema.

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

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

States a specific capability — what is open in an East End town right now and until when, computed against the region's own timezone. It also enumerates the covered venue categories and clearly separates itself from sibling tools that handle events, beach info, or planning.

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 routes the call: 'Call this for anything phrased as now, right now, still open, tonight, this late.' It also gives conditional usage rules — read seasonalClosureRisk from November to April, treat townScope.recognized:false as a not-found rather than 'nothing is open', and use opensNext when little is open.

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.