The Yenta connector

Yenta is a directory of hospitality venues — restaurants, bars, cafés — and of travel destinations such as cities and regions, publishing each partner's own approved information to AI assistants over the Model Context Protocol (MCP).

Everything Yenta serves comes from the partner. A venue uploads its menu and FAQs, or a destination its catalogue of listings, events and guides; an authorized person at that partner reviews and approves it, and only then does the content become publicly readable. Nothing is scraped, inferred or generated. Every answer carries a reference to the exact approved revision it came from, so an assistant can tell someone how fresh the information is.

The directory reads; it does not act. It cannot take a booking, place an order, or send anything to a venue on your behalf. Its one write is send_feedback, which stores a report for Yenta's team and nothing else.

Why this exists

Much of what people ask about restaurants and bars is poorly represented on the open web. Menus are often published as PDFs or images, dietary and allergen details are rarely written down at all, and hours, events and booking links are spread across third-party listings that go out of date.

Yenta publishes each venue's own information in a structured, machine-readable form: menu items with prices and dietary tags, hours, events, FAQs and the venue's official booking and ordering links. Every record is supplied or approved by the venue and reviewed before it is published, and every answer carries a source reference with the approval time, so a claim can be checked against the venue's own statement and its freshness.

It is built for two kinds of question:

• Discovery: which places serve a dish, suit a dietary need, or are open at a given time in a given city.
• Fact checking: whether a specific venue's menu, hours, prices or policies are what another source says they are.

Yenta does not accept payment for placement, take bookings or collect personal data. Where a venue has no published record here, Yenta has no answer for it.

Three endpoints

Yenta is not one server but three shapes of server, and all speak Streamable HTTP MCP at the path /mcp.

Start at the directory, and in most cases stay there. search and search_venues return, for every result, its slug or id and its citable page; a live venue or destination also carries its mcp_endpoint (a venue also carries its capabilities). You do not have to follow that URL to read the partner: the directory's venue_* and destination_* tools read a named venue or destination in place, so one connection completes the whole journey. An mcp_endpoint is that partner's own server, read-only unless its booking.method is live; nothing you ask of Yenta needs it.

Yenta is information only: nothing is booked through it. Where a venue takes reservations, its result carries booking.url, the venue's own booking page.

Directory tools: finding a partner

The directory publishes seventeen tools: sixteen reads, each with one obvious job, and send_feedback (see Sending feedback, below).

• search — everything by name or keyword: venues, travel destinations and the places listed inside a destination. It takes one query string and returns results of id, title and url — the shape ChatGPT connectors and deep research expect.
• fetch — the full page for one search result id, as Markdown text with its citable url and a little metadata (kind, city or area, content version).
• search_venues — search published venues by text (name, alternate names, description, cuisine, neighbourhood and city; every word must match), and filter by city, cuisine, price band, neighbourhood, whether the venue takes reservations, proximity to a point, opening hours and experiential facets (vibe, dietary and more). A value that matches nothing comes back with the valid values in the reason. Each result carries the venue's capabilities and, when it is live, its mcp_endpoint.
• list_cities — the cities that have at least one published venue, plus the travel destinations it also covers, such as Los Cabos.
• search_menus — search menu items across every published venue at once, each result tagged with the venue it came from.

Directory tools: reading a partner by name

These read a named venue or destination without reconnecting anywhere. Give a name (with a city, if the name is ambiguous) or a slug; if a name matches more than one partner, the answer comes back with the candidates so you can choose.

• venue_profile — a named venue's profile: description, cuisine, price band, neighbourhood, address and map link, phone, opening hours (with whether it is open now and today), booking, its official booking, ordering, delivery and website links, attributes, a menu summary, its capabilities and its citable page (yenta_page_url). A slug answers for every published venue. Each block appears only when the venue publishes the family behind it: hours and attributes need its profile, the menu summary its menu, the dietary block its dietary options, and the website its links.
• venue_menu — a named venue's menu by text (every word must match), required dietary tags, allergens to avoid and a maximum price. Without filters it also returns the dietary tags the venue declares, with up to three example dishes per tag, and allergen counts.
• venue_faq — a named venue's published FAQs.
• venue_events — a named venue's dated events overlapping a window, defaulting to from the venue's own local today.

