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

Annotations already declare read-only, idempotent, closed-world, and non-destructive behavior. The description adds valuable mode-dependent return behavior: listing all questions with slug and result count, or returning places for a given slug. It does not detail pagination, but the schema covers that.

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 appropriately sized and front-loads the core purpose with examples. The second paragraph efficiently explains the two modes. It is slightly verbose with examples but every sentence contributes useful 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?

Given the output schema exists and annotations cover safety, the description is complete enough for an agent to call the tool correctly. It explains both modes, including how to obtain slugs from the list mode, which is essential for chaining.

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

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

Schema description coverage is 100%, so the schema already defines each parameter. The description adds meaning beyond the schema by explaining that omitting slug lists all questions with their slugs and counts, while providing a slug returns that question's places. This clarifies the optional slug's behavior.

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 provides ready-made lists answering common dog-access questions and gives concrete examples. It distinguishes the tool's nature as curated Q&A lists rather than free-text search, though it does not name a specific sibling alternative.

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 explains the two usage modes: without a slug to list all questions, and with a slug to fetch places for a specific question. It gives clear context for when each mode applies, though it does not explicitly exclude or compare against sibling tools like search_places.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive) and closed-world scope, so the description is free to add result-shape behavior: it discloses the five possible outcome values and that results come back newest first. It does not mention pagination limits behavior or the ignore-radius-for-areas rule (that lives in the schema), so it is strong but not exhaustive.

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

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

Front-loads the resource and scope in the first sentence, then usage, then an example — a sensible order with almost no filler. The example line partially repeats the routing sentence's intent, but it earns its place by demonstrating parameter granularity.

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 an 8-parameter geo-filtered read tool with a nested point object and an existing output schema, the description covers what it must: what is returned, ordering, the place-vs-point choice, and the sibling routing. Return-value details are correctly left to the output schema.

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

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

Schema description coverage is 100% and every parameter carries a description, including the place/near mutual exclusion and the radius caveat, so the schema does the heavy lifting. The worked example (place="Monterey", since="2026-09-01") usefully shows the date format and place granularity in action, but adds nothing the schema has not already documented.

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 (verification events with their outcome types), a specific scope (within a radius of a town, county or point), ordering (newest first), and explicitly names the sibling it is not ('Use dogpolicies_changes_since for everything everywhere'). An agent can distinguish it from the cluster of similarly-named siblings 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 two concrete use cases ("has anything changed around Tahoe since my last trip?", re-checking a saved itinerary) and an explicit routing rule to the alternative tool, dogpolicies_changes_since, for unfiltered use. When-to-use and when-not are both present.

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?

The annotations already declare this is a read-only, idempotent, non-destructive operation. The description adds useful behavior beyond that: results are newest first, entries include place, outcome, who checked, and record links, and the outcome set is enumerated. It does not cover auth or rate limits, but it provides solid behavioral 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 single, front-loaded sentence that quickly states the purpose before adding detail. It is dense but every clause is relevant, though the outcome enumeration duplicates schema information 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?

With annotations covering safety and an output schema present, the description provides enough context to call the tool correctly: what changes are included, ordering, entry contents, and the polling use case. It need not explain return values further because the output schema exists.

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

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

Schema description coverage is 100%, so the schema already documents parameters like since, limit, offset, outcome, and response_format. The description reinforces the date scope and outcome categories but does not add syntax or format details beyond what the schema provides; 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 states a specific verb and scope: changes in the whole data set since a date, covering verification events and rule changes. The phrase 'whole data set' and 'everywhere' implicitly distinguishes it from the location-scoped sibling dogpolicies_changes_near, so an agent can tell which change-feed tool to use.

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

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

It gives a clear usage context: an agent can poll this cheaply instead of re-reading every record. It does not explicitly name alternatives or exclusions, but the contrast with 'whole data set' versus a near-scoped feed is clear enough for an agent to infer when to use this tool.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the output layout (one row per fact, one column per place, citations for every place) and the inclusion of confidence, freshness and confirmer provenance — information not visible from the annotations.

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

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

Front-loaded with the user's question and the comparison scope, then usage and example in a compact second paragraph. Slightly redundant in repeating the 2–6 range already enforced by the schema, but otherwise every sentence carries content.

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

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

With an output schema present and annotations covering safety, the description correctly focuses on comparison semantics and provenance rather than return-value mechanics. What an agent needs to select and invoke it is essentially all present; only explicit sibling exclusions are missing.

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

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

