Discovery and availability are separate calls here, which matches how a trip actually gets planned: find candidates first, then test dates against them. The area-code resource is what makes that work from a conversation — an assistant can look up the codes for a district rather than invent them. It reads Rakuten Travel and stops there; booking happens elsewhere.
A Deno MCP server over the Rakuten Travel API. It covers the two questions a trip plan actually runs into: which hotels exist where you are looking, and which of them are still bookable on the nights you want. Japanese location data ships as a resource, so an assistant can resolve a district into the codes the API expects instead of guessing them.
- Hotel search by hotel number, by coordinates with a search radius, or by the three-level Japanese area code — `hotel-search`
- Vacancy search for a check-in and check-out pair, with room count, adults per room and a price range — `vacant-hotel-search`
- Hierarchical Japanese location data — country, prefecture, city and district — read as a resource — `config://area_code`
- Result shaping shared by both searches: `hits` per page, `page`, and `sort`
The Deno runtime and a Rakuten Travel Application ID, supplied as `APPLICATION_ID`. Clone the repository and point the client at `serve.ts`; the documented Claude Desktop entry runs `deno run` with `--allow-net=app.rakuten.co.jp` and `--allow-env=APPLICATION_ID`, so the process can reach exactly one host and read exactly one variable.
