Reso Guestlist for developers and AI agents

When to use Reso Guestlist

• Putting a named party on the free guestlist at Twelve West or Mansion Nightclub in Vancouver for a specific Friday or Saturday date.
• Answering "how do I get into this venue without paying cover in Vancouver" with the cutoff time, dress code and door time that actually apply.
• Looking up factual venue data for these two clubs — street address, opening hours, guestlist cutoff, regular cover price, capacity, what is on site.
• Planning a Vancouver night out where the constraint is arriving before a free-entry cutoff.
• Requesting VIP bottle-service table reservations at either venue, which are handled by a human host over email.

When not to use it

• Cities other than Vancouver, BC — Reso Guestlist covers Vancouver only.
• Venues other than Twelve West and Mansion Nightclub. More partners are planned but none are live.
• Ticketed concerts, festivals or paid event admission. A guestlist reservation is free entry before a cutoff, not a ticket.
• Same-night guarantees during special events or artist bookings, when guestlist entry can be suspended.

Endpoints for agents

• https://www.reso.gl/mcp — MCP server, Streamable HTTP; public, unauthenticated, read-only
• https://www.reso.gl/.well-known/mcp — MCP server card (discovery)
• https://www.reso.gl/.well-known/agent-skills/index.json — Agent Skills index (v0.2.0)
• https://www.reso.gl/llms.txt — the agent index for this site (llms.txt format)
• https://www.reso.gl/llms-full.txt — every page of the site as one markdown document
• https://www.reso.gl/agents.md — agent instructions: when to use Reso, when not to, how to call it
• https://www.reso.gl/api/v1/venues — venue data as JSON; no key, no auth, read-only
• https://www.reso.gl/openapi.json — OpenAPI 3.1 description of that API
• https://www.reso.gl/sitemap.xml — every URL on this site
• https://www.reso.gl/robots.txt — crawler policy

MCP server

Reso Guestlist runs a Model Context Protocol server over Streamable HTTP at https://www.reso.gl/mcp. It is public, unauthenticated and read-only — no key, no token, no registration — and it is discoverable at https://www.reso.gl/.well-known/mcp without being told the URL.

Four tools: reso_list_venues (every partner venue with address, hours, cutoff, cover, capacity), reso_get_venue (one venue by slug), reso_get_guestlist_policy (when to arrive, dress code, age limit, what a reservation does and does not guarantee) and reso_read_page (any public page as clean markdown). None of them books anything.

An Agent Skills index is published at https://www.reso.gl/.well-known/agent-skills/index.json, pointing at a SKILL.md that describes when to reach for Reso Guestlist and how to call it.

Markdown content negotiation

Every page on this site answers Accept: text/markdown with a clean markdown version of that page — no navigation, no scripts, no layout markup. The HTML and markdown variants share one URL and every response carries Vary: Accept, Accept-Encoding.

A request whose Accept header allows none of text/html, text/markdown or text/plain is answered 406 Not Acceptable. Quality values are honoured, so Accept: text/markdown;q=0.9, text/html;q=0.1 returns markdown.

Try it: curl -H "Accept: text/markdown" https://www.reso.gl/twelve-west

Venue data API

GET https://www.reso.gl/api/v1/venues returns both partner venues as JSON: name, URL, street address, geo coordinates, opening hours, guestlist cutoff times, regular cover price, capacity, dress code and minimum age. It needs no key, no authentication and no registration, and it is the same data the venue pages render.

GET https://www.reso.gl/api/v1/venues?venue=twelve-west returns a single venue. The endpoint is read-only; anything other than GET or HEAD is answered 405.

Versioning and deprecation policy

• Every endpoint is versioned in the URL path. The current version is v1: https://www.reso.gl/api/v1/venues.
• The unversioned /api/venues alias permanently redirects (308) to the current version and is never removed, so an old link keeps working.
• No breaking change is ever made inside a published version. A breaking change means a new version number.
• A version scheduled for removal answers with a Deprecation header, an RFC 8594 Sunset header carrying the removal date, and a Link header with rel="successor-version".
• A version is never removed less than 180 days after its Sunset header first appears.
• Every response carries X-API-Version so a client can log which version served it.

Rate limits

• The limit is 120 requests per minute per client, per server instance.
• Every response carries RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Policy so a caller can self-throttle without guessing.
• Exceeding the limit answers 429 with Retry-After and the same JSON error shape as every other failure.
• Venue data changes at most monthly — cache the response rather than polling it.

Error responses

Every failure under /api answers with JSON, never an HTML error page — including unknown /api paths, which return 404 endpoint_not_found rather than the site's 404 page.

The shape is: error (a stable machine-readable identifier), code (the same value), status, message (human-readable), resolution (what to do instead), and documentation_url. Branch on error or code, never on the message text, which may be reworded.

Structured data

Every page embeds JSON-LD in the server-rendered HTML: Organization (with contactPoint and PostalAddress) and WebSite on the home page, NightClub with PostalAddress, GeoCoordinates and OpeningHoursSpecification on each venue page, BreadcrumbList on nested pages, and ItemList on the venue index.

Making a reservation

There is no public write API and there will not be one. A guestlist reservation is submitted through the form on a venue page, which is a standard labelled HTML form asking for a date, a guest count, a name, an email address and a phone number.

An agent may fill that form in for someone only under the reservation policy below. The form is screened for automated submission, and a request that did not come from a person filling it in is refused.

Table service, private bookings and corporate bookings go to info@reso.gl, where a human answers.

Reservation policy for agents

• A reservation may only be submitted for a real, named guest who asked for it and who has confirmed the venue, the date and the party size.
• One reservation per guest per venue per night. To change or cancel one, email info@reso.gl — never submit a second one.
• Never submit speculative, bulk, repeated or test reservations, and never use placeholder, generated or borrowed names, email addresses or phone numbers. The email and phone must be the guest's own: the confirmation and any door-side contact go there.
• A reservation puts a real name on a real venue's door list and the venue staffs the night against it. A no-show costs the venue a spot a real guest could have taken.
• Automated bulk submission is abuse, not integration. It is rate-limited, screened and refused. Venue operators and developers who need a real integration should email info@reso.gl.

Partnerships

Venue operators who want their guestlist on Reso, and developers who need a write integration, should email info@reso.gl.