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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds real context beyond that: the call returns free-night information and a price quoted in Toman, and it is a quote only, not a hold or reservation. It does not mention behavior for fully booked dates or whether the quote includes fees/taxes.

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 short sentences with zero filler, and the primary capability is front-loaded ahead of the scope boundary. Every clause carries information an agent needs.

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 does a reasonable job of describing what comes back (free nights plus a Toman quote). However, for a 5-parameter tool with 60% schema coverage, the silence on guests and discount_code leaves a noticeable gap in call correctness.

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 60%, and the description supplies no parameter-level meaning at all. The undocumented parameters, guests and discount_code, receive no explanation in either the schema or the description, so an agent must guess whether a discount code is validated, optional, or affects the returned quote.

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: checking free nights and a Toman price quote for an accommodation. It also draws a clear boundary by saying it does not book, which separates it from the reservation path via listing_url. It does not explicitly distinguish itself from sh_search_accommodations or sh_get_accommodation, so not 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?

Provides an explicit exclusion ('Does not book') and names the alternative tool (listing_url) plus where the reservation happens (shab.ir). It lacks a positive when-to-use trigger such as checking availability after finding an accommodation via search, so it falls short of full 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that it counts matching filters and does not describe return format, rate limits, or auth needs; no contradiction with 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?

A single front-loaded sentence with no redundant wording. Its brevity is efficient, though the missing detail is better assessed under contextual completeness.

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 16-parameter count tool with no output schema and no parameter descriptions, the definition is too thin. It should at least state that the return value is an integer count and clarify how the filter set maps to the sibling search tool; annotations cover safety but not query semantics.

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 are 16 parameters with 0% schema description coverage, and the description only says the filters match sh_search_accommodations. It adds no per-parameter meaning, so the agent must infer all filter semantics from the sibling tool.

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 ('Count') and resource ('stays'), and ties the filters to sh_search_accommodations, so the agent can distinguish counting from searching. It does not explicitly say the return is only a count, but the verb and title make that clear enough.

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?

Implies the tool is used when you need a count with the same filters as sh_search_accommodations, but it does not explicitly say when to prefer this over the search tool or when not to use it. The sibling reference gives useful context without full 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely useful context beyond that — that prices are denominated in Toman and that booking happens externally via listing_url on shab.ir — but says nothing about what the returned detail set contains or whether the record can be missing.

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?

Three very short sentences with the core purpose front-loaded; nothing is padded. The booking note is marginally tangential to retrieval but earns its place by telling the agent where the transaction actually happens.

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?

This is a simple single-parameter read tool whose annotations and schema are fully specified, so little is required. However, with no output schema, the description leaves "details" undefined — an agent cannot anticipate which fields come back, and the currency note is the only hint about return content.

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% for the single parameter ("Shab house id."), so the baseline is 3. The description does not add any meaning to accommodation_id, nor explain how to obtain a valid id.

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?

"Get one stay's details" pairs a specific verb (get) with a singular resource (one stay/accommodation), which distinguishes it from the sibling search, photos, and reviews tools. The wording "stay" instead of "accommodation" is slightly loose but still unambiguous in context.

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?

There is no explicit when-to-use guidance: nothing says to call this after a search returns an id, nor when to prefer it over sh_get_accommodation_photos, sh_get_accommodation_reviews, or sh_get_similar_accommodations. Only the word "one" implies single-item retrieval rather than listing.

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 open-world, so the safety profile is fully covered by structured data. The description adds only the fact that results are URLs rather than binary images; it says nothing about ordering, maximum counts, or what happens when a listing has no photos.

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 seven-word sentence with zero filler and the returned resource front-loaded. There is no wasted wording; the brevity problem is under-specification, which is penalized in other dimensions.

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 single-parameter read tool with full annotations and no output schema, the description covers the essential return type (photo URLs) but leaves the identifier's origin and the empty-result behavior unspecified. It is minimally adequate rather than complete.

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

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

The schema has one required parameter with 0% description coverage, so the description carries full responsibility for explaining accommodation_id, yet it never names the parameter or states that it must come from a search result. "For a stay" is the only indirect hint and does not compensate for the missing coverage.

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

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

"List photo URLs for a stay" gives a specific verb (list) and resource (photo URLs), which distinguishes it from siblings like sh_get_accommodation_reviews or sh_get_accommodation. It is clear what the tool returns, though "a stay" is slightly indirect phrasing for what the single parameter actually is.

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

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

