SeaWeb

search_restaurants

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`goal`	No
`intent`	Yes
`cuisine`	No
`dietary`	No
`bookable`	No
`location`	No
`price_max`	No
`party_size`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnly/idempotent/non-destructive), the description discloses server-side behavior: the server 'tries to extract them from intent on its own' and explicit params win conflicts. It flags that dietary is a 'HARD filter... never relaxed' and corrects the bookable=False pitfall ('UNFILTERED, it does NOT mean "must not be bookable"'). This adds substantial behavioral context the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded single-sentence purpose followed by compact per-parameter lines using a consistent 'extract from X -> value' format with terse annotations like '(1=$, 2=$$, 3=$$$, 4=$$$$)'. Dense but earned; the only mild redundancy is saying explicit params are 'more reliable' and then that they 'always win on conflict'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 nuanced parameters and an output schema that covers return values, every input is documented with its extraction trigger, default, and edge-case semantics — including the hard-filter guarantee for dietary and the bookable=False unfiltered behavior. Nothing an agent needs to call the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates: it explains location defaults, maps price_max to dollar tiers 1-4, enumerates the accepted dietary value set, gives party_size extraction examples ('party of 4' -> 4), and defines the goal values. This is precisely the meaning the bare schema titles omit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with 'Search restaurants by natural-language intent' — a specific verb, resource, and invocation mode in one sentence. The intent-based framing distinguishes it from siblings like filter_restaurants (structured criteria) and get_restaurant (point lookup), and it scopes the domain to SF with the 'empty (default) = no filter, all SF' clause.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides extensive when-to guidance: 'set these whenever intent implies them instead of leaving everything in free text', explicit params 'always win on conflict' with server-side extraction, and per-parameter extraction triggers like 'extract from any budget/price cue'. It never names an alternative tool or states when not to use it, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SeaWeb tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?