This server provides read-only, anonymous access to VeryChic's flash-sale hotel deals. You can:
List current offers.
Search and filter offers by destination, country, maximum price, and—per the full specification—also by discount, star rating, flights, theme, or proximity (note: the currently deployed schema only exposes destination, country, max_price, and limit; additional filters are documented but may not be live).
Sort results by discount, price, rating, stars, or distance.
Retrieve detailed offer information, including advantages, image gallery, and day‑by‑day availability and pricing.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@verychic-mcp Search VeryChic offers in Spain under 600 euros."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Browse current flash-sale offers, filter them by destination, country, price, discount, stars, flights, theme, or proximity (and sort the results), then read an offer's availability and prices by date. Read-only, anonymous, no account needed.
Read-only and anonymous. This server only searches and reads offers — it never books, never logs in, and uses no credentials. A conservative rate limit (≥ 1 s between requests) is built into the client. See the disclaimer for terms of use.
Adding the hosted VeryChic MCP server to Claude Desktop as a custom connector, then asking for Spain deals under €600:
Related MCP server: soloway-mcp
Add the server to your MCP client config. With uv installed,
there is nothing to clone or install:
{
"mcpServers": {
"verychic": {
"command": "uvx",
"args": ["verychic-mcp"]
}
}
}This runs the server over stdio, which is what Claude Desktop and Claude Code use. You can also run it directly:
uvx verychic-mcp # stdio (default)
uvx verychic-mcp --help # all optionsThe same command/args pair works in every stdio client; only the wrapping config differs.
These configs are for local clients (stdio). For cloud clients like claude.ai or Cowork,
which connect over HTTPS instead, see Use from Claude.ai or Cowork.
claude mcp add verychic -- uvx verychic-mcp{
"mcpServers": {
"verychic": {
"command": "uvx",
"args": ["verychic-mcp"]
}
}
}{
"servers": {
"verychic": {
"command": "uvx",
"args": ["verychic-mcp"]
}
}
}{
"mcpServers": {
"verychic": {
"command": "uvx",
"args": ["verychic-mcp"]
}
}
}Tool | What it returns |
| Offers filtered by |
| One offer's content (advantages, gallery) plus its availability and prices by date. |
Every call is read-only and anonymous, with a conservative rate limit built into the client.
verychic_search_offersReturns the offers matching every filter you pass (filters are combined with AND).
Parameter | Type | Required | Description |
| string | no | Case-insensitive substring matched against the offer's destination or name. |
| string | no | Exact, case-insensitive country match (e.g. |
| number | no | Keep only offers priced at or below this value (EUR). |
| number | no | Keep only offers with at least this discount percentage (e.g. |
| integer | no | Keep only offers with at least this hotel star rating (1–5). |
| boolean | no |
|
| string (enum) | no | Keep only offers matching a curated theme decoded from the catalogue's thematics tags. One of: |
| number | no | Latitude/longitude of a search center (decimal degrees), given together, to compute each offer's |
| number | no | Keep only offers within this many km of |
| string (enum) | no | Order results: |
| integer | no | Max number of offers to return. Defaults to |
verychic_offer_detailsReturns one offer's full content plus, for hotels, its day-by-day availability and prices.
Parameter | Type | Required | Description |
| string | yes |
|
| integer | yes | The offer's id, as returned by |
Ask your assistant things like:
"Browse the current VeryChic deals."
"Search VeryChic offers in Spain under 600 euros."
"Find 5-star spa hotels with at least 40% off, cheapest first."
"Show VeryChic offers within 300 km of Paris (48.8566, 2.3522), nearest first."
"Get the details and dated prices for the ORCHESTRA hotel offer 44983."
"Get the details for the ORCHESTRA_TO package offer 301375." Tour-operator packages bundle
flights with the hotel, so they do not expose day-by-day prices the way a single hotel does.
The tool still returns the offer content and advantages, and sets
availabilities_supported: false so an empty availabilities reads as "not supported for this
offer type", not "no dates available".
Offers carry a source (ORCHESTRA for a hotel, ORCHESTRA_TO for a package) and an
external_id. Both come back from verychic_search_offers, so the
assistant can pass them to verychic_offer_details on its own.
A verychic_search_offers result is a list of offer objects (one shown here, trimmed):
{
"source": "ORCHESTRA",
"external_id": 36509,
"name": "Sofitel New York ****",
"destination": "New York, États-Unis",
"country": "États-Unis",
"price": 182,
"currency": "EUR",
"discount": 57.0,
"sales_mode": "FLASH",
"offer_end_date": "2026-06-24T23:55+0200",
"image": "https://.../sofitel-new-york.jpg",
"advantages": ["Petit-déjeuner inclus", "VeryFlexible : réservez en toute sérénité !"],
"offer_url": "https://www.verychic.fr/p/36509/etats-unis-new-york-hotel-sofitel-new-york"
}verychic_offer_details adds gallery, included_added_values, a cheapest_price, and the
day-by-day availabilities for a hotel:
{
"offer": { "source": "ORCHESTRA", "external_id": 44983, "name": "Hotel Kaktus Playa *****", "...": "..." },
"cheapest_price": 169,
"availabilities_supported": true,
"availabilities": [
{ "date": "20/06/2026", "price": 169, "currency": "EUR", "nights": 1, "days": 2 },
{ "date": "21/06/2026", "price": 169, "currency": "EUR", "nights": 1, "days": 2 }
]
}Unlike the local clients in Quick start, cloud clients such as claude.ai and
Cowork only connect to remote MCP servers over HTTPS, not to a local process. To use VeryChic
MCP there, host it yourself in streamable-http mode
(verychic-mcp --transport streamable-http, behind HTTPS) and add it as a custom connector,
pasting your deployment URL with the /mcp path.
A public instance is deployed for convenience at https://verychic-mcp.fly.dev/mcp. Add it as
a custom connector in claude.ai/Cowork, or wire it into a local client that speaks remote MCP:
{
"mcpServers": {
"verychic": {
"url": "https://verychic-mcp.fly.dev/mcp"
}
}
}It is best-effort and may be paused or rate-limited at any time — for anything beyond a quick
try, run your own instance with the uvx command above or host the streamable-http mode.
Listing in Anthropic's official connector directory (next to Booking or Tripadvisor) is out of scope. That directory is reserved for partner integrations that pass a review this kind of tool would not.
The VeryChic web app talks to a public JSON API under
https://api.verychic.com/verychic-endpoints/v1 (plus search.verychic.com). This server
replays those same calls with a browser-like TLS fingerprint (curl_cffi), parses the
responses into typed objects, and exposes them as MCP tools. Everything works without logging
in. The one volatile request parameter, channelVersion, is read from the live site at startup
and falls back to a known value if that read fails.
git clone https://github.com/jordantete/verychic-mcp.git && cd verychic-mcp
pip install -e ".[dev]"
pytest # offline tests, run against recorded fixtures
pytest -m network # optional smoke test against the live API, low volume
ruff check verychic_mcp testsReleases are tag-driven. Pushing a vX.Y.Z tag runs the tests, builds the package, and
publishes it to PyPI through GitHub Actions with trusted publishing,
so no token is stored anywhere.
VeryChic MCP is not affiliated with, endorsed by, or connected to VeryChic or VeryChic SAS. It is an independent community tool for personal use that reads VeryChic's public web API the same way a browser does. You are responsible for complying with VeryChic's terms of sale, notably Article 9 on intellectual property and the database producer's sui generis right. Use it at your own risk, for personal and low-volume browsing only. Do not use it for bulk extraction or redistribution of VeryChic's data.
MIT. See LICENSE.
List current VeryChic offers (20 by default).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits but only mentions the default limit and that offers are 'current'. Important traits like pagination behavior, maximum limit, ordering, or rate limits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of fewer than 10 words, stating the core functionality and default. No wasted words and efficiently communicates the primary action.
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 is simple (1 parameter, optional, with output schema), the description covers the basic action and default. However, it lacks information on how to handle large result sets or the meaning of 'current', which moderately reduces completeness.
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 description adds the default value of 20 for the limit parameter, which is also in the schema, but does not explain the parameter's purpose (e.g., 'maximum number of offers to return'). For a single parameter with 0% schema coverage, this is minimal added meaning.
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 it lists current VeryChic offers and mentions a default limit of 20. This distinguishes it from sibling tools like verychic_offer_details (specific details) and verychic_search_offers (search functionality).
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 provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or context for selecting this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offer details (advantages, gallery) plus availability/prices by date.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| external_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool returns details and pricing, but fails to mention behavioral traits like read-only nature, potential side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with purpose. However, it sacrifices necessary detail for brevity, resulting in a slight deficit for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and minimal parameter guidance, the description is incomplete. It does not cover return format, error handling, or input requirements, making it insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and description adds no meaning for parameters 'source' and 'external_id'. It does not explain where to find these values or any constraints, leaving the agent without necessary context.
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 returns offer details (advantages, gallery) and availability/prices by date, which distinguishes it from sibling tools like list or search. However, it could be more explicit about the resource being a 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?
No guidance on when to use this tool versus siblings. The description implies it is used for a specific offer given source and external_id, but provides no when-not or alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search/filter offers by destination (substring), country, and/or max price.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| country | No | ||
| max_price | No | ||
| destination | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions filtering criteria. There is no disclosure of behavioral traits such as read-only nature, rate limits, pagination behavior (though limit parameter exists), or authentication requirements.
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?
Single sentence, no redundancy. Could be improved by listing parameters or adding structure, but it is succinct.
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?
Despite having an output schema, the description is too brief for a search tool with 4 parameters. Lacks details on substring matching, case sensitivity, price range behavior, or how to interpret results.
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 description explains three parameters (destination, country, max_price) beyond the schema, which has 0% coverage. However, the 'limit' parameter is omitted entirely, leaving its purpose unclear.
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?
Clearly states the tool searches/filters offers by destination (substring), country, and max price. However, it does not explicitly differentiate from sibling tools like verychic_list_deals or verychic_offer_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?
No guidance on when to use this tool versus alternatives. The description only states what it does without any contextual suggestions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3verychic_list_dealsverychic_offer_detailsverychic_search_offersScored across 3 tools
Each tool has a clear, distinct purpose: listing deals, getting detailed info on a specific offer, and searching/filtering offers. No overlap in functionality.
All tools follow a consistent 'verychic_verb_noun' pattern (list_deals, offer_details, search_offers), making them predictable and easy to distinguish.
With 3 tools, the server is minimal but covers the essential operations for browsing and searching travel deals. A few more tools (e.g., sorting, filtering by date) could enhance scope, but current count is reasonable.
The server provides listing, details, and search, which cover the core read-only use case. Missing features like booking or advanced filters are not critical for the primary purpose.
Anonymous, read-only cross-venue discovery of partner-approved venues, cities, destinations.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Search hotel prices, get best overall and best direct price in structured response. Get your developer token at https://Infoseek.ai/mcp
Real-time Booking.com rates for agents. Three things people do with this server. Scan for rate gaps: price_as_seen_from prices the same room from another market, so an agent can sample a property across countries and compare. Put live search in your app: search a destination or look a property up by name, no internal IDs, room-level rates as flat JSON. Run a 24/7 AI travel agent: add the server, sign in with Google, and schedule it. No ads, no sponsored content. You bring your own RapidAPI key, so every search is billed to your plan and never to anyone else's. Add https://hotels.flightpowers.com/mcp , click Sign in, sign in with Google, and paste your RapidAPI key once on the page that opens. Scripts and clients without a sign-in button send the key as x-rapidapi-key on the same URL.
