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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds substantial behavioral context: how `inSeasonNow` is computed, what `noCommercialOperator: true` actually asserts (a checked negative finding, with examples at Napeague and Shadmoor), how `seasonUnknown` is derived from 'Summer-only' listings, that results cap at 8, and exactly what happens when `townScope.recognized` is false (empty rows plus `didYouMean`). None of this is recoverable from the annotations or schema.

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

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

Content is front-loaded and nearly every sentence carries information, but it is a single dense paragraph with heavy backtick fragments and a trailing run-on list ('the permits an activity requires, the conditions it needs, minimum-approach rules for wildlife, and skill and age limits') that reads as an afterthought. It is efficient in information density but not in structure or readability.

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

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

For a complex, zero-required-parameter tool with no output schema, the description does the heavy lifting well: it documents season semantics, the meaning of empty results, the recognized/recognized-false town path, and the 8-row cap. The remaining gap is what to do when the cap is hit — no pagination or narrowing instruction is given, which matters for a tool that can easily match more than 8 records.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: `month` is framed as judging a different month than the default East End calendar month used by `inSeasonNow`, and `town`/`query` are described via the returned `townScope` interpretation and the fallback-to-capability-list behavior when both are omitted. It stops short of undocumented syntax or matching rules, but the added semantic depth is real.

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

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

The description opens with 'What there is to do on the East End' and then enumerates the exact resource classes covered: activities, on-water businesses, and wildlife sightings, with concrete examples ('fishing charters, marinas, sailing schools', 'seals, whales, ospreys'). An agent can immediately tell this is a curated East End recreation/operator lookup rather than a generic place search like search_places or a single-sport tool like play_sport.

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

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

Usage is implied through behavioral rules rather than explicit routing: 'With neither query nor town nothing is looked up and the answer lists the kinds and towns covered' tells the agent this doubles as a capability overview, and 'month judges a different month' clarifies the default. However, there is no statement of when to prefer this over sibling play_sport or beach_info, and no explicit when-not guidance, leaving overlap with activity-related siblings to inference.

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