The description offers no when-to-use guidance, no mention of how it differs from sh_get_accommodation (which plausibly also surfaces photos), and no note on prerequisites such as needing a valid id from sh_search_accommodations. An agent must infer everything from the name alone.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful non-annotation fact: review text is untrusted site content, which is a prompt-injection caution. It says nothing about pagination behavior, page size, or result volume, which is the remaining behavioral gap.

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 short sentences with no filler, and the core purpose is front-loaded. The brevity is close to under-specification rather than efficient, which 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?

For a simple two-parameter read tool with annotations and no output schema, the description is minimally sufficient: the agent knows what it returns and to treat the text as untrusted. It is incomplete on pagination — the page parameter's role, defaults, and limits are undocumented anywhere.

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 carries the full burden of explaining parameters, and it does not. "For a stay" loosely hints accommodation_id exists, but the page parameter and its paging semantics are never mentioned, leaving the agent to guess.

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 ("List guest reviews for a stay"), which is clearly distinct from sibling tools like sh_get_accommodation_photos or sh_get_accommodation. It does not explicitly name a sibling or draw the contrast, so it stops 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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives among the eleven sibling tools. A reader can infer reviews are fetched when reviews are wanted, but nothing in the description routes the 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without description help. The description adds only that the payload contains categories and highlighted filters; it says nothing about whether the content is static, localized, or region-locked, which matters for an open-world hint. Useful but thin beyond 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?

Seven words with no filler, so nothing is wasted, but the terseness is under-specification rather than discipline. The one clause present is not front-loaded with an action or scope statement that would orient an agent.

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

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

There is no output schema, so the description is the only source for what comes back, and "categories and highlighted filters" is too abstract to tell an agent the shape, identifiers, or how to act on the result. For a zero-parameter content-fetch tool whose only job is returning structured data, the return contract should be spelled out.

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, so there is nothing for the description to disambiguate. Per the baseline rule for a parameterless schema, this scores 4; the description does not need to compensate for any coverage gap.

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 resource (Tehran landing) and hints at its contents ("categories and highlighted filters"), but "landing" is internal jargon with no verb and no explanation of what a landing payload actually is. An agent can guess it is a Tehran-specific content block distinct from sh_search_destinations, but only by name similarity, not by any stated 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?

There is no when-to-use guidance at all: nothing says whether this is a discovery entry point, a UI-configuration payload, or a prerequisite for the search tools. Siblings like sh_list_search_filters and sh_search_destinations could plausibly cover the same need, and the description gives no rule for choosing between them.

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, open-world, non-destructive behavior, so safety is covered. The description adds nothing beyond that: it does not say how similarity is determined, how many results come back, whether ordering or ranking applies, or whether the source listing itself is excluded. For an open-world recommendation endpoint, these are meaningful gaps.

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 with no filler or repetition. Brevity is appropriate in form, though the same sentence is too thin to carry much information.

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

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

With no output schema, no parameter documentation, and a low-complexity surface, the description should explain what a 'similar stay' result looks like and the semantics of the seed id. It says neither, leaving an agent that must act on the returned list without knowing its shape or relationship to the input.

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 carry parameter meaning, and it only restates the name as 'house id'. It does not clarify that the integer is an accommodation identifier, how to obtain one (e.g., via sh_search_accommodations), or what happens with an unknown id.

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 verb ('List') and resource ('similar stays') tied to a 'house id', so the general intent is retrievable. However 'similar' is undefined and the phrasing 'stays' vs 'accommodations' leaves it ambiguous whether items are accommodations or availability records, which matters given siblings like sh_get_accommodation and sh_search_accommodations.

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?

There is no guidance on when to call this rather than sh_get_accommodation, sh_search_accommodations, or sh_check_availability. A caller cannot infer from the description whether this is for recommendation-style discovery or for expanding a known listing.

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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that the returned URL is public and intended for booking completion, but it does not disclose whether the URL expires, requires authentication, or has other behavioral constraints.

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 with no unnecessary wording. Every part of the sentence contributes to understanding the tool's output and purpose.

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

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

For a simple one-parameter read-only tool with full schema coverage and annotations, the description is largely complete: it explains what is returned and why. It could optionally clarify URL lifetime or format, but no critical information is missing for correct invocation.

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 the single parameter accommodation_id is documented as "Shab house id." The description adds no additional meaning about the parameter, so the baseline score of 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 the public shab.ir URL for completing a booking. This clearly distinguishes it from sibling tools that search or retrieve accommodation details, though it does not explicitly name an 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?

