Skip to main content
Glama

vibe_search

Read-onlyIdempotent

Semantic / vibe search over the same nationwide ramen DB — describe what you feel like eating in natural language, English or Japanese ("rich creamy pork broth", "あっさり淡麗な醤油", "oily mazesoba", "tsukemen near Ebisu station"), and get the closest shops by meaning, each with a similarity score. Powered by multilingual embeddings (bge-m3), so English queries find shops with Japanese-only names. Role split: use search_ramen for exact facts (shop name lookup, keito/prefecture/status filters, geo radius) — use vibe_search for descriptive/fuzzy queries where no exact filter fits. Style rankings reflect only classified shops (~25%); unclassified shops still match by name and place. Tip: concrete food words (style, broth, richness, place, hours) match far better than abstract mood words ("stylish", "hardcore") — translate moods into concrete attributes before querying. Prefecture intent in the query text (北海道, 博多の…) is auto-applied as a filter (pref_source: inferred); region-style names (札幌ラーメン, 喜多方, 佐野…) stay pure style words and never restrict location. Dish-concept words (オロチョン, カラシビ, 台湾ラーメン/まぜそば, 勝浦タンタンメン) are expanded into their constituent style vocabulary before embedding (transparent via concept_expansion in the echoed query) — expansion never adds filters, so shops serving the dish always stay eligible; spicy-implying concepts additionally give spice-verified shops a small rank boost (concept_boost — a soft rerank, still no filter). Richness/hours inferred from the query text likewise act as a soft rank boost (attr_boost; attr_matched is informational) — only explicit richness/hours params and spiciness intent filter strictly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesNatural-language description, English or Japanese (e.g. "rich creamy pork bone broth", "辛い味噌", "brothless oily noodles").
prefNoOptional prefecture filter, Japanese (東京都/千葉県, short 千葉 OK) or romaji (tokyo/osaka).
hoursNoOptional hours filter: morning / late_night / 24h. Auto-inferred from the query text (朝/深夜/24時間…) when omitted.
limitNoMax results (default 10, max 20).
spiceNoDeprecated alias of spice_level (kept for backward compatibility).
statusNoOptional: active (default) / closed_confirmed / all.
richnessNoOptional broth-richness filter from official-site enrichment: assari / kotteri / futsu / menu_varies. Auto-inferred from the query text (あっさり/こってり…) when omitted.
venue_typeNoOptional venue filter: "permanent" (DEFAULT) / "popup" (limited-run event & department-store-fair appearances, excluded by default so results are places you can actually visit) / "all".
spice_levelNoOptional spiciness ATTRIBUTE filter: "spicy" (shops whose signature is spiciness — chain signage or shop-name signal, dual-verified; ~1% of shops). Explicit value wins over query-text inference (辛い/激辛/spicy…; negations like 辛くない do not trigger). IMPORTANT: do NOT set this for dish/menu-name queries (オロチョンラーメン, カラシビ, 台湾まぜそば, 勝浦タンタンメン…) — many shops SERVING those dishes have no spice adjudication yet, so this hard filter would exclude them; leave it unset and the engine reaches them via concept expansion + menu-name matching. Set it only when the user asks for spicy shops in general. Orthogonal to keito: keito is style lineage, spice_level is an attribute — tantanmen alone never implies spicy.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoHuman-readable note.
countNoResults returned.
queryNoEcho of the resolved query — includes scene_expansion / concept_expansion when a scenario or dish-concept word (オロチョン, カラシビ, 台湾まぜそば…) was expanded into style vocabulary before embedding.
shopsNoClosest shops by meaning, best first.
data_as_ofNoDataset freshness date (YYYY-MM-DD).
attributionNoData source(s), license and provenance — an object, or an array of sources.

TDQS

A5/5.0
Behavior5/5

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) already signal safety, but the description adds substantial behavioral nuance: style rankings only cover ~25% of shops, prefecture intent auto-applied as a filter, concept expansion mechanics, soft vs hard filters (concept_boost, attr_boost), and the explicit warning that prefecture/region-style names stay pure style words. This is far beyond what annotations convey and fully transparent.

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

Conciseness5/5

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

Long but densely informative; every sentence earns its place. Purpose and usage split are front-loaded, followed by precise mechanics. No filler or redundancy. The structure flows from high-level guidance to nuance, making it easy to scan for the key decision (which tool to use) before diving into edge cases.

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?

For a tool with 9 parameters, complex inference behavior, and soft/hard filter semantics, the description covers all relevant aspects: query language support, auto-application, concept expansion, rank boosts, and the unclassified-shop caveat. Output schema exists, so return values need no explanation. Nothing an agent needs to use this 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 coverage is 100% and every parameter has a description, but the tool description adds critical meaning beyond schema: it explains auto-inference for pref/hours/richness, that explicit values win over inference, the spice_level pitfall for dish-name queries, and the distinction between hard filters and soft boosts. This adds semantic depth that the schema alone does not provide.

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?

The description states a specific verb ('semantic / vibe search'), resource ('same nationwide ramen DB'), and output ('closest shops by meaning, each with a similarity score'). It explicitly distinguishes itself from the sibling tool search_ramen ('use search_ramen for exact facts... use vibe_search for descriptive/fuzzy queries'), so an agent can immediately tell them apart.

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

Usage Guidelines5/5

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

Clear when-to-use vs when-not: 'use search_ramen for exact facts... use vibe_search for descriptive/fuzzy queries.' It also gives practical advice on query formulation (concrete food words vs abstract moods) and explicitly notes the split between exact filters and fuzzy search. This is actionable, not just generic context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: ping for health, get_ramen_shop for single-record fetch, search_ramen for exact/filtered queries, vibe_search for semantic/fuzzy queries, and get_ramen_changes for the data freshness feed. The overlap between search_ramen and vibe_search is explicitly addressed in their descriptions, eliminating ambiguity.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern in snake_case (get_ramen_changes, get_ramen_shop, search_ramen, vibe_search), with ping being the only exception as a bare verb health check. This is a minor deviation but still readable and predictable.

Tool Count5/5

With 5 tools, the server is well-scoped for a read-only database/search service. Each tool covers a necessary operation without redundancy, and the count is neither thin nor bloated.

Completeness5/5

The server provides full retrieval coverage: single-record retrieval, exact search, semantic search, and a change feed for data freshness. As a read-only service, it does not need create/update/delete operations, and the existing surface covers all plausible agent needs for querying ramen shop data.

Resources