Each venue chooses what it publishes. If a venue_* tool reports the venue is not available, check the capabilities that venue_profile returns for its slug — the venue may simply not publish that. A booking link in an answer is the venue's own booking page, for the person to open and complete themselves; nothing is booked through Yenta.

• destination_overview — a named destination's summary: counts of listings by category, events, offers, seasonality months and FAQs, the guide topics, the categories and areas listings, events and offers filter by, currency, timezone and a preview of places and events. Start here: a count of 0 means the matching read is empty.
• destination_listings — its businesses and places, by text (every word matches, in any order), category, area, tags, language, or proximity to another listing. Each business appears once, with a map_url when it has coordinates. Pass a listing's id to read its full detail, including the mcp_endpoint of its own venue when that business is itself a live Yenta venue. A filter value that matches nothing comes back with the valid values in the reason.
• destination_events — dated events overlapping a window, defaulting to from today in the destination's own timezone, optionally by text (every word matches, in any order).
• destination_offers — current deals and packages, with the partner booking link (booking_url) and the destination's own page (canonical_url) to cite.
• destination_seasonality — the best time to visit: weather and wildlife seasons (e.g. whale watching), month by month; pass an interest such as whales to keep only the months that mention it.
• destination_guide — editorial guides: weather, getting here, entry requirements, safety, and more, a few entries per page with an index of every match. Pass a topic from destination_overview's guide_topics to read one subject.
• destination_faq — that destination's published FAQs.

Sending feedback

send_feedback sends Yenta's team a report: data that is missing or looks wrong, a tool that was hard to use, or anything else. It takes a kind (missing_data, wrong_data, hard_to_use or other) and a message, plus optional tool, subject, model, client, city and purpose fields that say what the report is about and who sent it. The report is stored, never shown publicly and never written to the logs, and the answer carries a reference for it. It holds no account, no IP address and no browser or app identifier; leave personal details out of the message.

Tool names changed in September 2026

The directory went from twenty-four tools to sixteen, because assistants choose better from fewer. If you built on the old names, each one maps to a current tool:

The unified search now takes only a query and answers in the ChatGPT shape; use search_venues or search_menus for filtered searches.

Venue tools

A venue endpoint serves that one venue and nothing else.

• get_venue_profile — the venue's published profile summary.
• get_menu — the whole approved menu as nested menus, sections and items.
• search_menu — search the menu by text, by dietary tags that must all be present, and by allergens to avoid.
• get_dietary_options — every dietary tag and allergen declared on the published menu.
• get_venue_faq — search the venue's published FAQs.
• get_venue_links — the venue's official booking, ordering, delivery and website links, each tagged by kind.
• search_events — the venue's dated events overlapping a window, defaulting to from the venue's own local today.

Each venue chooses which families it publishes, so a venue endpoint lists only the tools that venue has enabled. A tool that is not enabled is absent from tools/list rather than present-and-refusing. get_menu is granted together with search_menu. The directory's venue_* tools above read the same content by name, subject to the same choices.

Destination tools

A destination endpoint — a city or region published by, for example, a tourism board — serves the same read-only, source-cited content in ten tools. Unlike a venue, a destination publishes all ten. Nine of them are the directory's matching destination_* tool under a shorter name; the tenth, search_event_spaces, is served only from the destination's own endpoint.