Schema coverage is 100%, so baseline is 3. The description goes beyond it by restating the 2–6 cardinality constraint in prose and supplying a concrete ids example (["carmel-beach","asilomar-state-beach"]), which clarifies id format in a way the schema's plain string type does not.

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

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

Opens with a specific question-form verb framing ('Compare two to six places') and enumerates exactly which attributes are compared (dogs allowed, leash rule, pet fee, weight limit, etc.). This clearly distinguishes it from dogpolicies_get_place (single place) and dogpolicies_search_places (candidate discovery).

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 states the trigger condition: 'Use after a search returned candidates and the user asks "which one?"' and notes that ids come from any search result, with a concrete example. No explicit when-not clause (e.g., 'do not use for a single place, use get_place'), so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to spend its words on non-obvious result behavior — and it does: the match/possible/excluded bucketing rules, what elevates a hotel to 'possible', and the sort order (matches first, cheapest pet fee first). That is output behavior an agent could not infer from the schema and is exactly the kind of context that changes how results should be reported to a user.

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 one-sentence purpose, then the ranking/eligibility semantics, then four examples that each exercise a different parameter path with no redundancy. Every sentence earns its place and no example repeats another's parameter combination.

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 15-parameter tool with a nested object, four enums and an output schema, the description covers scope, eligibility semantics, ordering and query-to-parameter mapping well. The remaining gap is modest: no mention of how the sibling lookup/planning tools relate, and no note that the underlying policy data can change (relevant given the changes_since/changes_near siblings).

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

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

Schema description coverage is 100%, so the schema already carries the per-parameter burden. The description still adds genuine value by demonstrating how free-form traveler questions decompose into parameter combinations (county vs. near vs. query vs. county+state, plus dogs/nights feeding the fee estimate), which the schema alone does not teach.

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

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

States a specific verb and resource (find hotels/motels) plus the two filters that matter most: pet-friendly for a specific dog and pet fee for the stay, scoped to California and Nevada. This is clearly distinct from siblings like search_places, get_place or plan_trip, which operate on places/policies rather than answering a lodging question.

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 four worked examples give concrete when-to-use signals across the main query shapes (county + weight + budget, point proximity + party size, name lookup, county + state). What's missing is an explicit steer on when to prefer a sibling such as dogpolicies_search_places, dogpolicies_plan_trip or dogpolicies_compare_places instead, so the boundary with siblings is left implicit.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context the annotations don't: what content the policy contains (limits, fees, exceptions) and the added dimension of California/Nevada property counts. It omits what happens for an unrecognized brand, which keeps it from a 5.

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?

Two compact blocks: the return payload first, then the accepted inputs. Every element earns its place, and the enumerated brand list directly reduces lookup failures rather than padding the text.

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

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

With an output schema present, the description needn't explain return structure, and it still summarizes payload contents well. The only real gap is behavior for a brand outside the six listed chains — an agent can't tell whether that errors or fuzzy-matches.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns more by listing the exact accepted brand values and showing that both slug ('red-roof') and display-name ('Kimpton') forms work — detail the schema's 'Brand id or name' does not resolve on its own.

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

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

