tock-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| tock_list_metrosA | List Tock cities/metros (name, slug, business count, country/state). Use a metro slug with tock_search_restaurants. By default only metros with bookable venues are returned. |
| tock_search_restaurantsA | List / search restaurants in a Tock metro. Pass a metro slug (from tock_list_metros, e.g. "chicago") and an optional text query. Returns venues with cuisine, price band, neighborhood, and their Tock slug (use it with tock_get_restaurant / tock_get_availability). Does NOT include bookable slots. |
| tock_get_restaurantA | Get details for a Tock venue by slug: name, cuisine, price band, location, description, and its bookable experiences (with prices and party sizes). Slug comes from tock_search_restaurants (or a exploretock.com/{slug} URL). |
| tock_get_availabilityA | Get a venue's bookable calendar: each experience (seating/menu) with its price, party sizes, cancellation policy, plus the dates and times the venue is open. Tock returns the full open-date/time set; pass a date to focus the summary. Reservations are prepaid tickets — this MCP does not book; open the venue on exploretock.com to reserve. |
| tock_list_reservationsA | List the signed-in user's Tock reservations (upcoming, past, or canceled) with venue, date/time, party size, and experience. Requires a browser tab signed in to exploretock.com via the ContextMint Bridge extension. |
| tock_get_profileA | Get the signed-in user's Tock account identity (name, email). Requires a browser tab signed in to exploretock.com via the ContextMint Bridge extension. Derived from your reservation records, so it needs at least one reservation on the account. |
| tock_verify_reservationA | Verify that a Tock reservation actually exists, by re-querying the account's own reservation lists (upcoming, canceled and past) and returning an explicit verdict. Use this after ANY booking attempt — a success screen or screenshot is not proof that a booking landed. Returns verdict |
| tock_healthcheckA | Round-trips a small public www.exploretock.com URL (/robots.txt) through ContextMint Bridge (your signed-in browser tab) and returns diagnostics: the bridge's role (host/peer/null), port, version, the extension link (linked / pair pending / not attached / never answered), the elapsed round-trip time, and a plain-English hint distinguishing 'bridge never came up' from 'extension not connected' from 'this browser can't serve a capability' from 'real www.exploretock.com-side problem'. Read-only, no auth required. Call this when a real tool fails and you want to know which hop broke. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Every tool targets a distinct resource/action: reservation listing vs. availability vs. metro listing vs. profile vs. verification vs. venue detail vs. search vs. bridge diagnostics. There is no meaningful overlap; even the closely related get_restaurant/search_restaurants and list_reservations/verify_reservation have clearly separated roles.
Almost all tools follow a clean tock_verb_noun pattern (list_reservations, get_availability, list_metros, get_profile, verify_reservation, get_restaurant, search_restaurants) with a consistent tock_ prefix. Only healthcheck breaks the verb_noun convention, a minor deviation.
Eight tools is well-scoped for a restaurant discovery/verification server, and each one earns its place (discovery, availability, reservations, profile, verification, diagnostics). Nothing feels redundant or padded.
The read surface is solid for discovery and checking reservations, but the server is explicitly read-only: it cannot book or cancel a reservation, even though verify_reservation acknowledges booking attempts and canceled reservations exist. Menus/reviews are also absent, leaving notable gaps in the reservation lifecycle.