Read-only Asian hotel search and guides with canonical sources and non-live rates.
Scored across 6 tools
find_hotels, search, and get_destination_guide all return published content and could be confused at a glance, but descriptions clarify their distinct targets (hotel records vs. guide text vs. destination-specific guides). compare_hotels, fetch, and get_booking_links are each clearly scoped to a unique action.
Four tools follow a clean verb_noun pattern (compare_hotels, find_hotels, get_booking_links, get_destination_guide). The bare verbs fetch and search are minor deviations but still readable and unambiguous.
Six tools is well-scoped for a read-only hotel guide server, with each tool mapping to a distinct user need (discover, compare, retrieve guides, retrieve links, fetch sources). No redundant or filler tools.
The surface covers search, discovery, comparison, guide retrieval, and booking links, which is a coherent read-only lifecycle. There is no explicit single-hotel detail tool (fetch only retrieves documents), a minor gap agents can work around via find_hotels.
Compare 2–5 known hotel IDs using sourced published fields. No inferred winner or comparable live prices.
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_ids | Yes |
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 behavioral context by disclaiming outputs: no inferred winner and no comparable live prices, which tells the agent the result is a static field-by-field comparison rather than a ranked or priced one. It stops short of describing return shape, but the negative guarantees are valuable.
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, zero filler, with the core action and scope front-loaded and the output limitations immediately after. Every clause earns its 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?
With no output schema and rich annotations, the description correctly focuses on what will and won't be returned, which is the main ambiguity for a comparison tool. It is slightly incomplete in not naming which published fields are returned, but it covers enough 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 0%, so the description carries the burden for the single parameter. It adds the key semantic the schema cannot express: values must be known/valid hotel IDs (not names or free text) and the count is 2–5, matching the min/maxItems constraints. This meaningfully reduces misuse risk even though it does not describe the item format beyond that.
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 (compare) and resource (hotels) plus the scope constraint (2–5 known hotel IDs), which separates it from find_hotels/search that discover IDs. 'Sourced published fields' is vague about which fields, so the resource is clear but the comparison payload isn't fully pinned down. No sibling is named, but the 'known IDs' framing implies the distinction.
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?
'Known hotel IDs' implies the caller must first obtain IDs via find_hotels or search, which is useful implied usage. However, it never states this as a precondition and never names the sibling to use for discovery, nor does it say when comparison is inappropriate. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a known document ID or exact canonical URL returned by search. No arbitrary URLs are fetched.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false. The description reinforces the closed-world constraint with "No arbitrary URLs are fetched," which adds concrete specificity beyond the flag, but reveals nothing further about return format or failure 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 short sentences, zero waste, with the accepted-input scope front-loaded and the negative constraint immediately following.
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 read tool with full annotation coverage, the definition supplies the precondition, the accepted inputs, and the URL restriction. Only the return shape is unaddressed, which is a minor gap given no 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 0%, so the description carries the burden for the single 'id' parameter. It usefully explains that the value is either a known document ID or an exact canonical URL, which is meaningful semantics the bare string schema does not convey.
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 (fetch) and resource (a known document ID or exact canonical URL), which is distinct from the exploratory sibling 'search'. It implies the discovery-vs-retrieval distinction without fully naming search as the counterpart.
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?
"returned by search" establishes the precondition that an ID/URL must already be known, and the second sentence rules out arbitrary URLs. It stops short of an explicit "if you don't have an ID yet, call search first" routing statement, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find published hotel records by exact destination name/slug, optional text and category. No live availability or price filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| category | No | ||
| destination | No |
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). The description adds traits those annotations cannot express: results are limited to *published* records, destination matching is exact rather than fuzzy, and availability/price data is deliberately out of scope. That is meaningful behavioral context beyond 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?
Two tight sentences with the core scope constraint front-loaded and the negative scope stated second. No filler, though the negative clause could have been tied to a concrete alternative sibling.
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 read-only lookup tool with annotations and no output schema, the description covers search scope well but says nothing about what a result contains (fields, ranking, pagination) and omits the limit parameter. Adequate, but an agent still has gaps before calling it.
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. It partially does: destination is an exact name/slug, query is free text, category is a filter — but the 'limit' parameter (default 10, max 20) is never addressed, and matching semantics (exact vs. fuzzy) are only stated for destination.
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 published hotel records') and constrains the lookup to 'exact destination name/slug'. It does not name or contrast itself with siblings like search, compare_hotels, or get_booking_links, so differentiation is only implied.
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 clause 'No live availability or price filters' signals the tool's scope boundary and implicitly routes availability/pricing needs elsewhere, but no alternative tool is named and no prerequisites are given. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return exact published affiliate and official URLs with disclosure. Does not visit links or book rooms.
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that links are 'published' and that it performs no link visiting or booking, which partially overlaps openWorldHint=false, so the added value is modest.
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 tight sentences, both front-loaded with the return content first and the non-behavior second. Nothing is wasted, though it is extremely terse given the undocumented parameter.
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-parameter read tool with no output schema, the description conveys the return content (affiliate and official URLs) but omits the parameter's meaning and leaves the vague 'with disclosure' unexplained. 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?
There is one required parameter, hotel_id, with 0% schema description coverage, and the description never mentions it or its expected form. It fails to compensate for the schema gap, so the agent learns nothing about the identifier beyond the property name.
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 — 'Return exact published affiliate and official URLs' — and the negative clause ('Does not ... book rooms') clarifies its scope. It doesn't name a sibling, but the purpose is unambiguous and distinguishable from the generically named fetch/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?
It implicitly frames usage by stating what it does NOT do ('Does not visit links or book rooms'), which hints the agent should use a different tool to follow or open URLs. However, it never states when to call this tool or names an alternative such as fetch, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find published guide documents for a known destination. Fetch returned IDs for full source text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| destination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that only published docs are returned and that the result is IDs rather than full text – a useful output-shape hint. It does not cover pagination, rate limits, or what happens when no destination 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?
Two short sentences, front-loaded with the core action and followed by the essential follow-up step. Every clause carries information; 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?
The tool is simple (2 params, no output schema, no nesting) and annotations cover the safety profile, so the bar is modest. The description gives the return type (IDs) and a next step, but leaves parameter semantics and no-result behavior undocumented.
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 0%, so both parameters lack any documentation in the schema. The description mentions the destination implicitly but provides no format/expectation details (e.g. city vs country name), and says nothing about the 'limit' parameter. With a low-coverage schema the description should compensate but 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?
States a specific verb (find) and resource (published guide documents) scoped to a 'known destination', which distinguishes it from the sibling search tool. No explicit sibling differentiation by name, but the 'published guide documents' framing separates it from compare_hotels/find_hotels clearly 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 usage context ('for a known destination') and hints that returned IDs must be fetched for full text, giving an agent a workflow cue. However, it does not name when to use this versus the 'search' sibling, nor state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published English hotel guides. Returns document IDs and canonical source URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the return payload (document IDs and canonical source URLs), which is useful, but says nothing about result ordering, pagination beyond the limit param, or rate limits.
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 the resource scope front-loaded and the return contract second. No filler, no repetition of the schema, nothing that fails to earn its 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?
With no output schema, the description correctly steps in to name the return fields, and the strong annotations remove the need to discuss safety. However, for a search tool with two wholly undocumented parameters it stops short of explaining query interpretation or how limit shapes results, so it is only minimally 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 description coverage is 0% and the description documents neither parameter. Only 'English' hints at query semantics; the limit parameter's default, max of 20, and effect on result count are never explained anywhere in prose, leaving the schema's bare types to carry both parameters.
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 (published English hotel guides) plus the shape of the result (document IDs, canonical source URLs). It is clear enough to act on, but it never distinguishes itself from the sibling find_hotels or get_destination_guide, both of which plausibly overlap with 'hotel guides'.
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 statement of when to use this tool versus compare_hotels, find_hotels, or get_destination_guide, and no exclusions or prerequisites. Usage is only implied by the word 'Search'; an agent must guess whether it wants guide documents or hotels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_hotelsfetchfind_hotelsget_booking_linksget_destination_guidesearchLive hotel prices worldwide, sourced destination guides, prebooking. No key needed for reads.
Search hotels and get hotel details. Search-only; book on hotely.travel.
Search and book 3M+ hotels in 200+ countries. Agents pay per reservation in USDC on Base over x402. Hosted, no auth.
Live hotel rates worldwide: search stays, property detail, all-in room prices, human phone desk.
Add one secure layer between your agents and this server.
