VeryChic Hotel Deals
Server Details
Unofficial read-only MCP server for VeryChic hotel offers
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 5/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: listing all deals, filtering/searching, and fetching details. The descriptions explicitly guide when to use each, leaving no ambiguity.
All tools share the 'verychic_' prefix and use snake_case. However, 'list_deals' and 'search_offers' follow verb_noun, while 'offer_details' is noun_noun, a minor inconsistency.
Three tools are perfectly scoped for a read-only flash-sale browsing service. Each tool fills a necessary role without redundancy or missing essential operations.
The set covers browsing all offers, filtered search, and detailed view. Missing date or sorting filters are minor gaps, but core discovery is well-supported for a read-only catalogue.
Available Tools
3 toolsverychic_list_dealsAInspect
Browse the VeryChic flash-sale hotel offers available right now.
When to use: to discover the current catalogue without any filter. To narrow by
destination, country, or price use `verychic_search_offers` instead; to get the
full detail and per-date prices of one offer use `verychic_offer_details`.
Behaviour: read-only and anonymous (no account or credentials); rate-limited to
about 1 request per second. Returns the first `limit` offers in catalogue order
(no pagination). Prices are in EUR and text is in French. "Current" means live
offers at call time; the catalogue changes over time.
Returns a list of offer objects, each with: `source` and `external_id` (the pair
that identifies an offer for `verychic_offer_details`), `name`, `destination`,
`country`, `price` and `currency`, `discount`, `short_desc`, `offer_end_date`,
`latitude`/`longitude`, `image`, `advantages`, and `offer_url` (public web page).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of offers to return (default 20). Caps the result size only; there is no pagination or cursor, so this always returns the first N offers of the live catalogue. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses read-only and anonymous access, rate limiting (~1 req/s), lack of pagination (returns first `limit` offers), currency (EUR), language (French), and temporal nature of the catalogue. No annotations exist, so full burden is carried effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into sections (purpose, when to use, behaviour, returns), uses concise language, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, clear output), the description covers all necessary aspects: purpose, usage, behavior, parameter meaning, and complete return field list. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'limit' is described in the schema, but the description adds crucial context: it caps the result size, there is no pagination, and it always returns the first N offers of the live catalogue. This goes beyond the schema's basic definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses current flash-sale offers, using a specific verb and resource. It explicitly distinguishes from siblings by naming verychic_search_offers for filtered search and verychic_offer_details for full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'When to use' section that explains when to use this tool (no filter) and when to use alternatives, with explicit tool names for each alternative scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verychic_offer_detailsAInspect
Get full details plus per-date availability and prices for one specific VeryChic offer.
When to use: after `verychic_list_deals` or `verychic_search_offers` returned an
offer you want to inspect — pass that offer's `source` and `external_id` here. You
must obtain those two identifiers from a list/search result first; this tool does
not search.
Behaviour: read-only and anonymous; rate-limited to about 1 request per second;
prices in EUR, text in French. Availability is looked up for roughly the next 5
months. For tour-operator packages (`source` = 'ORCHESTRA_TO') VeryChic exposes no
date-availability endpoint: `availabilities` is then empty and
`availabilities_supported` is false — meaning "not supported", NOT "sold out".
Returns an object with: `offer` (same fields as a list result, plus `offer_url`),
`advantages`, `included_added_values`, `non_included_added_values`, `gallery`
(image URLs), `availabilities` (one entry per check-in date with `date`, `price`,
`currency`, `nights`, `days`, `departure_city_code`), `availabilities_supported`
(bool), and `cheapest_price` (lowest available price, or null when none).
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | The offer's source type, copied verbatim from the `source` field of a `verychic_list_deals`/`verychic_search_offers` result. One of 'ORCHESTRA' (a single hotel) or 'ORCHESTRA_TO' (a tour-operator package). Packages have no per-date availability. | |
| external_id | Yes | The offer's numeric `external_id`, copied from a `verychic_list_deals`/`verychic_search_offers` result. Identifies the offer together with `source`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses: read-only and anonymous behavior, rate limits (1 req/s), currency (EUR), language (French), availability window (~5 months), and special case for 'ORCHESTRA_TO' where availabilities are unsupported, clarifying that empty availabilities mean 'not supported' not 'sold out'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, usage, behavior, return format. First sentence front-loads the core function. No unnecessary words; every sentence adds value. Length appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly details the return object structure, listing all major fields (offer, advantages, added values, gallery, availabilities, etc.) and special conditions (e.g., cheapest_price null when none). Addresses all aspects an agent needs to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining that parameters source and external_id must be copied verbatim from list/search results, and provides context on the meaning of 'ORCHESTRA' vs 'ORCHESTRA_TO' and its impact on availability. This goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get full details plus per-date availability and prices for one specific VeryChic offer.' It uses a specific verb ('get') and resource ('offer details/availability/prices'), and distinguishes from siblings by noting that it requires identifiers from list/search results, emphasizing it is for a single offer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'after verychic_list_deals or verychic_search_offers returned an offer you want to inspect.' Also gives a clear when-not: 'this tool does not search.' It directs users to first obtain source and external_id from other tools, providing actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verychic_search_offersAInspect
Search and filter the current VeryChic offers by destination, country, and/or price.
When to use: when you already know roughly what the user wants (a place, a country,
a budget). To simply list everything on offer use `verychic_list_deals`; to inspect
one specific offer in depth use `verychic_offer_details`. All filters are optional
and combine with AND; calling with no filter is equivalent to `verychic_list_deals`.
Behaviour: read-only and anonymous; rate-limited to about 1 request per second.
Filtering is done client-side over the live catalogue: `destination` is a
case-insensitive substring (matched on destination or name), `country` is an exact
case-insensitive match, `max_price` is an inclusive EUR ceiling. Prices are in EUR
and text is in French. Returns the first `limit` matches.
Returns a list of offer objects with the same fields as `verychic_list_deals`
(including `source` + `external_id` for use with `verychic_offer_details`). An
empty list means no offer matched the filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matching offers to return (default 20), applied after filtering. No pagination. | |
| country | No | Exact country name, case-insensitive, as spelled in the (French) catalogue, e.g. 'France', 'Italie', 'Grece'. Omit to not filter by country. | |
| max_price | No | Inclusive upper bound on the offer price, in EUR. Offers with no price are excluded when this is set. Omit for no price cap. | |
| destination | No | Case-insensitive substring matched against each offer's destination AND name (e.g. 'paris', 'maldives', 'crete'). Omit to not filter by destination. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: read-only, anonymous, rate-limited (1 req/s), client-side filtering, case-insensitive matching, EUR prices, French text, returns first `limit` matches, empty list if no match. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with 'When to use', 'Behaviour', 'Returns' sections. Concise sentences, no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters, no required, and presence of output schema (mentioned returns same fields as list_deals), description covers filtering logic, return format, edge cases (empty list, no price exclusion), and links to sibling tools. Complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant context: destination is case-insensitive substring, country is exact case-insensitive match, max_price is inclusive EUR ceiling, limit defaults to 20 with no pagination. Makes parameters clear beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches/filters VeryChic offers by destination, country, and/or price. It distinguishes from siblings: verychic_list_deals for listing all, verychic_offer_details for one specific offer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: when you already know roughly what the user wants. Also tells when not to use: to list everything use verychic_list_deals; to inspect one offer use verychic_offer_details. Notes filters are optional, combine with AND.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!