• get_overview — the destination's summary: counts of listings by category, events, offers, seasonality months and FAQs, the guide topics, currency, timezone, and the languages its content is available in. Call it first: its counts show which of the other reads have content.
• list_facets — the area, category and tag values to filter listings, events and offers with; filters accept a value's name or slug.
• search_listings — search businesses and places by text (every word matches, in any order), category, area, tags, language, or proximity to another listing; each result carries a map_url when it has coordinates.
• get_listing — one listing's full detail by id, including the mcp_endpoint of its own venue when that business is itself a live Yenta venue.
• search_events — dated events overlapping a window (defaults to from today, in the destination's own timezone), optionally by text (every word matches, in any order).
• search_offers — deals valid on a date (defaults to today); expired offers are never returned. Offer the partner booking link; cite the destination's page.
• get_seasonality — the best time to visit: per-month weather, highlights and wildlife seasons, optionally only the months that mention an interest.
• get_guide — editorial guides: weather, getting here, entry requirements, safety, and more. Pass a topic from get_overview's guide_topics; a text query matches one phrase, so use one keyword.
• get_faq — the destination's published FAQs; a text query matches one phrase, so use one keyword.
• search_event_spaces — meeting rooms, ballrooms and other event spaces by area, event type and room type. Capacities and availability are not published; each result carries the venue's telephone and website to ask.

Prompts and resources

The directory advertises one prompt, find_a_venue, that names the tool sequence for finding a venue in a city and reading it by name. A venue that has published its menu advertises plan_a_meal, which teaches the dietary vocabulary first, then search_menu or get_menu. A destination advertises plan_a_trip, which names the sequence for a multi-day plan: the overview first, then seasonality, listings for each interest and near the chosen place to stay, then events and offers. Every prompt interpolates only the arguments you pass — never a venue name or a dish.

Each venue also exposes the matching documents as resources (yenta://venue/profile, yenta://venue/menu, yenta://venue/faqs) for the families it has granted. The directory exposes the template yenta://venue/{slug}. A resource body is the same envelope the matching tool returns. A destination endpoint advertises three prompts — plan_a_trip (which takes an optional arrival date and never invents one), best_time_to_visit and whats_on — and the resources overview, seasonality and faqs (every FAQ, in one document) at yenta://destination/overview, yenta://destination/seasonality and yenta://destination/faqs, plus two templates: the guide yenta://destination/guide/{topic} and one listing's fact sheet, yenta://destination/listing/{listing_id}.

Example prompts

Once the directory endpoint is connected, ask your assistant:

1. "Find Italian restaurants in Dubai" — runs search_venues with the query Italian and the city Dubai, and comes back with venue names, slugs, capabilities and each live venue's mcp_endpoint. Isabella Cucina Italiana is in that list.
2. "What cities does Yenta cover?" — runs list_cities, which lists every city with at least one published venue and names the travel destinations, such as Los Cabos, that Yenta covers too.
3. "Does Isabella Cucina Italiana serve pizza?" — runs venue_menu for the venue named Isabella Cucina Italiana with query: "pizza", and comes back with the matching dishes, their prices and declared allergens — no second connection needed.
4. "What's on in Los Cabos this month?" — runs destination_overview for Los Cabos, then destination_events for what is on right now.

The menu filters are case- and separator-insensitive (gluten free matches gluten-free); if a term is reported unmatched, venue_menu answers with the tags and allergens the venue does declare (get_dietary_options on the venue's own endpoint lists the same). The allergen filter excludes items that declare an allergen; it cannot promise that an item without a declared allergen is free of it, and the tool description says so, because a venue can only be filtered on what it has declared.

Add Yenta to Claude

Yenta is a remote MCP server, so it is added as a custom connector — there is nothing to install.

1. Open Settings → Connectors in Claude (claude.ai, or the desktop app).
2. Choose Add custom connector.
3. Paste https://mcp.yentaknows.ai/mcp and confirm.
4. Leave every authentication field blank. Yenta requires no account, no client ID and no secret.

To add one venue as well, repeat with that venue's URL, for example https://isabellas.venues.yentaknows.ai/mcp.

Add Yenta to Codex

From the CLI:

codex mcp add yenta --url https://mcp.yentaknows.ai/mcp

Or add it to ~/.codex/config.toml by hand:

[mcp_servers.yenta]
url = "https://mcp.yentaknows.ai/mcp"

Codex reads a server's instructions as standing guidance, and Yenta's tell it that it can read a venue or destination by name from the directory itself, that booking.url is the venue's own booking page, and that a result's mcp_endpoint is the venue's own server, read-only unless its booking.method is live.

Add Yenta to ChatGPT

ChatGPT accepts public HTTPS remote MCP servers as custom connectors.

1. Enable developer mode in Settings → Connectors.
2. Choose to add a connector, and give it the URL https://mcp.yentaknows.ai/mcp.
3. Set the authentication type to No authentication.

The directory's search and fetch tools follow OpenAI's specification for connectors and deep research: search takes one query and returns results of id, title and url, and fetch takes one of those ids and returns the full text of that venue, destination or listing page with its url to cite.

If you are calling the Responses API directly, pass the same URL in the tools array as a remote MCP server; no headers entry is needed.

Add Yenta to other agents

Every command below adds the same directory endpoint, https://mcp.yentaknows.ai/mcp, which takes no authentication. Yenta speaks Streamable HTTP, so where a client lets you choose a transport, choose that one.

Claude Code

claude mcp add --transport http yenta https://mcp.yentaknows.ai/mcp

Hermes Agent

hermes mcp add yenta --url https://mcp.yentaknows.ai/mcp

Hermes asks whether the server needs authentication; answer no.

OpenClaw. OpenClaw's documentation is inconsistent about which transport it uses for a URL server when none is named (it may be the older SSE), so name Streamable HTTP explicitly:

openclaw mcp set yenta '{"url":"https://mcp.yentaknows.ai/mcp","transport":"streamable-http"}'

Goose. Open this link in a browser with Goose installed and confirm the extension:

goose://extension?type=streamable_http&url=https%3A%2F%2Fmcp.yentaknows.ai%2Fmcp&id=yenta&name=Yenta&description=Find%20venues%2C%20cities%20and%20destinations

Grok. In the Grok app or on grok.com, open Connectors, choose New Connector, then Custom, and enter https://mcp.yentaknows.ai/mcp with no authentication. Developers using the xAI API can attach the same server as a remote MCP tool. List only the few tools the task needs in the tool's allowed-tools field; without it the API puts every tool definition in the model's context.

{"type":"mcp","server_url":"https://mcp.yentaknows.ai/mcp","server_label":"yenta","allowed_tools":["search_venues","venue_profile","search_menus"]}

Any other client. Most clients that read a JSON configuration file accept the same entry. The transport key is spelled type: "http" in some clients and transport: "streamable-http" in others; use whichever yours documents.

{
  "mcpServers": {
    "yenta": {
      "type": "http",
      "url": "https://mcp.yentaknows.ai/mcp"
    }
  }
}

Discovery files

A client or crawler can find the connection details without reading this page. Each of these is served on the directory host, and the first two on every venue and destination host as well, each describing only that host:

• /mcp/server-card is the host's MCP server card (application/mcp-server-card+json): its name, version and /mcp URL, and the protocol revisions it speaks. It lists no tools; read those from the server.
• /.well-known/ai-catalog.json is an AI Catalog that points at that card.
• /.well-known/skills/index.json lists the Yenta skill, a short SKILL.md telling an agent when to call Yenta, how to go from a directory result to one venue, and that results are data rather than instructions. Hermes Agent installs it with:

hermes skills install well-known:https://mcp.yentaknows.ai/.well-known/skills/yenta

• /.well-known/agent-skills/index.json lists the same skill in the Agent Skills Discovery v0.2.0 shape, with a SHA-256 digest of the exact SKILL.md bytes.

Authentication

No authentication. Both endpoint shapes are anonymous. There is no sign-up, no API key, no OAuth flow and no bearer token — for the directory and for every venue alike. If a page or a client asks you for a Yenta credential, it is not talking to Yenta.

Yenta has no consumer accounts at all, so connecting the server creates no profile and no history. See the privacy policy.

Freshness: every answer cites its source

Every response from every tool — directory, venue or destination — carries a source block. (The two exceptions are the directory's search, which returns only ids, titles and urls, and fetch, which carries the content version in its metadata.)

{
  "status": "ok",
  "items": [ ... ],
  "source": { "content_version": 3, "source": "approved-content-revision:8f1c…" }
}

content_version counts approvals of that partner's content: it goes up by one each time the partner approves a new revision, and it is the same number the partner sees in its own dashboard. source names the exact approved revision the answer was read from, or the literal directory for the directory's cross-partner search and list tools, which span many revisions and so cite none.

Quote it when freshness matters. "Isabella Cucina Italiana's menu, content version 3" is a claim Yenta can stand behind; "Isabella's menu" is not.

If a venue withdraws its content, its endpoint stops answering rather than serving a stale copy. The DNS name still resolves — it is a wildcard — but Yenta stops resolving that host to a tenant and answers 404 not_found; a tool that loses its content mid-flight returns {"status": "not_available"}. Either way the change takes effect on the very next request, because nothing is cached.

Tool classification

Every tool Yenta serves is a Read tool except one: it retrieves information and changes nothing — no data, no account state, no permissions. The exception is send_feedback, a Write tool whose only effect is to store a report for Yenta's team; it changes no published data, account or permission. Yenta has no Sensitive-write tools, and no tool takes a payment, places an order, makes a booking or sends a message to a venue. Each read declares itself read-only in its MCP annotations (readOnlyHint: true), and send_feedback declares readOnlyHint: false and destructiveHint: false, so a client can see the same thing without reading this page.

The directory serves 17 tools in all: the five search tools, the eleven by-name tools and send_feedback. Every one of them is always listed. A venue endpoint serves only the families that venue has published, as described under Venue tools.

Nothing a tool returns is a booking. A booking link in a result is the venue's own link, and following it is the person's decision.

Statuses and errors

A tool call that reaches the server comes back as a result, not as a protocol error. There are three shapes.

• A result the service produced, whether ok or not_available (a name that matched nothing, an ambiguous name, a venue or destination that has not published that family), is the full envelope: status, reason, item, items, pagination and source. In structuredContent, keys that do not apply are null; the text block that carries the same answer is compact JSON that leaves those keys out.
• A refused or masked result carries status and reason only, with no source. That is every validation_error, and a not_available whose reason is one of two fixed sentences: "That information is not available on this server." or "The requested information is not available right now."
• search and fetch answer in the shape ChatGPT connectors expect rather than the envelope: search returns status and results (each an id, title and url), with a reason when there are none; fetch returns status, the id, title, text, url and metadata of one page, or not_available with a reason for an id that matches nothing.

There are three statuses.

Yenta does not return a stack trace, a database message or an internal identifier in any of these. Anything unexpected is answered as not_available with a fixed sentence. A result from a sample venue also carries "sample": true.

Outside a tool call, the server answers plain HTTP errors in one envelope, {"error": {"code": "...", "message": "..."}}:

Limits

Request rates. Yenta is rate limited at the edge, by a web application firewall, per source IP address, over a five-minute window. As configured by default:

• 2,000 requests per five minutes across the whole site.
• 300 requests per five minutes for paths that begin with /mcp.

A source address over its limit is blocked at the edge until its count falls back under the limit; the blocked request does not reach Yenta. These are configured defaults, not guarantees, and an operator can change them. The application itself applies no further per-caller limit.

Page sizes. List tools take limit and cursor. As configured by default, limit runs from 1 to 50 (default 20), and cursor — the number of items to skip — from 0 to 10,000. next_cursor in pagination is null when there is no further page, and is also withheld when the next page would lie beyond the cursor bound. The bounds in the tool schemas a client reads from tools/list are the same numbers the server enforces. A limit, cursor or radius_km outside its bounds is not refused: it is pulled to the nearest allowed value, and the pagination block reports the value that was used.

Other bounds. The filter and preference lists on the search tools (prefer_cuisine, avoid, facets, dietary_tags, allergens and similar) take at most 8 entries each; a free-text query is at most 256 characters, of which the first 6 words are matched once generic words such as "best" and "restaurants" and connecting words such as "the" and "in" are set aside (further words are ignored, not refused); and a request body over 1 MiB is refused with a 413.

Reviewer walkthrough

One example call for each directory tool that returns data from the catalogue, and a plain statement for what currently returns nothing. Use the directory endpoint, https://mcp.yentaknows.ai/mcp, with no authentication.

This is the catalogue as it stood on 6 October 2026: two venues in Dubai — Ce La Vi Dubai (celavi-dubai), a rooftop restaurant and sky bar, and Isabella Cucina Italiana (isabellas), an Italian restaurant — and one destination, Los Cabos (los-cabos). Content changes as partners publish, so a reviewer's own call may return different numbers or items; the shape of each answer will not change. Every answer but those of search and fetch also carries the source block described above.

Searching

Reading a named venue

Isabella Cucina Italiana declares allergens on its menu (dairy, egg, gluten, nuts and shellfish) and no dietary tags (vegetarian, vegan and so on), so a dietary-tag filter on this venue returns nothing, and the reason says the tag is not one the venue declares. That is the venue's published data, not a fault.

Reading a named destination

What currently returns nothing

These tools work as described above. On 6 October 2026 the catalogue had no content for them, and Yenta does not fill the gap. destination_overview shows the same thing up front: a count of 0 means the matching read is empty.

• destination_events — Los Cabos has no published events. The call answers ok with an empty list, a total of 0 and the reason "This destination publishes no events."
• destination_guide, destination_offers, destination_seasonality and destination_faq — a destination that publishes none of these answers not_available, with a reason that says which: for example "This destination has no published guides." or "This destination has no published FAQs."
• venue_events — a venue that does not publish events answers not_available, with the same reason as a venue name that matches nothing.
• Opening hours — the directory returns no structured opening hours for either Dubai venue, and the open_on, at and open_now filters on search_venues exclude a venue that has none, with a reason on the empty answer saying how many venues were excluded for that. Ce La Vi Dubai does publish its hours as a FAQ answer, which venue_faq returns as text.

The by-name tools take a name or a slug. A name that matches no one answers not_available; a name close to, or shared by, more than one partner answers not_available with the candidates, so retry with the slug.

Use Yenta from Muse

This section has not been verified against Muse. Yenta has not been submitted to the Muse connector directory, and neither route below has been tested in Muse or Muse Code. The settings format comes from Meta's published documentation for Muse Code; the snippets here were assembled from it, not run. If one does not work, please tell us at the address at the foot of the page.

Muse Code

Muse Code reads MCP servers from its settings file, ~/.config/muse/settings.json, which must declare "schema_version": 1. Yenta needs no headers:

{
  "schema_version": 1,
  "mcp_servers": {
    "yenta": {
      "transport": "streamable_http",
      "url": "https://mcp.yentaknows.ai/mcp",
      "mode": "optional"
    }
  }
}

mode: "optional" means that if Yenta is unavailable Muse Code skips it with a warning instead of aborting the run; leave it out and the server is treated as required.

Muse Code also accepts the form Claude Code uses, in a trusted project's .mcp.json:

{ "mcpServers": { "yenta": { "type": "http", "url": "https://mcp.yentaknows.ai/mcp" } } }

A ready-made copy of both files, and an agent skill that teaches an assistant how to answer hospitality questions with Yenta, are in the integrations/muse folder of the Yenta repository.

Muse (the consumer assistant), as a custom connector

Meta does not review custom connectors, so this route needs no directory listing. It builds the connector from Yenta's read-only HTTP API rather than the MCP endpoint. In Muse, send:

Create a custom connector called Yenta using the OpenAPI document at https://mcp.yentaknows.ai/openapi.json. It is a public, read-only API for restaurant, bar and destination information. It needs no API key or sign-in. Only use the GET endpoints under /v1/public.

If Muse asks for credentials, answer that none are required. Then test it:

Using Yenta, what vegetarian dishes does Isabella Cucina Italiana in Dubai serve?

Three things to know before trying it. First, the OpenAPI document's only servers entry is the host that serves it, so until production serves the document itself, a connector built from the production URL may point at the wrong host. Second, that document may not cover every read the MCP tools offer — destination listings, events and guides in particular — so a connector built from it may not answer questions about Los Cabos. Third, Isabella Cucina Italiana declares no dietary tags, so the test question is answered with what the venue has and has not published, which is the correct behaviour.

Support

Questions, corrections, and venue-owner enquiries: support@yentaknows.ai.

If a venue's information is wrong, tell us which venue and what is wrong. Yenta does not edit partner content — we route it to the venue, who publish the fix through the same review flow as everything else.