viator-mcp

Server Quality Checklist

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

Latest release: v1.0.5
Disambiguation5/5
Each tool targets a distinct entity or action: freetext search, destinations, locations, products, product tags, product details, attractions, attraction details, availability schedules, and exchange rates. No two tools have overlapping purposes, ensuring clear selection.
Naming Consistency5/5
All tools follow a consistent 'vt_verb_noun' pattern in snake_case (e.g., vt_search_freetext, vt_list_destinations, vt_get_product). The prefix 'vt_' is uniform, and verbs are appropriately descriptive.
Tool Count5/5
With 10 tools, the server is well-scoped for a travel information API. Each tool serves a clear purpose in the workflow of searching, retrieving details, and obtaining pricing/currency data, without being overly numerous or sparse.
Completeness5/5
The tool set covers the full lifecycle for discovering Viator products: search (freetext and structured), listing destinations and tags, retrieving product and attraction details, checking availability and prices, and converting currencies. No obvious gaps for the stated purpose.
Average 4.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 38 commits in the last 12 weeks
- Last stable release on July 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds a list of returned fields, which provides some behavioral context but does not go beyond what annotations imply. No side effects or error conditions mentioned.
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?
Single, front-loaded sentence that efficiently communicates purpose and returned data. No extraneous 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 (2 parameters, no output schema, openWorldHint), the description adequately lists key returned fields. However, it lacks mention of error behavior (e.g., if ID not found) which 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 description coverage is 100%; both parameters are already documented. The description does not add additional parameter-specific meaning beyond what the schema provides, meeting 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?
Description explicitly states 'Get details for one Viator attraction by id' and lists specific returned fields (name, destination, hours, review summary, product codes, URL). Clearly distinguishes from sibling search tools like vt_search_attractions.
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?
Description implies usage when an attraction ID is known and full details are needed, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
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 and openWorldHint=true. The description adds value by listing the return fields (description, inclusions, etc.) but does not disclose other behaviors like potential errors, rate limits, or the fact that it returns a single product object. Given the annotations cover safety, 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 a single, well-structured sentence that conveys the tool's purpose and output. Every word contributes meaning with no redundancy.
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 retrieval tool with no output schema, the description adequately lists the main content returned. It could mention that it returns a single product object, but the listed fields (description, inclusions, etc.) give sufficient 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% - both parameters are described with patterns, examples, and meanings. The description does not add extra semantics beyond what the schema provides. Baseline 3 is correct.
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 ('Get full details') and resource ('one Viator product by product code'), and lists the included data fields (description, inclusions/exclusions, etc.), clearly distinguishing it from siblings like vt_search_products or vt_list_destinations.
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 use when you have a product code and need comprehensive product details. While it doesn't explicitly state when not to use or name alternatives, the context of sibling tools (e.g., vt_search_products, vt_get_availability_schedule) makes the intended use clear.
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 and openWorldHint=true, so the safety profile is covered. The description adds that it returns multiple types (products, attractions, destinations) and is free-text, which is useful but not substantial beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and example. Every word adds value. No superfluous information.
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 search tool with extensive schema documentation, the description provides adequate high-level context. It could mention search_types or pagination, but the schema fills those gaps. Slightly incomplete for a full understanding without reading the schema.
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 input schema already documents all 15 parameters in detail. The tool description does not add further meaning to any parameter, meeting the baseline.
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?
Description clearly states the verb 'search' and the resource (Viator products, attractions, destinations) with a concrete example 'colosseum underground tour'. It distinguishes from siblings by positioning itself as 'fastest way to find things when you don't have a destination id yet'.
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: 'when you don't have a destination id yet', implying it's the go-to for open-ended searches. It doesn't explicitly list sibling tools or when NOT to use it, but the context is strong enough to guide the agent.
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 openWorldHint. The description adds that the data is 'cached' and is 'reference data', which provides additional behavioral insight beyond the annotations. No contradictions.
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 wasted words. The key purpose and usage context are front-loaded, 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?
Given no output schema, the description omits return value details, but the tool is simple reference data. The mention of caching and relationship to vt_get_availability_schedule provides sufficient context 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 both parameters having clear descriptions and enums. The description doesn't add significant new meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 uses specific verb 'Get' and resource 'exchange rates', and immediately connects it to a specific use case: converting supplier-currency prices from vt_get_availability_schedule. This clearly distinguishes it from sibling tools which deal with listings, search, and destinations.
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 when to use this tool ('needed to convert supplier-currency prices from vt_get_availability_schedule') and provides context that it's cached reference data. While it doesn't explicitly list when not to use it, the guidance is clear and directional.
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 indicate readOnlyHint=true and openWorldHint=true, so the description carries less burden. The description adds value by mentioning that product codes are included in the results, which is a key behavioral trait not captured by annotations. However, it does not disclose pagination behavior or any potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences: the first clearly states the purpose, and the second gives a helpful prerequisite. It is front-loaded, concise, and contains no unnecessary words or redundant information.
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 has 5 parameters, no output schema, and annotations present, the description adequately covers the input requirements and general output (attractions with product codes). Missing details about output structure or pagination are partially compensated by the schema descriptions. For its complexity, it is reasonably 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?
The input schema has 100% description coverage for all 5 parameters, so the schema already explains their meanings. The description provides no additional parameter details beyond stating that destination_id comes from vt_list_destinations, which is already in the schema description. Therefore, the description adds minimal value over the schema.
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 lists attractions for a destination, specifying that it includes product codes. This distinguishes it from sibling tools like vt_search_products (which likely searches products by other criteria) and vt_get_attraction (which retrieves a single attraction).
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 instructs to use vt_list_destinations to find destination ids, providing a clear prerequisite. However, it does not explicitly mention when to use this tool over alternatives such as vt_search_products or vt_get_attraction, leaving the agent to infer from the tool's purpose.
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 and openWorldHint=true, so the description's minimal behavioral detail (returns summaries) adds limited value beyond annotations. There is no contradiction. The description could mention pagination or default sorting, but it is adequate.
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 short sentences, front-loading the core action and result, then referencing auxiliary tools. Every sentence earns its place, no unnecessary words. Appropriate for the parameter count.
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 high parameter count (18) and no output schema, the description covers essential aspects: what the tool does, what it returns, and how to prepare inputs. However, it omits mention of pagination defaults (start=1, count=10) and sort default (DEFAULT). Still fairly complete for a search tool with openWorldHint.
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?
Schema coverage is 100% with descriptions for all 18 parameters. The description adds value by grouping filter categories (destination, tags, price, dates, rating, duration), which helps understand the parameter space concisely. This goes beyond simple schema repetition.
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 Viator tours, activities, and experiences with structured filters, and returns product summaries with pricing and booking URLs. It distinguishes from sibling tools like vt_search_freetext and vt_search_attractions by specifying structured filters.
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 advises using vt_list_destinations and vt_list_product_tags to find IDs, providing clear prerequisite guidance. It implies usage for structured search vs. free-text or attractions search, but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's main behavioral contribution is clarifying the return data (seasons, times, pricing). It does not disclose additional traits like rate limits or error conditions, but with annotations covering safety, a score of 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 plus a short note, front-loading the core purpose and then adding a critical usage hint. Every sentence serves a purpose with no redundancy.
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?
Despite lacking an output schema, the description comprehensively lists what the tool returns (seasons, days, start times, unavailable dates, per-age-band pricing) and addresses the currency conversion caveat. For a single-parameter, read-only tool, this is fully sufficient.
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?
Schema coverage is 100% for the single parameter product_code, and the schema description already states its purpose. The description adds value by providing an example ('e.g. 5010SYDNEY'), which helps agents understand the expected format beyond the regex pattern.
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 retrieves availability schedule and pricing for a Viator product, listing specific data elements (seasons, days of week, start times, unavailable dates, per-age-band pricing). This distinguishes it from siblings like vt_get_product or vt_get_exchange_rates.
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 includes a note advising that prices are in the supplier's currency and recommending vt_get_exchange_rates for conversion, providing explicit guidance on when to use an alternative. However, it doesn't specify when not to use this tool or compare to other siblings directly.
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 mark the tool as read-only and open-world. The description adds valuable context: caching behavior ('Reference data — cached') and a batch limit of 500 references. This supplements the annotations well, though error handling or rate limits are not mentioned.
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, consisting of two sentences. The first sentence explains the core purpose, and the second adds constraints. No redundant or superfluous information.
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 simple input (one parameter) and lack of output schema, the description mentions the output types (names, addresses, coordinates) and batch limit. This is mostly complete, but it omits what happens with invalid or missing references, which could be important for error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'location_refs' has a schema description that is fully covered (100%). The tool description adds meaning by specifying the format of references (e.g., 'LOC-...') and what they represent (meeting points, pickup points), which goes beyond the schema.
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 resolves location references to names, addresses, and coordinates, and specifies input types like 'LOC-...', meeting points, and pickup points. It distinguishes itself from sibling tools which perform different tasks such as searching or getting availability.
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 for resolving references from product details but does not explicitly state when to use this tool vs alternatives like vt_list_destinations. No when-not or exclusions are given, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and open-world. Description adds that this is cached reference data, which is crucial for agents to understand potential staleness. Also lists the exact data fields returned, providing full behavioral transparency beyond 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 focused sentences with no superfluous words. The first sentence states what the tool does and its output; the second gives guidance on usage and caching. Every sentence adds value.
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 simple list tool with one optional parameter and no output schema, the description completely covers what it returns, how to use it, and important caching behavior. No gaps remain.
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 covers the single optional parameter (campaign_value) with a description. The tool description does not add further semantics about the parameter beyond what is already in the schema, so baseline score of 3 is appropriate.
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?
Description clearly states it lists destinations (cities, regions, countries) with specific fields like ids, parent hierarchy, IATA codes, time zones, coordinates. Distinguishes itself by mentioning how destinationId can be used with other tools like vt_search_products and vt_search_attractions.
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?
Indicates that the data is reference and cached, and suggests using destinationId with specific search tools. While it does not explicitly state when not to use it, the context is clear for an agent to infer its purpose as a lookup for destination data.
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 declare readOnlyHint and openWorldHint. The description adds behavioral context with 'Reference data — cached', which informs the agent about freshness. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with no wasted words. All information is front-loaded and directly relevant.
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 tool has no parameters and no output schema, the description fully covers what the tool does, what it returns, and its usage context. It is complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds value by describing the output structure (tag id, names in all locales, hierarchy) beyond what the empty schema provides.
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 'list', the resource 'product tags', and specifies the return format (tag id, names in every locale, parent-tag hierarchy). It distinguishes from siblings by mentioning usage with vt_search_products.
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 a concrete use case: 'Use tag ids to filter vt_search_products.' It also notes that the data is cached, implying it's not for real-time queries. However, it does not explicitly exclude alternatives or state when not to use it.
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:

[![viator-mcp MCP server](https://glama.ai/mcp/servers/chrischall/viator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/viator-mcp)

Score Badge

Copy to your README.md:

[![viator-mcp MCP server](https://glama.ai/mcp/servers/chrischall/viator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/viator-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/chrischall/viator-mcp'

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