DogPolicies

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.

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 genuinely new behavior: the two-mode response shape, where the no-slug call yields every question with its slug and result count, which is what an agent needs to bootstrap the slug parameter. It does not mention rate limits or truncation, but nothing suggests those exist.

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 alias identity and client scope, then the resource with examples, then the mode behavior. Every sentence carries information, though the two example questions are somewhat redundant with each other and could have been compressed.

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 full schema coverage, the description need not explain return values, and it correctly spends its words on the alias relationship and mode switching. An agent can call this correctly from the description alone. The one residual gap is routing guidance versus non-alias siblings like search_places, which the description does not address.

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 earns an extra point by explaining the semantic contract of slug: omitting it enumerates available slugs, supplying it scopes results to one question. That is meaning the schema's "Question slug from the list" does not fully convey. limit/offset/response_format are left entirely to the schema, which is adequate.

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 (browse ready-made answered question lists, listing places per question) and identifies itself as an alias of dogpolicies_browse_answers, so an agent can map it to the canonical tool. The parenthetical examples of question types make the resource concrete. It stops short of a fully self-contained identity because the real semantics live in the named sibling.

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?

"Alias of dogpolicies_browse_answers, kept for older clients" gives a clear selection rule against the sibling: use the canonical name for new work, this one for legacy clients. It also covers the two calling modes (no slug = list all questions with slugs and counts; with slug = return that question's places). It does not distinguish this from search_places or near, which also answer place questions.

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 the safety profile is covered. The description adds real behavioral detail beyond that: result ordering (newest first), the enumerated verification event types, and the legacy/alias nature of the endpoint. It doesn't say anything about result volume or how pagination interacts with the offset/limit pair beyond the 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-loads the alias identity and the core operation, then usage, then the alternative, then an example — a sensible order with no padding. The example is compact and earns its place, though the sentence about answering a change question and re-checking an itinerary is mildly redundant with itself.

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 full annotation coverage, the description needn't explain return values, and it supplies purpose, scope, alternatives, and an example. The only soft spot is that it never explicitly states whether new callers should prefer dogpolicies_changes_near over this alias — it's only implied by "kept for older clients".

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 every parameter including the place/near alternative and the radius-ignored-for-areas rule. The description's example ("What changed near Monterey since September?" -> place="Monterey", since="2026-09-01") clarifies how natural language maps to the place/since pair, but the restated outcome list duplicates the enum and adds no new meaning. Baseline 3 is right.

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 by identifying itself as an alias of dogpolicies_changes_near, then states the specific resource (verification events across five outcome types) and scope (within a radius of a town, county, or point, newest first). An agent can distinguish it from dogpolicies_changes_since, which the description explicitly names as the anywhere/everywhere variant.

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

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

Gives concrete triggering scenarios ("has anything changed around Tahoe since my last trip?", re-checking a saved itinerary) and names the alternative tool plus the condition that selects it ("Use dogpolicies_changes_since for everything everywhere"). The "kept for older clients" note also signals that new clients should prefer the canonical sibling.

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 and idempotency, and the description adds useful behavior beyond them: whole-data-set scope, newest-first ordering, alias compatibility, and the fields included in each entry. This is enough for an agent to understand how the feed behaves without inferring from annotations alone.

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 alias status is front-loaded, followed by a dense but useful sentence covering scope, ordering, purpose, and entry contents. There is no wasted 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?

Given rich annotations, full schema coverage, and an output schema, the description supplies everything the agent additionally needs: alias context, global scope, polling suitability, ordering, and event contents.

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 parameter meanings are already documented in the schema. The description reinforces the since-date scope and names the outcome values, but it does not add syntax or filtering semantics beyond what the schema provides, so 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 resource: it returns everything that changed in the whole data set since a date, including verification events and rule changes. It also distinguishes itself from its canonical sibling by explicitly calling itself an alias of dogpolicies_changes_since kept for older clients.

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 cheaply instead of re-reading every record, and older clients can use it as an alias. It does not explicitly say when to prefer dogpolicies_changes_since or dogrulebook_changes_near, but the alias framing provides strong routing 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?

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds useful output-shape context (one row per fact, one column per place, citation per place) and compares confidence, freshness and provenance, going beyond what annotations provide.

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 alias caveat is front-loaded, followed by the scope and then usage. The fact enumeration is slightly list-heavy, but every part earns its place and there's no preamble 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?

It covers when to call it, what it returns conceptually, and the alias relationship; an output schema exists so return values need no further explanation. It could more explicitly direct new clients to dogpolicies_compare_places, but 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 description coverage is 100% and both parameters are documented there, including the 2–6 bound on ids and the markdown/json enum. The description only restates the id range and adds an illustrative example, which is marginal added value, so 3 is the correct baseline.

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

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

The description names the specific verb and resource ('compare two to six places') and immediately identifies itself as an alias of dogpolicies_compare_places, so an agent knows exactly what it does and how it relates to the canonical sibling. It also enumerates the compared facts (dogs allowed, leash rule, pet fee, weight limit, etc.), which further pins down 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?

It states a concrete trigger ('Use after a search returned candidates and the user asks "which one?"') and where ids come from ('any search result'), with a worked example. It doesn't say when to prefer the canonical dogpolicies_compare_places instead, which is a minor gap for an alias 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 cover the safety profile (readOnly, non-destructive, idempotent). The description adds valuable behavioral detail: results are grouped into match/possible/excluded, matches are sorted by cheapest pet fee, and fee arithmetic is shown per result. It does not discuss pagination or output format details, but the output schema likely covers those.

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 alias note is front-loaded, followed by a clear purpose statement, then reasoning about result categories and sorting, then examples. Every sentence is useful, though the example block is somewhat verbose; overall it is well-structured for a complex tool.

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 15 parameters, nested objects, four enums, an output schema, and full annotation coverage, the description provides enough context to call the tool correctly. It explains the search domain, what each result category means, sorting, and gives worked examples. It could be slightly more explicit about when to prefer the canonical sibling, but it is otherwise complete.

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

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

Schema coverage is 100%, so the schema already documents every parameter. The description goes beyond the schema by providing natural-language examples that map real questions to specific parameter combinations (county, near, dogs, nights, query, state, dog_weight_lb, max_total_fee), which helps an agent translate intent into arguments.

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 (find) and resource (hotels/motels) for a specific dog, with scope (California and Nevada) and fee estimation. It also explicitly names the canonical sibling it aliases (dogpolicies_find_hotels), so an agent can tell it is a duplicate for older clients.

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 alias note ('kept for older clients') gives clear context that new callers should prefer dogpolicies_find_hotels, and four concrete query-to-parameter examples demonstrate invocation patterns. It stops short of an explicit 'use X instead' directive or exclusion rules, but the intent is clear.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral content by enumerating the policy fields returned and noting California/Nevada coverage counts, which tells an agent what a successful call yields. It stops short of addressing unknown-brand errors or fallback behavior.

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 sentences plus a compact brand roster; the alias/scope statement is front-loaded before the content detail. The brand list is long but earns its place as a valid-value enumeration, and the example sentence is short. Slight redundancy between the brand roster and the examples keeps it from a 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 an output schema present and full annotation coverage, the description need not explain return shape, and it sensibly sticks to naming the covered fields and enumerating valid brand inputs. What is missing is minor: behavior when an unlisted brand is passed, and whether the alias differs at all from the canonical tool in output or freshness.

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 would be 3, but the description goes beyond the schema's bare 'Brand id or name' by listing every supported brand with its id slug and giving worked examples ('red-roof', 'Kimpton') that demonstrate slug-vs-display-name and casing tolerance. That is real added meaning the schema does not carry.

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 (a hotel chain's published pet policy) and enumerates exactly what fields it covers: pets per room, weight limit, fee, rules, exceptions, and state-level property counts. It also identifies itself explicitly as the alias of dogpolicies_get_brand_policy, which lets an agent tell it apart from the canonical sibling 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?

The phrase 'Alias of dogpolicies_get_brand_policy, kept for older clients' implicitly routes new callers to the canonical tool and explains why this one exists. There is no explicit 'use X instead when Y' statement or exclusion list, so the guidance is clear but inferential rather than directive.

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 without the description. The description's additions are about return payload composition (rules plus sources with capture dates and quotes), not about behavior such as freshness, size, or failure on unknown ids — and since an output schema exists, that content is largely redundant.

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?

Roughly half the description is a near-verbatim restatement of the preceding sentence — 'The full record for one place... every dog rule with its display text, the rules list, and each source with its URL, publisher, capture date and quote' is then repeated as '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.' The alias notice and the usage sentence are front-loaded and well placed, but the duplication wastes the reader's attention.

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 two-parameter, read-only, idempotent lookup with 100% schema coverage and an output schema, the description supplies everything essential: what the record contains, where the id comes from, and an example. Only the alias relationship's operational consequence (should new clients avoid it?) is left implicit.

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 in the schema with an example id ('fort-funston'). The description contributes only a second example id ('carmel-beach') and never mentions the response_format enum, so it adds no meaning beyond what the schema already provides. Baseline 3 applies.

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 (retrieve the full record) and resource (one place, by id) and enumerates the payload: dog rules with display text, the rules list, and sources with URL, publisher, capture date and quote. It also self-identifies as an alias of dogpolicies_get_place, which lets an agent place it in the family. Clarity is slightly undercut because the second sentence restates the first with drifted wording ('every dog rule' vs 'every fact'), muddying whether they describe the same thing.

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 it after dogpolicies_search_places or dogpolicies_find_hotels, which supply the required id, and gives a concrete example invocation. 'Kept for older clients' signals that new callers should prefer the canonical dogpolicies_get_place, though it never states that preference outright or says when not to use this alias.

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 fully covered. The description adds no behavior beyond that — no note on whether the id lookup is cached, what happens on a missing/stale rule, or error semantics for a malformed id. It does clarify the alias relationship, which is real added 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?

Two sentences with the alias/legacy note front-loaded, followed by the payload inventory. The long middle clause listing returned fields is dense but earns its place by telling the caller what they get back in one lookup. Slight crowding, no 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?

For a two-parameter lookup with an output schema, the description plus annotations plus schema cover what it does, how to get an id, and the alias relationship. Missing only failure/staleness behavior, which matters somewhat for a 'freshness'-bearing record but is minor given the rich 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 coverage is 100%, so baseline is 3, but the description earns above baseline by explaining the id's structure ('rul_<place uid>_<kind>') and, crucially, where to obtain ids ('appear in every place result as rule_records'). That provenance is not in the schema and directly enables correct invocation.

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 ('one rule ... by its stable id') and enumerates the payload (value, source, quote, confidence, verification date, freshness, citation line). It also names the canonical sibling it aliases, so an agent can place it immediately in the tool family.

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?

'Alias of dogpolicies_get_rule, kept for older clients' explains why this tool exists and effectively routes new callers to the canonical tool. It stops short of an explicit 'prefer dogpolicies_get_rule unless you need legacy compatibility' instruction, so the preference is implied rather than stated.

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, closed-world, non-destructive, so the safety profile needs no restating. The description adds useful behavioral detail beyond them: results are grouped by kind, sorted by distance, and each carries a dog rule plus citation. It does not discuss result volume, pagination, or what happens when place and near are both supplied.

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 alias identity and the core outcome, then the routing guidance, then compact examples. Slightly long due to the enumerated list of place kinds and three examples, but every element carries information an agent would otherwise have to infer.

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-structure explanation is unnecessary; the description nonetheless tells the agent results come grouped and distance-sorted with rules and citations. Parameters are fully schema-documented, safety is annotation-covered, and routing plus examples complete the picture for a 7-param tool.

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

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

Schema coverage is 100%, so baseline is 3. The description goes modestly beyond by clarifying that a town or county name alone suffices (no coordinates needed) and by demonstrating realistic combinations of place/near/types/radius_miles in examples, which helps an agent compose calls even though it does not re-specify bounds or defaults.

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 the specific verb+resource (returns dog-related places near a town/county/point), names the kinds grouped and sorted by distance with rules and citations, and explicitly identifies itself as the alias of dogpolicies_near kept for older clients. An agent can distinguish it from dogpolicies_search_places or 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?

Explicitly says it is "the one call to make when a user names a place and asks 'what can I do with my dog there?'" and routes three sibling cases (find_hotels for weight/budget, plan_trip for a whole stay, search_places for one kind with filters). Three worked examples further pin down when each parameter combination applies.

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=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it is a compatibility alias for older clients, it returns three distinct sections in one call, it computes the pet fee for the whole stay, and every item carries a citation. It does not discuss result caps, cost, or rate limits, so it stops 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?

The alias/deprecation note is front-loaded, followed by a one-sentence scope statement, the required inputs, the alternative tools, and compact examples. Every sentence earns its place and nothing is repeated from the schema.

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

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

For an 11-parameter tool with a nested object, an output schema, and full annotations, the description supplies what structured fields cannot: the alias relationship, the three-section return shape, and sibling routing. Nothing needed to select or invoke 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 description coverage is 100%, so the schema fully documents all 11 parameters and the baseline is 3. The description highlights the essentials (place/county, dog weight, dog count, nights, max total pet fee) and the examples show the place/dogs/nights/max_total_fee and stay_types mapping, but it says nothing about near, radius_miles, per_section, include_possible, or response_format beyond what the schema provides.

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?

Names the specific operation (plan a trip with a dog) and enumerates the three result sections it returns – stays with computed pet fees, dog-friendly activities nearest-first, and dog-friendly patios – each with citations. It also declares itself as an alias of dogpolicies_plan_trip for older clients, so an agent can tell exactly what it does and that it duplicates a sibling.

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 agent: 'Use dogpolicies_route_stops for the drive there and dogpolicies_near for a quick list without the stay check', which is a direct when-not-to-use statement naming alternatives. The three worked examples map natural-language requests to concrete argument sets, removing ambiguity about typical invocation.

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 cover the safety profile (non-read-only, non-destructive, open-world, non-idempotent), and the description adds substantial context beyond them: the report is human-reviewed, nothing is published automatically, and the record is unchanged until verified. It also adds a privacy constraint about not sending personal details, which is genuine behavioral guidance not captured anywhere in the structured fields.

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 alias/disambiguation note, then behavior, then input expectations, then the privacy caveat; each sentence carries purpose. Slightly longer than strictly necessary but no filler sentences.

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 no explanation; the description covers what the tool does, what happens after submission (human review, no auto-publish), and what inputs to gather. Complete for an agent to invoke confidently.

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 adds usage framing: 'give the place id, what is wrong in a sentence or two, and the official page the user saw, if any,' clarifying that source_url is optional and message is free-form user wording. This meaningfully supplements 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 action (file a correction), identifies it as an alias of dogpolicies_report_correction with a compatibility rationale, and enumerates concrete trigger cases (fee increase, beach closure, pet limit change). An agent can distinguish it from sibling read tools like get_rule or search_places immediately.

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 trigger condition: use when a user reports a rule is wrong or has changed, with three illustrative examples. It does not explicitly name an alternative tool or state when NOT to use it, keeping it just 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 declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely behavioral context the annotations cannot: routes are single-state and terminate at the state line, stops are filtered against dog weight and the pet-fee budget, and California vs. Nevada mile conventions differ. It does not discuss result volume or what happens when a start point is off-route, which is why this is a 4 rather than 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?

Purpose and constraints are front-loaded and the worked examples earn their space. But the 'Routes covered:' inventory largely restates the route enum already present in the schema, adding only mile lengths, and the prose paragraph above it covers much of the same ground — roughly a third of the text is redundant with structured data.

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 a nested `near` object and an output schema, this description supplies what structured data cannot: the mile/direction model, per-route jurisdictions, and the filtering semantics for weight and fees. Nothing an agent needs in order to construct a correct call is missing.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description goes well beyond it: it explains that direction means increasing miles (north/east), that California miles follow the Caltrans odometer from named origins while Nevada counts mileposts from the state line, and that on_road marks Highway 1 stretches running on US-101. That is interpretation an agent cannot derive from the schema alone.

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

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

The description opens with a specific verb+resource ('Dog-friendly stops along a California or Nevada highway, in driving order') and enumerates exactly which kinds of stops are included, plus the alias relationship to dogpolicies_route_stops. An agent can tell this apart from dogpolicies_near or dogpolicies_plan_trip without opening any schema.

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

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

It names the alias condition ('kept for older clients') and states a hard usage requirement: 'Give a starting point with from_mile or near, and a direction.' Five worked examples map natural-language requests to concrete argument sets. It does not, however, say when to prefer this over dogpolicies_plan_trip or dogpolicies_near, which the sibling list makes plausible 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?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real behavior beyond that: results are one page, each hit carries a one-line answer, a status in {yes, yes_restricted, no, varies}, a verification date and a page URL. It does not mention freshness cadence or what an empty result means, but the added context is substantive.

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 prose is front-loaded and tight, but eight example bullets is more than needed — several (San Diego beaches, Tahoe beaches, Las Vegas parks) demonstrate essentially the same filter-and-geography pattern, so the example block is padded relative to the information it conveys.

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 restate return fields, yet it still summarizes the answer/status/verification shape usefully; params are fully documented in-schema and annotations cover the safety profile. The only gap is that it never says whether this alias and the canonical tool behave identically or which to prefer.

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 worked examples add genuine meaning beyond the schema by showing how a natural-language ask maps onto parameter combinations (type=beach + off_leash=true + near, type=campground + county + dogs_allowed). It does not explain interplay like query vs area precedence or how offset/limit combine with near-distance sorting.

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 by naming the canonical tool it aliases and then states a specific verb+resource: searching parks, beaches, trails, hotels, campgrounds and cabin resorts across CA/NV by name, location and dog rules. It also distinguishes itself from dogpolicies_get_place and dogpolicies_find_hotels in the same paragraph, so an agent can route without opening schemas.

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 adjacent intents: dogpolicies_get_place for full rules/sources, dogpolicies_find_hotels for a specific dog's weight/budget. The 'alias ... kept for older clients' framing implies the canonical name is preferred but never states 'prefer dogpolicies_search_places', leaving a small ambiguity when both names are in scope.

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