The Edit by Chase (Quick Travel Guides)

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the figures are medians aggregated across all of a city's Edit hotels on Chase Travel, and the response includes summary cheapest/priciest months. It omits caveats such as currency or the time window covered.

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?

One sentence, front-loaded with the resource and scope, with the returned highlights (cheapest/priciest months) tacked on efficiently. 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?

With no output schema, the description correctly carries the burden of describing returns: month-by-month medians plus cheapest/priciest months. For a one-parameter read-only tool this is nearly sufficient; minor gaps are the absence of currency/units and the date range the medians are computed over.

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?

There is a single 'city' parameter with 100% schema description coverage, so the schema already carries the parameter semantics; baseline 3 applies. The description confirms the aggregation is per-city but adds no format or matching guidance beyond the schema's 'City name, e.g. Tokyo'.

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 resource and scope: month-by-month median Chase Travel nightly rates for a city's Edit hotels, plus the cheapest and priciest months. That clearly separates it from search_edit_hotels and get_edit_hotel, which deal with individual hotels rather than month-level pricing. It is a noun phrase rather than a verb+resource action statement, which keeps it just short of a 5.

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 content ('cheapest and priciest months'), so an agent can infer this is the tool for seasonal price comparison. However, no explicit when-to-use, when-not-to-use, or alternative (e.g. search_edit_hotels for actual availability) is 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 cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lowered. The description usefully adds that results are restricted to restaurants where the dining credit works, but says nothing about result count, ordering, or the meaning of the limit cap in practice.

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?

One sentence, no filler, with the resource definition front-loaded and the two lookup modes trailing. The parenthetical explaining the dining credit is the only aside and it earns its place by clarifying the filter's meaning.

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

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

With no output schema and four undocumented parameters, the description should say more about what is returned and what happens when the tool is called with no arguments. It covers the core intent but leaves the agent guessing about result shape and default behavior.

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 0%, so the description must compensate. It implicitly maps lat/lng to the 'nearest to a point' mode and city to the 'by city' mode, covering three of four parameters, but never mentions limit (max 20) or gives any format/coordinate-system detail.

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 a precisely scoped resource: Sapphire Reserve Exclusive Tables restaurants where the $300/yr dining credit applies. This is distinguishable from siblings like sapphire_reserve_credits (credit info) and search_edit_hotels (hotels) 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?

The phrase 'by city, or nearest to a point' implies the two supported lookup modes but never states when to pick one over the other, nor what happens if no parameters are supplied (required parameters: 0). Usage is inferable but not explicit, and no alternatives are named.

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 and openWorldHint=false, so the safety profile is covered. The description goes beyond that by enumerating what the call actually returns (typical rate, monthly medians, cheapest months, double-credit status, benefits, nearby dining-credit restaurants), which is genuinely useful given there is no output schema. It adds nothing about auth or rate limits, but for a read-only lookup that is minor.

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?

A single front-loaded sentence: the tool's purpose and keyed identifier come first, then the return payload. No filler and no repetition of the title.

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 one-param read-only lookup with no output schema, the description covers the essentials: what it returns and where the ID comes from. It stops short of noting any coverage limits (e.g., whether 'within 3 km' data is always present or what happens for hotels with no Edit benefits), which would fully close the loop.

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 one parameter and 100% schema coverage, the baseline is 3. The description adds provenance the schema lacks: the ID is a Chase hotel ID obtained from search_edit_hotels, which tells the agent where to source a valid value rather than guessing.

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 ('Details for one Edit hotel') and scopes it by a named identifier. It also points to the sibling tool (search_edit_hotels) that produces that ID, so an agent can place it relative to siblings 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?

The parenthetical '(from search_edit_hotels)' tells the agent this is the follow-up detail call after a search, which is clear usage context. It does not, however, state any when-not condition or alternative for retrieving the same data another way.

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 and openWorldHint=false, so the safe, non-networked read profile is covered. The description usefully adds what the payload contains (per-credit value, mechanics, activation, guide links), though it says nothing about curation/freshness or whether the data is static.

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?

A single front-loaded sentence that spends its words on content scope rather than restating the name. The colon-list construction is compact and readable, though the fragmentary phrasing without a leading verb is slightly informal.

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 no-parameter, no-output-schema reference tool, the description covers the necessary ground: it tells the agent this returns credit values, mechanics, activation status, and external guide links, so the agent knows the response covers all the card's credits in one call.

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

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

The tool takes zero parameters, which is the baseline 4 case; there are no parameter meanings to document and the description does not misrepresent any input.

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?

Clearly states the resource (Chase Sapphire Reserve's credits) and enumerates what the response covers: value, mechanics, activation requirement, plus links to guides. It does not compare itself to any sibling, but the resource is unambiguous and an agent can distinguish it from edit/search tools.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative is named. There is an obvious adjacency with the sibling find_dining_credit_restaurants (a specific credit's redemption), yet nothing in the description explains how this general reference tool relates to that lookup 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?

With annotations limited to readOnlyHint and openWorldHint, the description usefully adds the result cap (20 per page, 5 pages) and the fact that rows carry a typical Chase Travel nightly rate and the double-credit flag. It does not disclose filter combination logic, ranking defaults, or rate-freshness caveats.

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 sentences, front-loaded with the primary action and scope, with the result constraint tacked on where it belongs. No filler, though the parenthetical collection branding is slightly verbose.

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 10-parameter, zero-required search tool with no output schema, the description covers what the results contain and how many come back, which is the right compensation. It still omits how filters combine and what 'typical nightly rate' means in practice.

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 70%, so structured fields already carry most semantics. The description reinforces the 'double credit' and 'nightly rate' concepts, but adds no syntax or meaning for city/state/country/query/sort that the schema does not already give.

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

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

States a specific verb (search) and resource (hotels in The Edit by Chase Travel) and names the scope of the collection, plus what the results carry (nightly rate, 2026 double credit). It is clearly distinguishable from get_edit_hotel (detail fetch) and find_dining_credit_restaurants, though it never names a sibling 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?

No when-to-use guidance and no routing to alternatives, despite four siblings that overlap conceptually (get_edit_hotel for detail, sapphire_reserve_credits for credit questions). The only real guidance is the pagination note, which is about output shape, not tool selection.

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