Dim Hour

What it is

Dim Hour is a city guide - the places worth your time, scored, not starred - covering more than 19,000 restaurants, bars, hotels, and venues across 24 cities. For this challenge, dimhour.com became agent-native: the page itself registers five WebMCP tools, so an agent browsing the site can search the catalog, read a venue, check what is open tonight, draft an itinerary, and hand back a booking link - without scraping a pixel.

Why this use case is a strong fit for WebMCP

Planning a night out is one of the most common things people already ask an agent to help with, but today the agent scrapes pages and guesses at what the site already knows. WebMCP lets dimhour.com hand the agent its real search, scoring, and booking data as structured tools, in the same tab where the person is browsing. The catalog is the product; WebMCP makes it callable. Because the tools are thin adapters over a production venue API, every agent answer is grounded in live data instead of page scraping.

How it creates a better user experience

One page, two users. A person browsing the Dallas guide and their agent now work on the same surface. The agent calls the site's own tools and gets back the same scored venues, hours, and booking links the UI shows - no copy-pasting between a chat window and a browser, and no agent inventing hours, addresses, or availability. The person keeps the judgment (taste, swaps, vetoes); the agent does the legwork (searching, filtering, checking, assembling). The site stays the source of truth for both of them, and saving a plan stays a human action - the tools read, they never write.

What people and agents can do together

Co-plan a night in one sitting, in one page. "Dinner in Deep Ellum for four on Friday, then cocktails within walking distance." The agent searches the scored catalog, filters to what is actually open tonight using the same rule the site's own tonight strip uses, pulls full venue records, and drafts an ordered itinerary with real booking links (Resy, OpenTable, SevenRooms, Tock) while the person watches - then interrupts: "swap the second stop for something quieter," and the agent re-plans around the constraint. Before WebMCP, the agent could read the page but not act through the site's own logic, and the person could use the site but not delegate the legwork. Now both happen at once, and the result is a plan with real reservation links attached, not a list of suggestions.

How we implemented WebMCP

The WebMCP layer is one feature-detected script, webmcp.js, loaded by the site's index.html. Each of the five tools is a thin adapter that POSTs JSON-RPC tools/call to Dim Hour's existing MCP server (mcp.dimhour.com) and passes the result straight through:

• search_venues - one strong keyword plus city, neighborhood, cuisine, score floor, and price ceiling filters
• get_venue - the full record: hours, score, booking path, awards
• find_open_tonight - venues with a happy hour or late kitchen, best score first, using the same definition the site's own "tonight" strip uses, so the agent and the page agree
• build_itinerary - an ordered multi-stop plan with why and how to book each stop; saving stays a human action at /trip.html
• get_booking_link - the reservation platform and direct booking URL for a venue, returned for the agent to present; it never opens or books anything itself

The script handles the in-flight standard rename (document.modelContext first, navigator.modelContext fallback) and is a silent no-op where no WebMCP host exists. No authentication; the tools expose only public, read-only catalog data. What predates the hackathon: the venue catalog, scoring pipeline, MCP server, and site. What was built during the submission window: webmcp.js, the tool schemas, and the index.html include - the public repo's README draws that line explicitly, with dated commits.

Challenges we hit

Search results deliberately do not carry hours - only full venue records do - so "open tonight" meant ranking candidates first, then reading the top few individually rather than filtering a field that is not there. Booking links live in the page's own catalog rather than the API, so the booking tool merges both sources and says so honestly when a city is not loaded. The verification suite now asserts substance (tonight actually finds venues; a booking link equals the catalog's own URL), not just shape - because an early version passed every check while two tools quietly returned nothing.

Built With

• chatgpt
• cloudflare
• javascript
• mcp
• openai
• webmcp