TourMind Booking Skills: an agent skill for live hotel rates and bookings

What TourMind Booking Skills does that a plain hotel search does not

A generic language model asked for a hotel in Osaka will produce plausible names and plausible prices. Both are usually wrong. TourMind Booking Skills exists to remove that failure mode: the README describes it as an agent skill that resolves places, searches live room products, compares rates across OTAs and hotel suppliers, and then books, pays, cancels or queries the resulting order through the TourMind API.

The intended user is not a traveller typing into a chat window. The README asks for a business account at tourmind.com/admin/skillSignup and says developers and individual users should use a different TourMind Skill version for their user type. That is a distribution decision, not a technical one, and it narrows the audience considerably: this repository is aimed at teams embedding booking into an agent product, not at consumers.

The capability list is concrete. City, hotel, landmark, station, address and ski-area resolution without inventing coordinates. Up to 20 hotel candidates per search, with the five best verified options returned. Nightly and stay-total rates with cancellation terms and inventory status. Room images, facilities, beds, meals and fees. A price and availability recheck immediately before booking. Stripe, WeChat Pay and Alipay as payment starts. And expiring, repeatable, read-only result links that do not expose the Skill Token.

Architecture: a SKILL.md, a token file, and direct HTTPS calls

The repository layout is the architecture. The top level holds SKILL.md, which is the entry point a compatible client loads, alongside agents/, references/, scripts/ and tests/. There is no server component in this repository and no MCP server to run. The README states plainly that the Skill calls the TourMind API directly over HTTPS.

That shape matters for two reasons. First, deployment is trivial: cloning a folder into a skills directory is the whole installation. Second, every network call leaves the client process and goes to TourMind, so the agent's behaviour is bounded by what the API returns. The README's phrase "evidence-based match reasons" is a hint about the design intent: the agent is supposed to justify a recommendation from returned data rather than from its own priors.

The verification step is the most interesting mechanism. The README describes a recheck of the selected room's price and availability before booking. Anyone who has worked with supplier inventory knows why: rates move between search and purchase, and a booking attempt against a stale rate is a support ticket. The skill encodes that ordering, search, then recheck, then book, rather than letting the model decide when to trust a cached number.

The result-link feature is a second design choice worth noting. Links are described as expiring, repeatable and read-only, and they avoid exposing the Skill Token. That implies a server-side handle rather than a serialised query, which is the right call for anything a customer might forward.

Installing the skill and running a first search

The README calls this a one-minute install. Create a Skill Token at tourmind.com/user/skill-token while signed in, then install the repository into your client. Clients with a Skills interface take the Git URL directly:

https://github.com/tourmind-com/Tourmind-Booking-Skills.git

If your client loads skills from the filesystem instead, clone into its personal skills directory. The README shows this form, where CLIENT_SKILLS_DIR is replaced with the path your client expects:

CLIENT_SKILLS_DIR="<your-client-skills-directory>"
mkdir -p "$CLIENT_SKILLS_DIR"
git clone https://github.com/tourmind-com/Tourmind-Booking-Skills.git "$CLIENT_SKILLS_DIR/tourmind-booking"

The documented locations are ~/.workbuddy/skills for WorkBuddy and ~/.claude/skills for Claude Code. For OpenAI Codex the README points at the Skills interface or "the local directory supported by your Codex version", which is the one place the instructions stay vague, and you should confirm against your own Codex build before assuming a path.

Next, put the raw token in a file named skill_token.txt inside the installed tourmind-booking folder, and lock it down on macOS or Linux:

chmod 600 skill_token.txt

The README warns never to commit skill_token.txt and notes it is covered by .gitignore. After that, reload skills or restart the client. No local MCP server is required. A first request can be as small as asking for a hotel in a named city; the README's own examples are far longer, combining itinerary planning with a live search and a stated nightly budget, and they end with "Do not book yet", which is a sensible default posture for a first run.

Where the skill is the wrong tool

The dependency on a TourMind business account is the first real constraint, and the README states it without apology. If you are an individual developer experimenting, the README redirects you to a different Skill version for your user type, which means this repository may not be the one you should install at all.

The second constraint is the token model. A raw token sits in a plain text file inside the skill directory. The README mitigates this with chmod 600 and a .gitignore entry, and the result links avoid leaking the token. Neither measure helps if the host machine or the agent runtime is shared, or if a client indexes the skills directory into a context window. Anyone planning multi-tenant use should treat the token file as a secret with a blast radius, not as configuration.

The third is client compatibility. The README lists WorkBuddy, OpenAI Codex, Claude Code, Agent Skills-compatible clients that can load a root SKILL.md and make outbound HTTPS POST requests, and MCP-capable clients via a separate TourMind Booking MCP package. That is a broad list, but the condition attached to the generic entry is doing real work: a client that cannot make outbound HTTPS POST calls cannot use this skill, whatever else it supports.

Finally, the README does not document rollback behaviour, rate-limit handling, or what happens when a booking succeeds at the supplier but the payment step fails. Those are the failure modes that matter most in travel, and their absence from the documentation is worth weighing before you put this in front of paying customers.

TourMind Booking Skills compared with the TourMind Booking MCP package

The obvious alternative is not a competitor but a sibling: the README points MCP-capable clients at the TourMind Booking MCP package at github.com/tourmind-com/Tourmind-Booking-MCP. The difference is the integration model. This repository is a skill, so the client loads SKILL.md and the agent calls the API directly over HTTPS with the token file on disk. The MCP package exposes the same booking domain as MCP tools, which typically means a server process sits between the client and the API and the tool surface is declared rather than described in a skill document.

Which one you want depends on your client. If your agent already speaks MCP and you prefer a declared tool schema with a process you control, the MCP package is the natural fit. If your client loads skills from a directory and you want the smallest possible footprint, no local server and no process to supervise, this skill is the lighter option. The README presents them as complementary rather than ranked, and that framing is accurate.

Beyond the sibling package, the honest comparison is to a direct API integration. Building against the TourMind API yourself gives you control over retries, idempotency and payment handling, none of which the README describes here. What you give up is the prompt-level behaviour: the candidate narrowing to five verified options, the match reasons, the result links. Whether that prompt layer is worth a dependency is the actual decision.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-09, which is recent enough that the project is being worked on. Two releases are listed: v1.0.0 on 2026-08-05 and v1.0.4 on 2026-08-18. The gap between them is thirteen days and four patch versions, which suggests an active early phase rather than a settled API. Plan for the skill document and the scripts/ directory to change under you.

Upgrade cost is low in absolute terms because the install is a git clone. Pulling a new version is a directory update, and the token file stays put. The risk is behavioural rather than mechanical: an agent skill's output depends on the prompt text in SKILL.md and the helper code in scripts/, so a patch release can change how the agent phrases a recommendation or which fields it surfaces without any change to your own code. If you have tests that assert on agent output, they will catch it. If you do not, you will find out from a user.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and it does not, on its own, grant you anything from TourMind's API. The token, the account, and whatever commercial terms attach to the booking service are separate, and the README does not describe them. Read the account terms before assuming the MIT licence covers your intended use.

Editorial conclusion

Adopt it if you already have a TourMind business account and an AI client that loads a root SKILL.md, because the whole integration is a token file and outbound HTTPS POST calls. Do not adopt it if you need a self-hosted, offline, or token-free booking flow, or if you cannot hold a business account. Before building anything on it, verify three things in the repository: how skill_token.txt is resolved inside scripts/, which payment providers the booking flow actually reaches, and whether your client's skills directory matches one of the documented paths.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tourmind-com/Tourmind-Booking-Skills on GitHub