The phrase "where the user can finish booking" gives a clear usage context, implying it should be called when a booking URL is needed. However, it does not state when not to use it or name any alternative sibling 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds only the optional-filter fact, which is already visible from required=0 in the schema; it says nothing about result volume, completeness of the neighbourhood list, or how an unrecognized city is handled.

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 short sentence with the resource first and the optional modifier second; there is no filler, hedging, or redundant restatement 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 single-optional-parameter read-only list tool this is minimally sufficient, and annotations carry the safety profile. However, with no output schema the description could legitimately say what a neighbourhood record or response looks like, and it omits that entirely.

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% and the single parameter already documents that it expects a Persian city name. The description merely restates that the city acts as a filter, adding no format, casing, or matching-behavior detail beyond the schema, so the baseline of 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?

The description gives a specific verb and resource ("List neighbourhoods") plus the one scoping dimension (city filter), which is clear enough to distinguish it from siblings like sh_list_search_filters or sh_search_destinations. It does not explicitly name or contrast any sibling, so it stops short of the top mark.

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?

"Optionally filtered by city" implies the calling context (use when you want the full list or a city subset), but there is no explicit when-to-use versus when-to-use-an-alternative guidance, no exclusions, and no note on prerequisites such as needing the Persian form of the city name.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description's only added behavior context is that the output feeds another tool; it says nothing about the shape or size of the returned list.

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 with no filler. The purpose and the downstream tool appear immediately, which is exactly what an agent scanning definitions needs.

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 parameterless, read-only reference tool with annotations covering safety, this is nearly complete. The one gap is that with no output schema, the description could say more concretely what comes back (e.g., code/label pairs) and how to pass those values to sh_search_accommodations.

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, so there is nothing for the description to disambiguate. Baseline 4 applies since the empty schema leaves no semantic gap.

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 gives a specific verb ("List") and resource ("amenity codes and filter options"), and ties it to the sibling tool it supports, sh_search_accommodations. The only softness is that "filter options" is not enumerated, but an agent can still tell this apart from the other sh_* listing 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?

By naming sh_search_accommodations as the consumer, it implies this is a discovery step to run before searching. It never states that explicitly, nor does it say when not to bother calling it or whether the values are required by the search 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 read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds that prices are in Toman and that booking happens on shab.ir via listing_url, but it omits pagination behavior, result composition, default sorting, and how the many filters affect results.

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 three short sentences, front-loads the purpose, and avoids filler. It is concise, though that conciseness comes at the cost of necessary detail for a 23-parameter 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?

For a complex search tool with 23 optional parameters and no output schema, the description is far too sparse. It provides the currency and a booking pointer but omits essential context about filtering, pagination, defaults, and what the results contain.

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 23 parameters and only 35% schema description coverage, the description does not compensate: it clarifies only that prices are in Toman, leaving sort_by, page, per_page, is_instant, coordinate filters, accommodation_type, and others unexplained. The mention of listing_url is not an input parameter and does not help with 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?

The description states a specific verb and resource: searching Shab stays, which the name clarifies as accommodations. It does not differentiate this tool from siblings such as sh_search_destinations or sh_count_accommodations, but the core purpose is clear.

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?

There is no guidance on when to use this search tool versus alternatives like sh_get_similar_accommodations or sh_count_accommodations. The booking note about listing_url is a post-search action, not a condition for selecting 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 readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing behavioral on top: it does not say whether matching is fuzzy or exact, how many destinations may come back, whether results are ranked, or what happens when nothing matches.

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 with no filler or repetition. It is efficiently written, though its brevity tips into under-specification rather than maximal clarity.

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

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

For a one-parameter lookup with a fully documented schema and strong annotations, the essentials are present enough to call the tool. With no output schema, the description could have described the returned destination shape or identifiers, and it omits match/empty-result behavior, leaving a real gap for an agent assembling a search flow.

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 the schema itself gives length bounds plus concrete Persian examples (رامسر, تهران). The description contributes only the notion that the query may be a city, province, or generic place, which mildly broadens the schema's 'Persian place name' wording. Baseline 3 applies since the schema does the heavy lifting.

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 verb 'Resolve' plus the resource 'a city, province or place name' to 'destinations for search' makes it clear this is a place-name lookup that yields destination entities. It is not tautological, but it never differentiates itself from nearby siblings such as sh_list_neighbourhoods or sh_list_search_filters, so an agent must infer the boundary.

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 'for search' implies this is a precursor step before searching accommodations or applying filters, which is useful implied usage. However, the description names no alternative tool, states no when-not-to-use condition, and gives no prerequisite such as needing a destination identifier before calling sh_search_accommodations.

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