travel_mcp

by Skyline-9

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation3/5
Several tools are direct aliases (e.g., search_restaurants vs search_tabelog, get_restaurant_details vs get_tabelog_restaurant_details, suggest_dining vs suggest_tabelog, check_restaurant_reservation vs check_tabelog_reservation, get_transit_and_directions vs get_hotel_distance_and_transit) that create redundancy and potential misselection. Though descriptions clarify they are equivalent, the presence of both forms is confusing.
Naming Consistency2/5
Naming is inconsistent: most tools follow a verb_noun pattern (get_, search_, suggest_), but deviations like 'search_tabelog', 'get_tabelog_restaurant_details', and 'get_hotel_distance_and_transit' break the pattern. Tools with provider-specific shortcuts don't align with the general naming convention, making the set feel ad hoc.
Tool Count3/5
At 20 tools, the server borders on heavy. The count is inflated by multiple alias/shortcut tools that duplicate existing functionality (e.g., search_restaurants vs search_tabelog). The effective unique tool count is lower, but the redundancy suggests the set could be streamlined.
Completeness3/5
The server covers discovery and research well: hotel search, price comparison, details, rooms, reviews, FAQs, restaurant search/details, reservation availability, transit, and place reviews. However, it lacks actual booking or reservation creation (only checks availability), and no itinerary management or broader travel lifecycle features, leaving notable gaps for end-to-end travel planning.
Average 3.8/5 across 20 of 20 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover the safety profile. The description adds no extra behavioral context such as network dependencies, approximations, or side effects. It does not contradict the annotations, but the description contributes minimal additional transparency beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceedingly concise: two sentences, zero redundancy. It front-loads the purpose and then notes the alias. Every word earns its place, and it is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which means return format need not be described), the tool has 5 parameters with no schema descriptions. The description omits critical parameter semantics and does not point the user to the alias for more details. An agent would likely need to inspect the alias tool or guess, so the definition is incomplete for self-contained use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameter meanings. It hints that 'origin' is likely a hotel and 'destination' is a target, which is useful, but it does not clarify the format of values, the role of 'country', 'provider', or 'travel_mode', or acceptable values. This leaves agents guessing on many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Calculate'), resource ('travel distance and transit options'), and context ('between a hotel and a target destination'), which is clear and unambiguous. It distinguishes itself from sibling tools by naming the hotel use-case, though it does not explicitly contrast with get_transit_and_directions beyond being an alias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the alias get_transit_and_directions or other navigation tools. The alias note implies interchangeability but does not explain any preference or conditional use cases. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, signaling a safe, non-mutating operation. The description adds value by specifying the content: verified traveler reviews, category ratings, and comments, which is beyond the annotations. However, it does not disclose pagination behavior or that results vary by provider, leaving some behavioral aspects unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and resource. It has no fluff or redundant wording. While it could mention provider handling or pagination, the structure is efficient and appropriate for a simple fetch tool, though not maximally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and strong annotations, the description covers the core function adequately. However, it does not address potential confusion with the sibling 'get_place_reviews' or mention that results are provider-specific. Pagination is implied by schema parameters but not surfaced in the description. For a straightforward fetch tool, this is minimally complete but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented with types, defaults, and purpose. The description adds no additional parameter-specific semantics; it merely highlights what the tool returns. The baseline of 3 applies because the schema carries the full parameter burden and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the specific resource 'verified traveler reviews' with added detail on category ratings and comments. It is specific and distinct from generic review fetchers, but does not explicitly differentiate from the sibling 'get_place_reviews', which could be a similar tool. The main purpose is clear, but sibling differentiation is omitted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it targets hotel reviews specifically or when to prefer it over 'get_place_reviews'. There is no mention of provider specifics or conditions for use. The agent is left to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint, idempotentHint, and openWorldHint, indicating safe and repeatable calls. The description adds value by enumerating the returned data fields, giving agents an idea of expected output. It does not disclose rate limits, error handling, or any operational constraints, but given the annotations cover safety, the added context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists the key data categories without filler. It effectively conveys the tool's scope in one line, though it could be slightly more structured with bullet points. Still, it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and annotations that cover read-only and idempotent behavior, the description is adequately informative for a detail-fetching tool. However, it does not mention potential errors, prerequisites (e.g., needing a valid restaurant identifier), or the provider-specific behavior implied by the 'provider' parameter. These gaps are minor but noticeable when the agent must decide between similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema itself. The description mentions the types of data returned, which indirectly clarifies the purpose of restaurant_id_or_url, but it adds no extra syntax or format details beyond the schema. The baseline of 3 is appropriate 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool fetches a full restaurant profile with specific data fields (award history, address, coordinates, budget, amenities), making the purpose clear. It differentiates from search tools by implying it retrieves details for a known restaurant. However, it does not distinguish itself from the sibling get_tabelog_restaurant_details, which may cause ambiguity for an agent deciding between the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_tabelog_restaurant_details or search_restaurants. The description does not mention typical use cases, exclusions, or conditions under which a different tool would be more appropriate. An agent would need to infer usage from the parameter schema and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety and side-effect profile. The description adds minor behavioral context with 'live' and 'upcoming', implying real-time data and future focus, but it does not elaborate on response format or limitations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant phrasing. It front-loads the action and resource clearly, making it easy to parse without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema and annotations cover operational details, the description omits any reference to the closely related sibling 'check_tabelog_reservation', creating ambiguity about when each should be used. This is a notable contextual gap for an otherwise simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides full descriptions for both parameters (100% coverage), so the description adds no additional meaning beyond what the schema already offers. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action ('check') and resource (restaurant booking vacancy and available dates). It is specific enough to understand its function, though it does not distinguish itself from the sibling tool 'check_tabelog_reservation', which appears to serve a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its sibling 'check_tabelog_reservation' or other dining tools. The description only explains what it does, leaving the agent without clues about selection criteria, such as provider-based routing or preferred usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the qualifier 'verified' which hints at data quality, but otherwise it simply restates the read-only nature already declared by annotations (readOnlyHint, idempotentHint). It does not disclose any additional behavioral traits such as response format, pagination, or error handling. Since annotations carry the safety profile, the description adds minimal but non-zero value, warranting a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action and lists specific topics. No filler words, no redundancy. Every element adds value, making it an excellent model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and an output schema present, so the description need not explain return values. It covers the what (FAQs on specific topics) and the scope (property). Nothing critical is missing for an agent to call it correctly. The only minor gap is not mentioning the provider default, but that is in the schema, so a 4 is fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (hotel_id and provider) are fully documented in the schema. The description does not add any additional meaning or context for the parameters, such as how they interact or typical usage. Baseline 3 is appropriate for full coverage with no extra description value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('verified property FAQs') with specific topics (check-in, parking, etc.). It is unambiguous and tells the agent exactly what this tool retrieves. However, it does not explicitly differentiate from sibling tools like get_property_details, which might also cover some of these topics, so it loses a point for lack of explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, conditions, or comparisons to sibling tools. An agent would have to infer from the name and context that this is the go-to for FAQs, which is not sufficient for confident selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, establishing the safety profile. The description adds only the generic 'Get', which is consistent with readOnly, but does not provide additional context such as potential data volume, provider-specific behavior, or any side effects. Given the annotations, the description meets the minimal bar but offers no extra transparency beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and resource, then lists specific output components. Every word is purposeful, with no fluff or redundancy. It achieves maximum clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and a high schema coverage for parameters, the description need not explain return structures. The description adequately captures the essence of the tool for a simple read operation. Minor gaps exist, such as not noting that check-in/check-out are optional for overview purposes, but those are already detailed in the schema, so the description is sufficient in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 8 parameters are adequately documented in the schema. The description does not add any parameter-specific meaning; it only lists return fields. According to the rubric, when schema coverage is high, the baseline is 3, and no additional value is added here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a specific resource ('full property overview') and lists concrete content fields (address, star classification, amenities, room rate options). It distinguishes itself from sibling tools like get_room_grid (room availability) and get_hotel_reviews (reviews) by the nature of the data returned, though it does not explicitly name any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used for property summaries, nor does it reference siblings such as get_room_grid or compare_hotel_prices for other use cases. The agent is left to infer the appropriate context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful content details (breakfast inclusion, cancellation terms, bed setups) beyond those annotations, but it doesn't disclose other behavioral traits like result variability or the effect of the logged_in flag on member rates. Some value is added, but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently lists the key aspects without filler. It is concise and well-structured, earning a perfect score for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the presence of an output schema and strong annotations (read-only, open-world, idempotent), the description sufficiently covers the tool's purpose. The main gap is the lack of usage context, but that is captured under usage_guidelines. For a read-only inspection tool, it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters having descriptive text. The description doesn't add parameter-specific semantics beyond hinting at the data types inspected, but the schema already covers the parameters' meaning. The baseline of 3 is appropriate since the description adds no extra parameter insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific resource (room grid) and the information it exposes (beds, dimensions, breakfast, cancellation). It is distinct from siblings like get_property_details, though it doesn't explicitly contrast itself with them, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_property_details or compare_hotel_prices. It doesn't mention prerequisites, conditions, or scenarios where this tool is preferred, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that it operates on partial keywords and covers multiple entity types, which is useful context beyond the annotations but does not contradict them. No side effects are implied, consistent with read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no filler. The key purpose and scope are front-loaded. All necessary information fits efficiently within one line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are defined. However, the description does not mention when to prefer this tool over suggest_locations or suggest_tabelog, especially in a rich sibling ecosystem. The openWorldHint annotation suggests possible unknown behaviors, but the description doesn't address them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (query, limit, provider) are already documented. The description adds little beyond restating the entity types covered by query, which is already in the schema examples. It meets the baseline without adding extra nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'autocomplete' and the resource 'search query', and lists specific entity types (restaurants, cafes, stations, areas, food genres). It is distinct from generic search, but does not explicitly differentiate from sibling suggest_tabelog or suggest_locations, which are also suggestion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for autocomplete/search-as-you-type scenarios, but provides no explicit when-to-use or when-not-to-use guidance versus the many sibling search and suggestion tools. The broad entity list hints at coverage but lacks clear exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description doesn't need to cover safety or idempotency. It adds meaningful behavioral context beyond annotations by describing the output composition: verified Bayesian rating scores with thresholds, Tabelog Award winners, 100 Famous Stores, budget info, and reservation status. This tells the agent what kind of results to expect, which is not in the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core purpose in the first sentence. The second sentence lists several output characteristics but remains a single efficient sentence. There is no redundant fluff or repeated schema information, making it appropriately concise for the level of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, but schema coverage is 100% and an output schema exists, so the description need not explain return values. The description covers the key purpose and enriches it with output expectations. It is missing explicit usage differentiation from siblings, but that is covered under usage_guidelines and does not hinder the agent from calling the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 every parameter. The description does not add parameter-specific semantic detail beyond what the schema provides; the rating-threshold explanation is about output values, not input parameters. Per the rubric, with high schema coverage, the baseline is 3, and the description meets that without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and a clear resource ('top-rated restaurants, cafes, and gourmet dining spots'), and goes beyond a simple noun to specify what kinds of places are included. It also names the data sources (Tabelog Japan and global providers) and lists distinguishing output features (ratings, awards, budgets), making it easy to understand what this tool does and how it differs from a generic search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is a search tool, so an agent would use it when the user asks to find restaurants. However, it does not explicitly when to use this tool over siblings like 'search_tabelog' or 'suggest_dining', nor does it state when not to use it. There is no alternative routing or exclusion guidance, so it remains at implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety and side-effect profile. The description adds that it is a 'direct shortcut' and behaves equivalently to suggest_dining with provider='tabelog', which provides some behavioral context (e.g., no additional filtering). It does not describe response format or potential quirks, but the annotations cover the most critical behavioral traits, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The first sentence states the purpose and target, the second provides the exact equivalent call. Front-loaded and efficient, exactly what a shortcut description should be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema, the description is almost complete. It conveys the core use case, the provider scope, and the equivalence to another tool. It does not explicitly mention error handling or edge cases, but the existence of an output schema and the tool's simplicity keep the gap small. One minor omission is explicit direction on when to use this versus the general suggest_dining, though that is somewhat implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the two parameters (query and limit). The description only mentions these parameters via the equivalent function call signature, not their meaning or constraints. It implies 'query' is the keyword to autocomplete from the phrase 'autocomplete keywords', but does not explain 'limit' or its default. This is insufficient compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('autocomplete') and resource ('keywords on Tabelog Japan'), and explicitly frames it as a 'direct shortcut' to suggest_dining with provider='tabelog'. This clearly distinguishes it from the general suggest_dining and other tools like suggest_locations, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by noting it is equivalent to suggest_dining(query, provider='tabelog', limit=limit), which implies it is the Tabelog-specific autocomplete tool. However, it does not explicitly state when to prefer this over suggest_dining (e.g., 'use this when you only want Tabelog results'), though the equivalence hint provides reasonable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description does not need to restate that. It adds useful context by specifying the scope (Tabelog Japan) and the 'upcoming' reservation aspect, which informs behavior beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no filler. The purpose is front-loaded, and the equivalence statement is an efficient way to convey the relation to the general tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, output schema provided), the description covers the core purpose and scope. However, the missing parameter semantics and the lack of any guidance on prerequisites or return format prevent it from being fully complete, though output schema handles returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, restaurant_id, and the schema description coverage is 0%, leaving the description to clarify its meaning. The description does not explain what restaurant_id is or where to obtain it, relying on the tool name and context. This is a gap that the description could easily have filled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a shortcut to check upcoming reservation availability specifically on Tabelog Japan. It distinguishes itself from the general check_restaurant_reservation by explicitly naming the provider, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Tabelog reservation checks by stating it is equivalent to check_restaurant_reservation with provider='tabelog'. This effectively tells the agent when to use this tool versus the general alternative, though it does not explicitly mention exclusions or other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety/retry profile is covered. The description adds value on top by disclosing that rates are 'live' (real-time, subject to change) and by describing the preserved platform-specific data (room sizes, crossed-out prices, perks, star ratings). It does not contradict the annotations — 'Search'/'Retrieves' align with readOnly and idempotent. Minor gap: pagination/overlap across providers is unaddressed, but the annotation stack lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences with no filler. The primary action and scope are front-loaded in sentence one, the retrieved data in sentence two, and the platform-specific richness in sentence three. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A complex tool with 11 parameters, all schema-documented, plus an output schema that removes the need to explain return values. The description still covers purpose, scope (three providers), and data richness. The only incremental gap is not pointing to follow-on tools (get_property_details, get_room_grid) for deeper inspection, but that is not required for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 11 parameters are already documented (limit, query, rooms, adults, check_in, children, provider, check_out, logged_in, max_price, min_price). The description adds no parameter-level detail beyond the schema; it only enriches the expected output (room sizes, crossed-out prices, perks). With full schema coverage, the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Search hotels across Agoda, Booking.com, and Hotels.com in parallel' — and clearly scopes the tool as a multi-provider discovery search. This distinguishes it from siblings like compare_hotel_prices, get_room_grid, and get_property_details, which handle side-by-side comparison and per-property detail, leaving no ambiguity about what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence implies this is the discovery/search entry point and the 'live rates... booking links' phrasing suggests a pre-detail stage. However, it never explicitly states when to use this versus siblings such as compare_hotel_prices or the follow-on tools get_property_details/get_room_grid, nor gives exclusions. Usage context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate those. The description adds implementation behavior (parallel queries) and output features (resolving IDs/coordinates), which is useful but not comprehensive. It does not disclose potential latency, aggregation details, or failure modes. Given the annotation coverage, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose ('Autocomplete search query') and followed by a brief technical note on how it works. There is no redundancy or extraneous information, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 detail return values. It covers the core functionality, mentions parallel provider queries, and notes the types of resolved data. It does not mention pagination or limit-per-provider behavior, but the schema's 'limit' parameter description already covers that. Overall, it is sufficiently complete for an agent to call the tool correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (query, limit, provider) are already well documented with examples and defaults. The description does not add additional meaning to the parameters; it merely reinforces what the schema states. The description's mention of 'parallel' queries indirectly references the provider parameter, but the schema already explains that. Thus, it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs autocomplete for destinations, cities, districts, landmarks, and properties, and distinguishes it from sibling suggest tools like suggest_dining (restaurants) and suggest_tabelog (Tabelog-specific). It also specifies that it queries typeahead endpoints in parallel and resolves destination IDs, geo-coordinates, and property identifiers, giving a precise sense of scope and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for location-typeahead needs, and the context of sibling tools (suggest_dining, suggest_tabelog) makes the primary use case clear. However, it does not explicitly state when not to use it or mention alternatives, so it lacks explicit exclusionary guidance. The verb 'Autocomplete search query' and resource list are clear enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true and idempotentHint=true, which cover safety. The description adds value by specifying the different input formats (name, ID, URL) and the exact data returned (star ratings, category strengths, photos), which is not in the annotations. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs. It front-loads the core action and includes concrete examples without unnecessary filler. All sentences contribute to understanding input and output, so it's efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return format is covered. The description addresses input variability (name, ID, URL) and the data fetched. Though it doesn't explicitly mention pagination or provider selection, those are in the schema. For a read-only retrieval tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents all four parameters. The description largely repeats the parameter descriptions (e.g., places and URLs) without adding new semantic meaning beyond what's in the schema. No additional parameter-specific guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool fetches verified user reviews, star ratings, category strengths, and reviewer photos from dedicated review platforms. It names the verb ('Fetch') and the resource ('reviews'), and mentions specific platforms (Kakao Maps, Google Reviews, Tabelog) that distinguish it from other review tools like get_hotel_reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what the tool does (fetches from external review platforms) and how to provide input, but it does not explicitly mention alternatives like get_hotel_reviews or when to prefer one over the other. It implies its broader scope by accepting hotel/place names, but no explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the valuable behavioral fact that it is equivalent to get_restaurant_details with provider='tabelog', clarifying it is a wrapper. It does not add additional behavioral context (e.g., data freshness or error conditions), but given the strong annotations, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero redundancy. The purpose is front-loaded in the first sentence, and the equivalence is clearly stated in the second. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, read-only, output schema present), the description covers the essential aspects: what it does, what input it takes, and its relationship to the general function. It could mention explicit usage guidance, but overall it is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no additional explanation of the 'restaurant_id_or_url' parameter beyond naming it in the equivalence. While the parameter name is self-explanatory, the description does not compensate for the lack of schema documentation, leaving the input format and requirements implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a Tabelog restaurant profile with specific fields (address, coordinates, budget, amenities) and explicitly distinguishes it as a 'direct shortcut' for the Tabelog provider, while naming the equivalent general call. This differentiates it from siblings like get_restaurant_details and search_tabelog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is the Tabelog-specific shortcut and references the alternative get_restaurant_details(provider='tabelog'). It implies when to use it (when Tabelog data is needed) but does not explicitly spell out exclusions for other providers or edge cases, so it falls short of a full when/when-not list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect concerns. The description adds the geographic scope ('across Japan') and the equivalence to the general function, but does not disclose additional behavioral traits like rate limits or pagination details. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The purpose is front-loaded and the equivalence is stated concisely. Every sentence earns its place without redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a shortcut tool with an existing output schema and comprehensive annotations, the description is complete. It clarifies the Tabelog scope and relationship to the general search function. No essential information is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already documented in the schema. The description does not add parameter-specific detail beyond what the schema provides. Since the schema carries full parameter semantics, the description adds minimal value beyond clarifying the overall scope, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches restaurants across Japan on Tabelog, using the verb 'search' with a specific resource and geographic scope. It also names the equivalent general function, which differentiates it from siblings like suggest_tabelog and get_tabelog_restaurant_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is a direct shortcut equivalent to `search_restaurants(..., provider='tabelog')`, giving the agent a clear relationship to an alternative. However, it does not explicitly state when to prefer this over search_restaurants or suggest_tabelog, though the equivalence implies the Tabelog-specific scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect profile. The description adds meaningful behavioral detail: which providers are queried, what data is extracted, and that it highlights the winning platform. It does not mention rate limits or failure modes, but for a read-only comparison tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and the second sentence adds concrete detail without waste. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is present, so return-value detail is not the description's job. The description covers the essential aspects: what it does, which providers, and what it produces. It could note that it searches by hotel_name and dates (already in schema), but it is complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is fully documented in the schema. The description adds some context (e.g., that it extracts nightly rates and perks), but does not provide new parameter-level meaning beyond what the schema already states. Baseline 3 is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Perform a cross-platform parallel price check') and resource ('across all providers'), and enumerates the exact providers (Agoda, Booking.com, Hotels.com) and output (lowest rates, perks, URLs, winning platform). This differentiates it from sibling tools like search_hotels or get_room_grid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when an agent needs to compare prices across providers) and what it does, but it does not explicitly state when not to use it or mention alternatives. The tool name itself signals comparison, so the context is clear, but explicit routing guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are both false (not read-only, not destructive), so the description must carry the burden of behavioral disclosure. It adds value by stating that it launches Chrome and opens the official authentication portal, indicating an interactive, user-driven login process. It also mentions the goal of capturing member rates. It does not disclose potential wait times, failure modes, or what happens after the browser opens, but the key behavioral trait (interactive browser launch) is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence front-loads the primary action ('Launch Chrome browser to sign in'), and the second adds necessary context (portal, providers, and purpose: capture member rates). Every word earns its place, and the description is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema (not shown), so the description need not cover return values. It explains the action, the targeted providers, and the intended result. However, it does not indicate whether the tool waits for user login or returns immediately after launching, nor any prerequisites like user presence. Given the presence of an output schema and the simplicity of the tool, this is largely sufficient, but a note about the interactive waiting behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'provider' parameter fully described in the schema including allowed values and default. The description merely reiterates the 'official authentication portal' and the provider list without adding new meaning beyond the schema. Per calibration, a baseline of 3 is appropriate when the schema does the heavy lifting, and the description adds no extra semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Launch Chrome browser') and the resource ('hotel booking provider'), and lists the specific providers (Agoda, Booking.com, Hotels.com). It distinguishes itself from the sibling tool get_login_status by focusing on the act of logging in rather than checking status. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a user needs to complete a login to capture member rates, giving clear context for its use. However, it does not explicitly exclude the alternative get_login_status or provide a when-not-to-use guidance. Since get_login_status is a direct sibling, the lack of explicit alternative routing is a minor gap, but the purpose is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the base expectation is lower. The description adds valuable context by explaining that it inspects active session cookies loaded from Chrome, which clarifies the mechanism and reinforces the non-mutating nature. It does not contradict annotations and provides extra detail that helps an agent trust the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, focused sentences: the first gives the core purpose, the second adds essential detail about cookie source and specific providers. No filler, no redundancy, and the critical action is front-loaded. The structure earns top marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter, full schema coverage, and presence of an output schema (making return-value documentation unnecessary), the description is complete. Annotations already cover safety and idempotence, and the description specifies exactly which providers and reward programs are checked. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the 'provider' parameter 100%, including its default and allowed values. The description mentions the same providers and reward types but does not add semantics beyond what the schema already states. Since high coverage reduces the need for description-level parameter info, baseline 3 is appropriate; there is no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Check') and a specific resource ('authentication and VIP/Member reward status'), and further enumerates the exact platforms and reward types (Agoda VIP tiers, Booking.com Genius, Hotels.com OneKey). It distinguishes itself from the sibling 'interactive_login' by focusing on status inspection rather than authentication actions, so an agent can tell them apart 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (verify current login/reward status by reading cookies) and that it is non-intrusive, but it does not explicitly state when to prefer this over interactive_login or mention exclusions after login failures. It gives clear context about checking sessions without logging in, but lacks an explicit 'use this for X, use interactive_login for Y' disclaimer, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and open-world behavior. The description goes beyond these by disclosing that the tool supports automatic English and local language place name resolution (e.g., resolving long hotel names to landmarks), which is not in the schema. It also enumerates the route modes. No contradictions; the added behavioral context is useful for an agent deciding to call this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core purpose with precise output types and scope; the second adds a differentiating capability (place name resolution) with examples. No filler, front-loaded, and easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return format is specified elsewhere) and annotations cover safety and side effects, the description is largely complete. It covers scope, supported entity types, route modes, and the name resolution feature. Minor details like geographic limitations are handled by the country parameter default. It does not explicitly mention rate limits or failure modes, but these are not critical given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so each parameter is already explained. The description adds semantic value by providing a concrete example of place name resolution for origin and destination, clarifying that natural language strings are accepted beyond simple addresses. This exceeds the baseline of 3 by giving operational guidance for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Calculate' and enumerates the exact deliverables: travel routes, turn-by-turn walking steps, public transit (subway/bus), and driving taxi fares. It specifies the resource as 'ANY two travel entities' and lists those entity types (hotels, restaurants, cafes, stations, airports, landmarks). This distinguishes it from the sibling get_hotel_distance_and_transit, which focuses on hotel-specific transit, by emphasizing the universal applicability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for calculating routes between any two travel entities and highlights place name resolution as a key capability. However, it does not explicitly mention when NOT to use this tool or name alternatives like get_hotel_distance_and_transit. The guidance is implied by the 'ANY' scope but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hotels-mcp MCP server](https://glama.ai/mcp/servers/Skyline-9/hotels-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Skyline-9/hotels-mcp)

Score Badge

Copy to your README.md:

[![hotels-mcp MCP server](https://glama.ai/mcp/servers/Skyline-9/hotels-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Skyline-9/hotels-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Skyline-9/hotels-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server