Booking.com takes 15-25% commission and owns the customer relationship. I run a small
network of independent establishments in Luxembourg, and I wanted AI agents to be able to
book them directly — machine-native, at the establishment's exact direct price.
So I built Adaga Network — Direct Booking Federation: one MCP endpoint that fans out
to every establishment in the network.
The architecture
- Each establishment runs the same open template: an
mcp.jsmodule mounted on/mcpinside its existing Express app. No new port, no new service — a pure proxy to the app's own REST API. - The federator (
adagasolutions.lu/network/mcp) is a Streamable HTTP stateless MCP server that keeps a registry of tenants and calls their MCP tools in parallel (6s timeout per tenant, dead tenants are skipped and reported).
3 tools cover the whole journey:
| Tool | What it does |
|---|---|
network_directory |
Lists every establishment (brand, type, city, slug) |
network_search |
Fan-out live availability + exact total prices, sorted |
network_book |
Creates a REAL booking, hands secure card payment to the human |
The payment hand-off is a feature
The agent never touches card data. network_book returns payment instructions; the human
completes a Stripe Checkout; unpaid bookings expire automatically. Booking confirmed only
after payment — and a 409 if the room became unavailable in between.
What I learned writing tool descriptions
The tool description is the #1 selection criterion for agents. After running the tools
through a TDQS audit, the fixes that mattered:
- State auth requirements, rate limits and pagination explicitly (mine: none, none, none)
- Put the full workflow in the transactional tool's description
- Describe every optional input format (phone: international format, extras: integer ids)
- Units everywhere: prices in euro cents, dates YYYY-MM-DD, max 30 nights
Distribution
- Official MCP Registry:
io.github.jeffreyturov-dev/adaga-network - Glama connector with health checks (hourly) — a watchdog pings the endpoint every 10 min
- The honest pitch: no OTA commission — the traveler pays the exact direct price, the establishment keeps its customer.
Salons and restaurants join the network next. If you run an independent establishment and
want AI agents to book you directly, the onboarding template takes 2-4 hours.
Top comments (2)
Good point on the payment hand-off: keeping card data away from the agent is the right call. One question on the fan-out: when a tenant hits the 6s timeout and is skipped, does network_search flag it as 'unknown' rather than 'unavailable'? Otherwise an agent could conclude a room is gone when the tenant was just slow.
Great catch — and no: a skipped tenant never shows up as 'unavailable'. network_search puts every tenant that times out or errors into a separate top-level
errorsarray (tenant slug + reason, e.g. 'timeout 6000ms'), fully disjoint fromoffers. A slow tenant's rooms simply don't appear in offers at all, so the agent can't conclude the room is gone — and the response tells it explicitly that coverage was partial (tenants_queried vs errors). Your point is exactly why errors are a first-class field instead of a silent skip.