The first sentence names the resource precisely (a hotel chain's published pet policy) and enumerates the fields returned: pets per room, weight limit, fee, rules, exceptions, and CA/NV property counts. The brand-level scope is clear enough to separate it from property-level siblings like dogpolicies_get_place, though no sibling is named explicitly.

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 by the brand-level framing and the enumerated brand list, so an agent can infer 'use this for chain-wide policy'. However, there is no explicit when-to-use/when-not statement and no routing to alternatives such as dogpolicies_get_place for a specific property or dogpolicies_get_rule for a regulation.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful content-shape context (rules carry display text; sources carry URL, publisher, capture date, quote), which tells the agent this is the heavy-detail endpoint versus a search hit; it does not mention response size or cost of a full fetch.

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 front-loaded first sentence is good, but the second sentence re-says the same thing ('Full rules and sources for one place: every fact with its display text, the rules list, and each source with its URL, publisher, capture date and quote'), a near-duplicate that consumes space without new information. The usage hint and example are buried after the redundancy.

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 an output schema present, the description need not explain return values, and annotations cover the safety profile, so the remaining burden is provenance and precondition — both addressed via the sibling-tool routing. A note on behavior for unknown or ambiguous ids is the only meaningful gap.

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

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

Schema description coverage is 100% and both parameters are documented, including the response_format enum, so the baseline is 3. The only added value is an example id ("carmel-beach"), which duplicates the schema's own example ("fort-funston") and adds nothing about id format or fallback behavior when an id is unknown.

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

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

States a specific verb and resource ('The full record for one place') and enumerates what that record contains: dog rules, rules list, and sources with URL, publisher, capture date and quote. It also distinguishes itself from siblings by noting the id comes from dogpolicies_search_places or dogpolicies_find_hotels, though the second sentence restates the first almost verbatim rather than adding scope.

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

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

'Use after dogpolicies_search_places or dogpolicies_find_hotels, which return ids' gives a clear precondition and names the producing tools. It stops short of exclusions — nothing says when to prefer dogpolicies_get_rule, dogpolicies_compare_places, or a search snippet instead of pulling the full record.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful content about what the record carries (source, quote, confidence, verified date, freshness, citation line), but says nothing about behavior on a missing/unknown id or any lookup limits. With annotations carrying the safety burden, this is adequate but not rich.

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

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

Purpose is front-loaded in the first clause, and the id-format note is a legitimate second sentence rather than filler. The middle list of returned fields is somewhat dense and partly duplicates the output schema, but each element is informative.

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 simple read-by-id tool with a full output schema and complete parameter coverage, the description supplies everything an agent needs: what it returns, what the id looks like, and where ids come from. The only gap is behavior on an unknown id, which is a minor omission given the output schema handles the return shape.

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

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

Schema description coverage is 100%, so both parameters are already documented, and the schema itself supplies a concrete id example. The description adds marginal value by explaining the id pattern 'rul_<place uid>_<kind>' and its origin in place results, but gives no guidance on response_format beyond what the enum already conveys.

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

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

States a specific verb and resource (fetch one rule by stable id) and immediately disambiguates what a 'rule' is with concrete examples (fee, leash rule, weight limit). This clearly separates it from sibling tools like dogpolicies_get_place, which returns a whole place rather than a single rule.

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

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

Usage is implied rather than stated: the note that rule ids 'appear in every place result as rule_records' tells the agent where to get an id, which implies the get_place -> get_rule workflow. However, it never explicitly says when to use this instead of get_place or get_brand_policy, and gives no exclusions or error conditions.

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?

It adds significant behavioral context not in the schema, specifically that the results include the dog rule and citation for each entry. It also details that the output is grouped by kind and sorted by distance, which is valuable runtime information.

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?

While effective, the description is quite verbose due to the large amount of routing logic and examples it needs to provide. It is appropriately sized for the complexity but could be slightly 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?

The definition is exceptionally complete. It covers both primary input methods (`place` and `near`), expected output behavior (grouped, sorted, cited), and clear boundaries for its utility compared to other sibling tools.

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

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

With 100% schema coverage, the baseline is high. The description compensates by clearly defining the usage of the `place` parameter (city, county, area) and explaining how the `types` parameter works (kinds to include; all by default).

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 is highly specific, defining the scope ('everything dog-related nearby') and the output structure (grouped by kind, sorted by distance). It clearly distinguishes this general search from specialized sibling 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?

It provides explicit branching logic for tool selection. It instructs the agent to use this tool for general inquiries while pointing to `dogpolicies_find_hotels`, `dogpolicies_plan_trip`, and `dogpolicies_search_places` for specific use cases (budget, whole trip, or one kind of place).

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety needs no restating. The description adds real behavioral context beyond that: results are aggregated in one call, pet fees are computed for the entire stay rather than per night, activities are ordered nearest first, and every item carries a citation. It does not discuss truncation or how partial matches are signalled, keeping it just short of a 5.

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?

Output scope is front-loaded in the first sentence, then inputs, then sibling alternatives, then three compact examples. Every sentence carries information; the labeled example list is easy to scan and none of the examples is redundant.

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?

Eleven parameters, a nested `near` object and an output schema are all accounted for: the description tells the agent what the response contains by section, which inputs are needed, and when a sibling is a better fit. With annotations covering safety and the output schema covering return shape, nothing an agent needs in order to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description goes beyond it by demonstrating how conversational phrasing maps onto argument values ('a weekend' to nights=2, 'two small dogs' to dogs=2, an area name substituted for a town plus stay_types). That mapping guidance is genuine value the schema cannot supply, though most individual parameters are still left to the schema.

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

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

States a specific verb and resource ('Plan a stay ... with a dog, in one call') and enumerates the three sections produced (stay with pet fee for the whole stay, dog-friendly things to do nearest-first, dog-friendly patios), each with citations. An agent can distinguish this from dogpolicies_near or dogpolicies_find_hotels 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?

Explicit routing: use dogpolicies_route_stops for the drive and dogpolicies_near for a quick list without the stay check. It also states the required inputs (town or county plus dog weight, dog count, nights, fee cap) and shows three worked request-to-argument mappings, including the non-obvious one mapping 'camping near Mammoth Lakes' to place="Mono County".

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?

Beyond the annotations, it discloses that the report goes to a person who re-reads the official source, that nothing is published automatically, and that the record does not change until verified. It also includes a privacy constraint, and none of this contradicts the mutation/non-destructive annotations.

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

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

The description is front-loaded with the trigger and behavior, then parameter guidance, then privacy. Four sentences, each carrying useful information with no filler.

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

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

An output schema exists, so return values need not be explained, and the annotations cover safety hints. The description supplies the trigger, human-review behavior, parameter guidance, and privacy constraint needed to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful usage guidance for all four parameters: place id, a sentence or two for the message, the official page if available, and an optional contact. It mostly reinforces the schema rather than adding deep parameter-specific 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?

States a specific verb and resource, 'File a correction,' and defines the triggering scenario with concrete examples such as a fee change or beach closure. No sibling tool appears to be a correction-reporting tool, so the purpose is unambiguous.

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

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

Gives a clear when-to-use condition: when a user says a rule on a record is wrong or has changed. It does not explicitly name when not to use it or list alternatives among the sibling lookup/search tools, but the context is strong enough for an agent.

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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuine behavioral context beyond that: results are weight- and pet-fee-filtered, each stop carries mile and off-road distance, routes stop at state lines, and US-101/Highway-1 overlaps are flagged via on_road.

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

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

The purpose is front-loaded in the first sentence, which is strong. However, the second and third paragraphs are dense walls of route-mile arcana (odometer origins, shared-highway stretches, per-route mileage) that largely restate the route enum and slow an agent down before it reaches the usable examples.

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 14-parameter tool with an output schema, the description supplies the one thing the schema doesn't enforce — that a starting point and direction are needed — and explains mileage conventions. Return values need no explanation given the output schema; pagination and multi-dog semantics are left to the schema.

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

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

Schema coverage is 100%, so baseline is 3, but the description meaningfully enriches several parameters: direction is explained as increasing-miles north/east, route ids are tied to specific highways and lengths, max_total_fee is scoped to the whole stay, and dog_weight_lb drives lodging eligibility. It doesn't address offset/limit pagination or the dogs count.

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

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

States a specific verb and resource — dog-friendly stops along a California or Nevada highway — and adds the ordering guarantee (driving order), the kinds of stops, and the filtering rules (dog weight, pet-fee budget). It also implicitly distinguishes itself from siblings like search_places or find_hotels by being route/mile-based rather than place-query-based.

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 five worked examples that map natural-language questions to invocations, plus the explicit rule 'Give a starting point with from_mile or near, and a direction.' It does not name the sibling alternatives (e.g. dogpolicies_near, dogpolicies_find_hotels) or state when to prefer them, so routing between tools 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?

Annotations already establish that this is a safe, read-only, idempotent, closed-world search. The description adds useful behavioral context by stating that it returns one page of places with a one-line answer, status values, verification date, and page URL, plus a pointer elsewhere for fuller detail. It does not discuss rate limits or auth, but those are less relevant for a read-only search in this 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 front-loaded with purpose, return behavior, and sibling routing, followed by concrete examples for a complex 12-parameter search tool. The examples are numerous but each demonstrates a distinct query pattern, so they earn their place.

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 12 optional parameters, rich schema, output schema, and sibling tools, the description covers what the tool does, how results look, where to go for deeper rules or hotel-specific checks, and how to translate common natural-language queries into parameters. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description still adds value by mapping natural-language queries to concrete parameter combinations such as type="beach", off_leash=true, near={lat,lon}, and by illustrating county/state/query usage.

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

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

The description states a specific verb and resource: search places (parks, beaches, trails, hotels, campgrounds, cabin resorts) in California and Nevada by name, location, and dog rules. It explicitly distinguishes itself from dogpolicies_get_place for full rules/sources and dogpolicies_find_hotels for hotel weight/budget checks.

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 direct routing guidance: use dogpolicies_get_place for full rules and sources, and dogpolicies_find_hotels to check a specific dog's weight and budget at hotels. The examples further clarify when to use this search tool for natural-language place queries.

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