TourMind Booking Skills: An Agent Skill That Books Hotels Through a Token, Not an MCP Server
AI agent skill for end-to-end hotel search and booking—compare live rates across leading OTAs and hotel suppliers, verify availability, book stays, and manage reservations, cancellations, and payments via the TourMind API.
At a glance
- What is it?
- TourMind's MIT-licensed agent skill gives a client hotel search, rate comparison, booking and payment against the TourMind API. It is a credential file plus a SKILL.md, and its real constraint is that the token is the whole product.
- Who is it for?
- Adopt TourMind Booking Skills if you already have a TourMind business account, your agent client can load a root SKILL.md and make outbound HTTPS POST requests, and you want booking without running a local MCP server. Do not adopt it if you need supplier-neutral inventory, if you cannot store a live payment credential on the agent host, or if your client only speaks MCP, in which case the separate TourMind Booking MCP package is the path.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap TourMind Booking Skills fills between an itinerary and a confirmed reservation
An agent that can plan a trip is not an agent that can book one. The README's own example prompts make the split explicit: the client is told to use its own web research and itinerary-planning abilities to compare fishing areas or ski resorts, and only then to call TourMind for live hotel inventory. The skill exists for that second half. It resolves cities, hotels, landmarks, stations, addresses and ski areas without inventing coordinates, searches up to 20 hotel candidates, queries matching live room products, and narrows them to five verified options. That cap is a product decision, not a technical one. Twenty candidates is enough to cover a city, and five results is a size a conversation can actually hold. The audience is travel businesses and developers who already have a TourMind account and want booking inside an agent, rather than a separate booking site. The README points individual users and developers at a different TourMind Skill version for their user type, which tells you the business account is the intended entry point.
How the skill reaches live rates: a token file, HTTPS POST, and a verify step before payment
The architecture is deliberately thin. There is no local server. The README states that this Skill calls the TourMind API directly over HTTPS, and that no local MCP server is required. The client loads a root SKILL.md and makes outbound HTTPS POST requests. Credentials live in a file named skill_token.txt inside the installed tourmind-booking folder, containing only the raw token. The workflow the README describes runs in a fixed order: resolve the place, search candidates, query live room products, compare nightly and stay-total rates across OTAs and hotel suppliers including cancellation and inventory status, then recheck the selected room's price and availability before booking. That recheck is the part worth noticing. Rates and availability move, so the skill treats the earlier comparison as advisory and the pre-booking recheck as authoritative. Booking, order query, cancellation and payment follow, with Stripe, WeChat Pay or Alipay as the payment starters. Result links are described as expiring, repeatable and read-only, and are built so the Skill Token is not exposed in them.
Installing it: a clone, a skills directory, and a chmod that matters
The README gives a one-minute install. Create a Skill Token at tourmind.com/user/skill-token, or register a business account at tourmind.com/admin/skillSignup. Then either import the repository URL through your client's Skills interface, or clone it into the client's personal skills directory. The README's shell example is a clone of https://github.com/tourmind-com/Tourmind-Booking-Skills.git into a directory named tourmind-booking under CLIENT_SKILLS_DIR. The listed personal directories are ~/.workbuddy/skills for WorkBuddy and ~/.claude/skills for Claude Code. For OpenAI Codex the README says to use the Skills interface or the local directory supported by your Codex version, which is a hedge rather than an answer. After cloning, create skill_token.txt in the installed folder, paste only the raw token, and run chmod 600 skill_token.txt on macOS or Linux. Then reload Skills or restart the client. The README states the file is excluded by .gitignore and must never be committed. That chmod is the only access control the material describes, and it protects against other local users, not against the agent itself.
The token is the weak point, and the README knows it
A plaintext credential in a folder that an agent reads is a different risk profile from an OAuth flow with scoped, revocable grants. The README's advice, never commit skill_token.txt and keep it out of result links, addresses leakage through the repository and through shared links. It does not address what happens when the agent process itself is compromised, when the host is shared, or when a prompt injection inside a hotel description or a search result convinces the agent to call the cancellation or payment endpoint. The skill can create bookings, cancel orders and start payments, and the material does not describe a confirmation gate, a spend ceiling, or a per-action approval step. Any deployment that lets an untrusted input reach those endpoints is carrying risk the documentation does not quantify. Treat the token as a payment credential, because the payment endpoints it unlocks make it one.
Where this is the wrong tool
The skill is bound to TourMind. The README frames the rate comparison as comparing across leading OTAs and hotel suppliers, and that comparison happens inside TourMind's aggregation, not by querying each supplier directly. If your requirement is supplier-neutral sourcing, contract rates you negotiate yourself, or inventory TourMind does not carry, this skill cannot deliver it, and no configuration key changes that. A second boundary is client capability. The README lists Agent Skills-compatible clients as supported when the client can load a root SKILL.md and make outbound HTTPS POST requests. A client that only speaks MCP cannot load this repository at all; the README directs those users to the companion TourMind Booking MCP package. A third boundary is the account type. The README explicitly separates business accounts from the skill version intended for developers and individual users, so installing the wrong one is a documented failure mode rather than an edge case. Finally, the five-result cap and the twenty-candidate search are fixed by the skill's design. If your use case needs a full market scan, this is not the layer for it.
TourMind Booking MCP versus the skill: same API, different plumbing
The only alternative named in the material is TourMind's own MCP package, at github.com/tourmind-com/Tourmind-Booking-MCP, listed for MCP-capable AI clients. The difference is where the integration lives. The MCP package runs as a server that the client connects to, which is the standard route for clients built around the Model Context Protocol. The skill skips that layer: the client loads SKILL.md and posts to the TourMind API directly, and the README states no local MCP server is required. For a Claude Code or WorkBuddy user, the skill means one clone, one token file and a restart. For an MCP-only client, the skill is simply not loadable. The trade is operational surface against reach. Fewer moving parts on one side, a narrower set of compatible clients on the other. If you are choosing between them, the deciding question is your client, not the feature list, because both sit on the same TourMind API.
Maintenance, releases and what the MIT licence does not cover
The repository is MIT-licensed, which covers the skill code in the repository. It does not cover the TourMind API, the inventory behind it, or the account terms attached to a Skill Token; the README's instruction to register a business account and to use the skill version matching your user type sits outside the licence grant. The release history in the material is short and recent: v1.0.0 on 2026-08-05 and v1.0.4 on 2026-08-18, with the last push to the default branch on 2026-09-09. Four point releases inside two weeks of the first tag is a fast early cadence, and it means the surface you install today may shift. Upgrading means re-cloning or re-importing the repository and confirming the token file survived, since skill_token.txt lives inside the installed folder and is gitignored. The README is maintained in four languages (English, Simplified Chinese, Japanese, Spanish), which suggests the documentation is treated as part of the product rather than an afterthought, but the material gives no deprecation policy, no versioning scheme for the API itself, and no statement about how clients should pin a release. The homepage at tourmind.com/skills is the place to check for that.
Editorial conclusion
Adopt TourMind Booking Skills if you already have a TourMind business account, your agent client can load a root SKILL.md and make outbound HTTPS POST requests, and you want booking without running a local MCP server. Do not adopt it if you need supplier-neutral inventory, if you cannot store a live payment credential on the agent host, or if your client only speaks MCP, in which case the separate TourMind Booking MCP package is the path. Verify three things before writing any integration code: that your account type matches the skill version you install, that your client's personal skills directory is the one the README lists for it, and that a search returns real room products for a test city before you let the agent reach the booking step.
Community notes