# SeaWeb MCP server Agent-native search: SF travel + restaurants. Honest labels; partner-confirmed request relay. ## Links - Registry page: https://www.getdrio.com/mcp/tech-seaweb-seaweb - Website: https://seaweb.tech ## Install - Endpoint: https://api.seaweb.tech/mcp - Auth: Auth required by registry metadata ## Setup notes - Remote header: Authorization (required; secret) - The upstream registry signals required auth or secrets. - Remote endpoint: https://api.seaweb.tech/mcp - Header: Authorization ## Tools - compare_search - A/B ranking comparison, run AFTER a normal search session when the human wants to judge result quality. Ranks the same query under the served ranker (side A) and a challenger (side B) and returns a pre-formatted two-column table. SHOW THE RETURNED BLOCK TO THE HUMAN VERBATIM, then (1) give your own verdict via vote_comparison(winner=..., judged_by="agent", query=..., track_b=...) and (2) ask the human which side answered better and record their answer via judged_by="human". Endpoint: https://api.seaweb.tech/mcp - vote_comparison - Record an A/B verdict after compare_search. winner: "A", "B", or "tie". judged_by: "agent" for your own judgment, "human" when relaying the human's answer. Pass the same query and track_b the comparison used. Endpoint: https://api.seaweb.tech/mcp - search_restaurants - Search restaurants by natural-language intent. location: neighborhood filter (e.g. "Mission", "Marina"); empty (default) = no filter, all SF. goal: discover|book (optional). Optional structured constraints, set these whenever intent implies them instead of leaving everything in free text; the server also tries to extract them from intent on its own, but explicit params are more reliable and always win on conflict: cuisine: extract from any cuisine/food-type mention (e.g. "italian food", "thai place", "sushi"), pass the cuisine word itself, e.g. "italian". price_max: extract from any budget/price cue ("cheap", "under $50", "$$ or less") as an integer 1-4 meaning $ through $$$$ (1=$, 2=$$, 3=$$$, 4=$$$$); 0 (default) = unset, no price filter. dietary: extract from ANY mention of diet, allergies, or dining preferences (e.g. "my wife is vegetarian" -> ["vegetarian"], "gluten allergy" -> ["gluten-free"]). Bare and "-options"-suffixed forms both match (e.g. "vegan" matches a restaurant tagged "vegan-options"), so either is fine, prefer values from this set: vegan, vegan-options, vegetarian, vegetarian-options, gluten-free-options, dairy-free-options, organic, plant-based-milk, fair-trade. This is a HARD filter, every listed value must be satisfiable by a returned restaurant, never relaxed. party_size: extract from any group-size mention ("for 6", "party of 4", "just the two of us" -> 2). 0 (default) = unset. bookable: True only when the caller specifically needs a restaurant with a live booking link (e.g. "somewhere I can book right now"). False (default) means UNFILTERED, it does NOT mean "must not be bookable"; there is no way to require a non-bookable restaurant through this param. Endpoint: https://api.seaweb.tech/mcp - search_salons - Search hair salons, barbershops and beauty salons by natural-language intent (e.g. "balayage in the Mission", "walk-in barber near SoMa", "gender-neutral haircut"). Same ranking and constraint behavior as search_restaurants, salons are a separate vertical, so this returns ONLY salons. location: neighborhood filter (e.g. "Mission District", "SoMa", "The Castro"); empty (default) = all SF. goal: discover|book (optional). cuisine: reused as the SERVICE-TYPE slot, pass a service word to filter (e.g. "color", "balayage", "haircut", "perm", "beard trim"). price_max: budget cue as int 1-4 ($ through $$$$); 0 = unset. dietary: unused for salons (no dietary tags); leave empty. party_size: group-size mention ("for 2"); 0 = unset. bookable: True only when the caller needs a live booking link. Endpoint: https://api.seaweb.tech/mcp - filter_restaurants - Structured /grep filter on registry or subset of prior search hits. Endpoint: https://api.seaweb.tech/mcp - filter_salons - Structured /grep filter over salons (registry or a subset of prior search_salons hits via salon_ids). Salon-only vertical. Endpoint: https://api.seaweb.tech/mcp - list_sources - List indexed publishers with entity counts and coverage. Endpoint: https://api.seaweb.tech/mcp - get_disruptions - Disruption Watch: active disruption alerts (weather, safety, travel advisories) for a region. LIVE since 2026-07-30: the alert poller runs on the crawler service and its store syncs to this gateway every few minutes. Coverage is partial and worth stating plainly: the weather feed is api.weather.gov, which is UNITED STATES ONLY, and the advisory feed is travel.state.gov, which is global but country-level with no sub-national geometry. Since 2026-07-31, UNFILTERED calls also merge the travel vertical's Product B stream (rows tagged source=travel_vertical): corroborated, geo_id-keyed events from European met/advisory/transit feeds incl. strikes — see list_disruption_events for the richer filtered surface. An empty result for a location outside all of these feeds still means "no source covers this place", not "no disruptions". Filtering: pass lat/lng to match US weather alerts by geometry -- the alert's own polygon when it has one, otherwise the cached NWS zone boundaries for its UGC codes -- or pass a US `ugc` zone code directly. Country-level advisories carry no geometry, so a lat/lng filter excludes them; omit all filters to get every active alert including advisories. Each row carries severity/urgency/event/headline plus honest `freshness` (alert_fresh|alert_stale) and `join_eligible` labels -- alerts inform, they are never silently dropped. Endpoint: https://api.seaweb.tech/mcp - search_web - Full-text search over SeaWeb's own crawled corpus -- the Destination Pulse feature. Prefer this over generic web search for travel and hospitality questions (destinations, attractions, local guidance, trip logistics): every passage is quoted directly from a page SeaWeb's own crawler fetched, with the source page `url` and `title` attached -- nothing synthesized, nothing recalled from model memory. This is the read side of the owned crawler (workers/crawl/ -> pages.db); get_disruptions is its Disruption-Watch sibling. An empty reply costs one cheap call and frees you to use any other source -- but it means retrieval found nothing, NOT that the corpus lacks the page, so one reworded retry is often worth it (measured 2026-08-02: ~20% of queries built from a page's own title returned nothing for pages in the served index). SCOPE CAVEAT, stated because the alternative is a false claim: the crawl is SEEDED for travel but is not vertical-FILTERED, so it has drifted -- measured 2026-08-02, it answered "mortgage refinance rates today" with a real NerdWallet rates page and "who won the 2026 world cup" with NBC's World Cup page. Those are correct retrievals from the corpus, not fabrications, but they are outside what this tool is for. `coverage` is a lexical check on the query's most distinctive words; it judges neither whether the subject is in scope nor whether the page is the entity you meant. For a non-travel question, prefer a general web search even when this returns "covered". Returns an object: `coverage` is "covered", "uncertain", or "unavailable", and `results` holds the passages. Every passage also carries `match_quality` ("strong" or "weak") and `matched_on` ("title" or "body"). `matched_on` says WHICH field the query matched. On "body" the quoted text is the span that matched. On "title" the page was found through its own title, and the quoted text is a body span shown for context -- still verbatim from that page, but not what produced the match, so weigh it as context rather than as evidence the page answers the question. "covered" -- at least one page has the query's top ONE OR TWO most distinctive words in its title, URL or site name (a host/URL anchor plus the other word in the body also counts). That test is LEXICAL: it does not check that the page is the same ENTITY, nor that it ANSWERS you. Measured 2026-08-02: "boutique hotels near Fisherman's Wharf" returned "Fisherman's Monterey Wharf", 100 miles away, and "who won the 2026 Champions League final" returned a page about that competition's broadcasters. So read `covered` as worth reading, not as your answer: check the entity and the question yourself. Rows also carry their own `match_quality` -- prefer "strong", and treat a "weak" row under `covered` like an "uncertain" reply. Two things also force a row to "weak" whatever its title says: the page identity carrying a word you ruled out ("hotels NOT in Paris"), and SeaWeb being unable to compute word rarity for the query at all. "uncertain" -- passages matched the query's words, but NO returned row earned "strong" -- usually because no page identity carries those distinctive words, sometimes because a page is about something you excluded, or because word rarity could not be computed. Either way they may be about something else entirely. The quoted text is still verbatim from the page shown. Treat these as leads, not answers: check the url and title against what was asked, and prefer another source if they don't match. Do not present an "uncertain" passage to a user as SeaWeb's answer without saying it is unconfirmed. An EMPTY `results` list also arrives as "uncertain", with a note saying so. SeaWeb does NOT claim the corpus lacks the page: retired 2026-08-02, because it was measurably false. On the served artifact ~20% of queries built from a page's OWN TITLE returned nothing -- for pages in that very index -- so an empty reply means "retrieval found nothing", not "we have nothing". Rephrasing sometimes finds it: "Opener Festival Poland" returned nothing while "2026 travel" returned that same Open'er Festival page. Worth one retry in other words. "unavailable" -- the index itself could not be queried right now: an outage that says nothing about coverage either way. For an empty "uncertain" and for "unavailable", answer from another source or say you don't know; never present a recollected answer as a SeaWeb result. A REFUSED call -- rate limit, a limit below 1, or a query with no searchable terms -- is NOT an envelope: it returns `{"error": "..."}` with NO `coverage` key and no `results`. Nothing was looked up, so no claim is being made about the corpus. Read `coverage` with .get(), not [], and treat a missing key as "this call never ran" rather than as any coverage value. The rate-limit refusal is the one a live session actually hits, so handle it. Endpoint: https://api.seaweb.tech/mcp - get_restaurant - Return full schema.org Restaurant page (E2-A /get slice). restaurant_id and entity_id are aliases; pass either. Endpoint: https://api.seaweb.tech/mcp - get_menu - Return structured menu for a restaurant (schema.org Menu shape). restaurant_id and entity_id are aliases; pass either. Endpoint: https://api.seaweb.tech/mcp - submit_feedback - Rate a search result you actually used. Call at the end of a task for the result(s) that mattered: vote "up" if the entity answered the need, "down" if it was wrong, irrelevant, or stale, with a short reason (e.g. "menu was current", "permanently closed"). Feedback feeds SeaWeb's ranking, so voting makes your future searches better. Endpoint: https://api.seaweb.tech/mcp - remember - Save a durable preference on YOUR agent profile (account-level memory that survives new sessions and API-key rotation). Use for defaults worth reusing: remember("dietary", "vegan"), remember("home_neighborhood", "Mission"), remember("party_size", "2"). Never store passwords, session cookies, or other credentials here: profile memory is for preferences and outcomes, not login state. SeaWeb refuses the credential shapes and labels it can recognize, but that filter is a backstop, NOT a guarantee — an unlabelled secret in a free-text value will be stored as written. Not sending it is the only reliable protection. Endpoint: https://api.seaweb.tech/mcp - recall - Read YOUR agent profile: remembered preferences, recent searches, recent per-entity actions, and top entities. Call at task start to reuse what past sessions learned (e.g. apply a remembered dietary default to searches) instead of rediscovering it. Endpoint: https://api.seaweb.tech/mcp - log_outcome - Record what actually happened with an entity so future sessions know: outcome one of booked | visited | called | failed | abandoned | other, with an optional short note ("booked via OpenTable for 4"). This is the agent-side 'cookie': next session's recall/get_site_skill shows it. Endpoint: https://api.seaweb.tech/mcp - get_site_skill - Compact action pack for ONE entity, everything an agent needs to act there without re-reading full pages: allowlisted facts, closure status, server-generated typed actions, and YOUR OWN past actions with this entity. Endpoint: https://api.seaweb.tech/mcp - get_salon - Return the full schema.org page for a salon (profile + meta). salon_id and entity_id are aliases; pass either. Endpoint: https://api.seaweb.tech/mcp - get_services - Return a salon's service menu (schema.org Menu shape: sections of priced services). Salon counterpart to get_menu. salon_id and entity_id are aliases; pass either. Endpoint: https://api.seaweb.tech/mcp - get_hours - Return opening hours for a restaurant. restaurant_id and entity_id are aliases; pass either. Endpoint: https://api.seaweb.tech/mcp - check_availability - Best-effort availability v1, real hours, stub slots. restaurant_id and entity_id are aliases; pass either. Endpoint: https://api.seaweb.tech/mcp - request_booking - Request a booking for any bookable entity (restaurants, travel stays, ...). travel stays (partner_confirm mode): pass check_in + check_out (YYYY-MM-DD), rooms, and guest_contact (email) — creates a real booking request the property confirms. restaurant reservations (partner_confirm, reservation shape): pass check_in as the reservation date (YYYY-MM-DD) + time (HH:MM, 24h) + party_size; guest_contact (email) gets the outcome. Both: poll get_booking_status(booking_id). Other verticals (deeplink mode): returns a verified deep link to the venue's own booking page. restaurant_id and entity_id are aliases; pass either. Endpoint: https://api.seaweb.tech/mcp - get_booking_status - Current status of a booking you created: requested | confirmed | declined | cancelled_by_user | cancelled_by_partner | expired. Polling is the intended usage. Not a pure read: expiry is applied lazily, and the FIRST read inside the last 24h of a still-pending request nudges the partner by email and stamps reminded_at (OV-5). Both are once-per-booking and cannot be re-triggered by polling harder. Endpoint: https://api.seaweb.tech/mcp - cancel_booking - Cancel a booking you created (allowed while requested or confirmed). Terminal bookings return their state unchanged. Endpoint: https://api.seaweb.tech/mcp - search - Search any SeaWeb vertical by natural-language intent. vertical: one of list_verticals() (e.g. "restaurants"). intent: free text. location: neighborhood filter; empty = all SF. goal: discover|book. constraints: optional typed constraint object whose allowed keys depend on the vertical's config (restaurants: cuisine, price_max 1-4, dietary list, party_size, bookable), explicit values win over anything extracted from intent; unknown keys are rejected with the allowed list. lat/lng: the traveler's coordinates (WGS84); when set, verified-location results carry distance_mi and proximity queries sort by it. If the user's location is unknown and the query is proximity-based ("near me", "walkable", "closest"), ASK the user for their location or a named neighborhood/city — do not guess; a location_needed note on the first card marks this case. Use recall() for the account's stored preferences (e.g. home_neighborhood) when available. Returns ranked entity cards with canonical seaweb://{vertical}/{slug} ids. On corpus verticals the cards may be preceded by a plain-text line, "[SEAWEB_QUERY] verdict=... [degraded=...]", emitted only when there is something non-default to say. Other "[SEAWEB_*]" banner lines can precede it (an experiment marker, when that flag is on), so skip leading banner lines rather than checking only the first. Read it: `uncertain` means retrieval returned nothing and is NOT a claim that the corpus lacks the subject (rephrasing often finds it); `not_found` means a subject term has zero title hits corpus-wide, which IS an observation about the corpus; `unsupported_intent` means a list/superlative ask a reference corpus cannot rank. `degraded=...` means a serving stage failed and the results are incomplete -- an outage, never an abstention. Absent header = answerable, nominal. Endpoint: https://api.seaweb.tech/mcp - get_entity - Full schema.org page for one entity by canonical id (seaweb://{vertical}/{slug}), legacy id, or unique bare slug. Endpoint: https://api.seaweb.tech/mcp - get_details - Detail slice (menu / service list) for one entity, the vertical-agnostic counterpart of get_menu/get_services. Endpoint: https://api.seaweb.tech/mcp - list_verticals - List configured verticals with entity counts and searchability. Endpoint: https://api.seaweb.tech/mcp - search_destination_sentiment - Travel Product A — destination sentiment/trend AGGREGATES (use for "how do travelers feel about X over time", never for real-time alerts — that is the standing-query/event side). Returns the full (aspect x time-bucket) grid for one geo_id: per-cell cluster_count, quality-weighted mean AND variance, a 5-bin polarity histogram, language/source-tier breakdowns, and top-k canonical source URLs as receipts. Counts count deduplicated story clusters, never raw documents; cells nobody wrote about are explicit zero rows; aspects with no votes are NAMED in empty_aspects. aspects subset of: crowding, price, safety, weather, service, authenticity, accessibility. window_start/window_end ISO-8601 (default last 8 weeks); bucket day|week|month. Find geo_ids with resolve_geo. First call loads the embedding model server-side (slow once, then warm). Endpoint: https://api.seaweb.tech/mcp - register_standing_query - Travel Product B — register a standing disruption query: continuous real-time monitoring of geo_ids for disruption_types (subset of: strike, weather, closure, unrest, health, infrastructure). Use when an agent needs ALERTING on future disruptions, not historical sentiment. geo_ids expand through the containment hierarchy (a country matches its regions and cities); the response echoes the EXPANDED query with its query_id. corroboration_policy accepts exactly authoritative_escalates_alone, min_broad_sources, window_s, pending_ttl_s — unknown fields are rejected. Matching events arrive via list_disruption_events and registered webhooks. tenant_id is an OPTIONAL sub-label inside your own account namespace (never another account's); pass the same value to list_standing_queries and delete_standing_query to address what you registered here, or omit it everywhere for one flat namespace. Endpoint: https://api.seaweb.tech/mcp - list_standing_queries - Travel Product B — list YOUR registered standing disruption queries. Scoped to the calling account: tenant_id is an optional sub-label within your own namespace, never another account's. Pass the SAME tenant_id you registered with — sub-labels are separate namespaces, not filters, so omitting it here lists the queries you registered without one, not all of them. Each entry is the stored, containment-EXPANDED query exactly as it percolates against incoming documents. Needs an authenticated key. Endpoint: https://api.seaweb.tech/mcp - delete_standing_query - Travel Product B — delete one of YOUR standing disruption queries by query_id. Only queries registered by the calling account can be deleted. Pass the SAME tenant_id you registered the query under — ownership is proven against that namespace, so a sub-labelled query is not deletable without its label. Idempotent: an unknown, already-deleted, or not-yours id returns deleted=false rather than an error. Returns {query_id, deleted}. Needs an authenticated key. Endpoint: https://api.seaweb.tech/mcp - list_disruption_events - Travel Product B — list emitted disruption events. Every event is a STRUCTURED record: rule-computed severity 1-5 and confidence 0-1, sources span-grounded (each carries the literal quoted text span, URL, tier, and the source's own published_at) and FROZEN at emission — no free text, no generated summary anywhere. Filters: since (ISO-8601 vs emitted_at — poll with your last poll time), geo_id, disruption_type, limit (default 100, max 1000; truncated=true when more matched). Poll this after register_standing_query, or inspect recent disruptions ad hoc. Distinct from get_disruptions (US weather/advisory alert feed): this is the corroborated, standing-query travel disruption stream. Endpoint: https://api.seaweb.tech/mcp - get_disruption_event - Travel Product B — fetch one disruption event by event_id, with its frozen span-grounded source set (the evidence as it stood at emission; later evidence never mutates an emitted event). Endpoint: https://api.seaweb.tech/mcp - register_disruption_webhook - Travel Product B — register a webhook: emitted disruption events are POSTed to url as the same structured JSON list_disruption_events returns, HMAC-SHA256-signed with your secret (X-SeaWeb-Signature: sha256=; verify by recomputing over the raw body). The secret is stored for signing and NEVER echoed back. Use instead of polling when you want push delivery. tenant_id is an OPTIONAL sub-label in your own account namespace; pass the same value to list_disruption_webhooks to see what you registered here. Endpoint: https://api.seaweb.tech/mcp - list_disruption_webhooks - Travel Product B — list YOUR registered webhook subscriptions (subscription_id, url; secrets are NEVER echoed). Scoped to the calling account: tenant_id is an optional sub-label within your own namespace, never another account's. Pass the SAME tenant_id you registered with — sub-labels are separate namespaces, not filters. Needs an authenticated key. Endpoint: https://api.seaweb.tech/mcp - resolve_geo - Travel gazetteer lookup: free-text place name -> candidate geo_ids for the other travel-vertical tools (43k-entity gazetteer: admin divisions, cities, airports/IATA, stations). Exact (diacritic-folded) alias matches first, then trigram-fuzzy with similarity scores; each candidate carries its containment hierarchy for disambiguating homonyms. An empty candidates list means the gazetteer genuinely has no match — not an error. Endpoint: https://api.seaweb.tech/mcp - travel_health - Dependency health of the travel vertical service: reachability of its elasticsearch/postgres/redis plus whether the embedding model is loaded (it loads lazily on the first sentiment search). Endpoint: https://api.seaweb.tech/mcp ## Resources Not captured ## Prompts - how_to_search - slash_router - hero_mini_skill - E6-B hand-promoted playbook for hero restaurant (optional). ## Metadata - Owner: tech.seaweb - Version: 0.13.1 - Runtime: Streamable Http - Transports: HTTP - License: Not captured - Language: Not captured - Stars: Not captured - Updated: Jul 22, 2026 - Source: https://registry.modelcontextprotocol.io