Gachi-Ramen
Server Details
Nationwide Japanese ramen shop database — 62,000+ shops across all 47 prefectures. Geo search (lat/lng + radius), prefecture/city filter, 14-value ramen-style taxonomy, nearest-station data, and monthly closure tracking. No auth required.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: fetching changes, fetching a single shop, health check, and searching. No overlap or ambiguity.
Most tools follow verb_noun pattern (get_ramen_changes, get_ramen_shop, search_ramen), but 'ping' is a single-word verb that deviates slightly. Overall, the naming is clear and consistent.
Four tools is well-scoped for a database search and retrieval server. Each tool serves a necessary function without being excessive or lacking.
The set provides search, single-shop retrieval, a change feed for freshness, and a health check. It covers typical read-side needs, though there is no direct listing tool beyond search.
Available Tools
4 toolsget_ramen_changesARead-onlyIdempotentInspect
Monthly change feed for the ramen DB — new shops, closure candidates (missing from the monthly web source 2 consecutive checks or marked disused/closed), web-verified closures (closed_confirmed, with evidence URL) and reopenings. This is the freshness signal you cannot cache: poll it to keep a local copy honest. Optional since (YYYY-MM-DD) returns only events on/after that date.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Optional ISO date (YYYY-MM-DD), inclusive. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | Number of events. |
| since | No | Echo of the since filter. |
| events | No | Change events (new / closure_candidate / closed_confirmed / reopened). |
| window | No | Time window covered. |
| dataset | No | Dataset id. |
| data_as_of | No | Dataset freshness date. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
| definitions | No | Event-type definitions (or a note string in the no-auth preview). |
| generated_at | No | Feed generation timestamp. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's addition of specific event types (closure candidates, web-verified closures) and the since parameter behavior adds valuable context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a parameter note, front-loaded with the core purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity (multiple event categories), the description fully explains the change feed contents and provides context for freshness. Output schema exists, so return value details are handled elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'since', and the description adds format hint (YYYY-MM-DD) and behavioral detail ('returns only events on/after that date'), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a monthly change feed for the ramen DB, listing specific event types (new shops, closure candidates, verified closures, reopenings). It effectively distinguishes from siblings like get_ramen_shop and search_ramen by focusing on the change feed scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is a freshness signal that cannot be cached and should be polled to keep a local copy honest. It lacks explicit when-not-to-use instructions but adequately implies its usage as a change feed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ramen_shopARead-onlyIdempotentInspect
Fetch one ramen shop by its stable id (rk_000001 style) — full record incl. address, coordinates, ramen style (keito), nearest station (Japan Station Master st_xxxx id + distance), tri-state payment facts, and the freshness block (first_seen/last_seen/status/closure evidence URL). No id? Pass name + pref instead and the best match is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Stable shop id, e.g. rk_000851. Preferred. | |
| city | No | Municipality (e.g. 松戸市) — alternative to pref; prefecture auto-resolved. | |
| name | No | Shop name (Japanese) — used with pref or city when id is unknown. | |
| pref | No | Prefecture (千葉県; short form 千葉 also OK) — pref or city required with name. |
Output Schema
| Name | Required | Description |
|---|---|---|
| shop | No | |
| error | No | Set when the shop was not found. |
| data_as_of | No | Dataset freshness date. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
| definitions | No | Field definitions (or a note string in the no-auth preview). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detailed information about returned fields (address, coordinates, style, station, payment facts, freshness block), providing context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence conveys all key information without redundancy. Could be slightly better structured for readability, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers both lookup methods, explains return fields, and compliments existing output schema. No missing context for a fetch-by-identifier tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage. The description enriches parameters with examples (rk_000851), clarifies that city is an alternative to pref, explains auto-resolution of prefecture, and mentions 'best match' behavior for name-based lookups—adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches one ramen shop by stable ID or by name+prefecture. It mentions the full record content, distinguishing it from sibling search_ramen which is likely for broader searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use ID as preferred, and if missing, use name+pref/city. Implicitly differentiates from search_ramen but does not explicitly state when to choose each sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingARead-onlyIdempotentInspect
Connection test / health check — call this first to confirm the server is reachable. Returns server identity, deploy version, and live data freshness (active shop count + the latest weekly-crawl date) so you can confirm the data is current, not just that the server is up. No auth, no arguments, lightweight.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| server | No | Server name. |
| status | No | Always "ok" when the server is reachable. |
| version | No | Deploy version. |
| coverage | No | Geographic coverage. |
| shops_active | No | Live count of active ramen shops in the dataset. |
| last_weekly_crawl | No | Date the dataset was last refreshed (YYYY-MM-DD). |
| rate_limit_noauth | No | No-auth rate limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds useful detail about returned data (server identity, deploy version, active shop count, crawl date) and that it requires no arguments or authentication. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load purpose and usage order, then detail return value and properties. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health-check tool with no parameters, rich annotations, and an output schema, the description covers purpose, usage order, return details, and safety profile. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description confirms 'no arguments', which aligns with the schema. Baseline of 4 is appropriate given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a connection test/health check and specifies it returns server identity, deploy version, and live data freshness. It distinguishes from sibling tools (all ramen-related) by focusing on server reachability and overall system health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'call this first' and mentions it is lightweight with no auth, but does not provide when-not or alternatives. However, given the tool's simple nature and distinct purpose from siblings, this is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_ramenARead-onlyIdempotentInspect
Search a nationwide Japanese ramen-shop database (62,000+ shops, all 47 prefectures) with a verifiable freshness layer: monthly source checks, closure candidates, and web-verified closures with evidence URLs. English-first: shop names and places are searchable in Japanese OR romaji. To answer "is there a ramen shop called X?", pass q alone — it searches NATIONWIDE by name (e.g. q=一蘭 or q=ichiran, no prefecture needed). Or filter by prefecture (東京都/大阪府/〇〇県 or romaji tokyo/osaka/saitama), city (松戸市 or romaji kawaguchi), ramen style (keito), status (active/closed_candidate/closed_confirmed), or search near a coordinate (lat/lng + radius up to 5 km). Facts only — no rankings, no reviews. Payment/midnight fields are tri-state (true/false/null=unknown).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Shop-name substring, Japanese OR romaji/English (e.g. 一蘭 or ichiran, 豚坂下 or butasakashita). Works NATIONWIDE on its own — pass q with no pref/city to check if a shop exists anywhere. | |
| lat | No | Optional latitude for nearby search (with lng). | |
| lng | No | Optional longitude for nearby search (with lat). | |
| city | No | Municipality, Japanese (松戸市, 世田谷区) OR romaji (kawaguchi, setagaya). Works alone — prefecture is auto-resolved (add pref if the romaji is ambiguous). | |
| pref | No | Prefecture, Japanese (千葉県; short forms 千葉/東京) OR romaji (chiba/tokyo/saitama/osaka). Optional if city, q, or lat/lng is given. | |
| keito | No | Optional ramen-style filter. Coarse bucket (tonkotsu, miso, shoyu, shio, tsukemen, spicy, other) matches every school in the bucket — tonkotsu also covers iekei/家系 & jiro/二郎. Or an exact fine value from the 19-value vocabulary: iekei, jiro, tsukemen, tantanmen, abura_mazesoba, chuka_tanrei, champon, toripaitan, sapporo, asahikawa, kitakata_aizu, shirakawa, sano, onomichi… (keito=champon returns only champon shops). ~23% of shops carry a style; the rest are unclassified. | |
| limit | No | Max results (default 20, max 50). | |
| match | No | How q matches: 'partial' (default, substring) or 'exact' (whole word on the romaji name — q=ojiya finds 王子家/Ojiya but not 糀谷/Kojiya). Use exact to avoid coincidental substring hits. | |
| status | No | Optional: active (default: all) / closed_candidate / closed_confirmed. | |
| radius_m | No | Nearby search radius in metres (default 1500, max 5000). |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | Human-readable note. |
| count | No | Results returned. |
| query | No | Echo of the resolved query. |
| shops | No | Matching shops. |
| data_as_of | No | Dataset freshness date (YYYY-MM-DD). |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
| total_matched | No | Total matches before limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds significant behavioral context: verifiable freshness layer, monthly source checks, closure candidates with evidence URLs, and tri-state payment/midnight fields. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single dense paragraph. While all information is present, it lacks visual structure (e.g., bullet points for parameters or use cases) as word count. Front-loaded with core purpose, but could be more scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, output schema exists), the description covers all essential aspects: search modes, freshness layer, geographic scoping, style filtering, status management. Output schema exists, so return values need not be described. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. The description adds substantial value beyond schema: explains keito coarse/fine matching, q nationwide behavior, match types, and tri-state fields. Each parameter's behavior is enriched with practical examples and edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a nationwide Japanese ramen-shop database with specific filters. It distinguishes from sibling tools (get_ramen_shop, get_ramen_changes, ping) by focusing on search and listing capabilities. The verb 'search' and resource 'ramen-shop database' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use just 'q' for name lookup, when to add prefecture/city, and what each filter does. Lacks explicit exclusion of other tools, but the context of siblings and detailed filter descriptions imply appropriate usage. Could be improved by referencing get_ramen_shop for specific shop details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!