Skip to main content
Glama
Sign In

Japan Restaurant Calories

by dev.omikuji
OverviewDiscussionsAdmin

Server Details

Nutrition facts for 24,000+ menu items of 100+ Japanese restaurant chains (kcal, PFC, salt, vitamins), each with the chain's source document. Search items, total a meal, and request missing chains.

Ownership verified
Status
Healthy
Uptime
100.0% over 21 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
ChatGPT
–
Claude
–

TDQS

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: listing covered chains/makers, searching menu items, summing selected item IDs, and reporting missing coverage. The overlap between chain names appearing in search_menu and list_chains is well clarified by the descriptions, so an agent can select confidently.

Naming Consistency5/5

All tool names use snake_case with a verb-first pattern: list_chains, request_missing, search_menu, sum_items. The convention is consistent throughout, even though request_missing uses an adjective rather than a noun object.

Tool Count5/5

Four tools is well-scoped for a focused nutrition lookup server. Each tool earns its place by covering discovery, search, aggregation, and feedback without unnecessary surface area.

Completeness4/5

The surface covers the main lifecycle: browse chains/makers, search items with nutrients, sum selected items, and request missing coverage. A direct get-item-by-id tool could be useful, but search_menu returns IDs, URLs, and source files, so the gap is minor and workable.

Available Tools

4 tools
list_chainsList covered chainsA
Read-onlyIdempotent
Inspect

List the restaurant chains, stores and packaged-food makers covered (makers have type: packaged_food_maker), with item counts (current items only), which nutrients each chain publishes and when the data was fetched. query filters by chain name and also returns each chain's source document URL.

NameRequiredDescriptionDefault
queryNo

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, so the bar is lower; the description still adds real value by disclosing that counts are current-items-only and that fetch timestamps and source document URLs come back. It does not say whether results are paginated or how large the list typically is.

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?

One dense but well-ordered sentence: scope first, then the parenthetical type clarification, then return contents, then the parameter's effect. No filler sentences.

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

Completeness4/5

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

No output schema exists, and the description compensates by enumerating the returned fields, while annotations cover the safety profile. Minor gaps remain around ordering and result size for what is presumably an unpaginated list.

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

Parameters4/5

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

Schema coverage is 0% — the single 'query' parameter has no description at all — so the description carries the burden, and it does explain that query filters by chain name and additionally surfaces each chain's source document URL. It omits matching semantics (exact vs substring, case sensitivity).

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?

Names a specific verb and resource ('List the restaurant chains, stores and packaged-food makers covered') and enumerates the returned fields: item counts, nutrients per chain, and fetch date. The parenthetical 'makers have type: packaged_food_maker' resolves an ambiguity an agent would otherwise have to guess about.

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

Usage Guidelines3/5

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

Usage is only implied: the tool lists the covered universe, so an agent can infer it's the discovery step before search_menu or sum_items, but neither sibling is named and no when-not condition is given. Adequate but leaves routing to inference.

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

request_missingRequest a missing chain or itemAInspect

Tell the site operator that a restaurant chain or menu item is missing. Use only after search_menu / list_chains could not find it AND the user actually wanted it. One request per chain or item. Only the chain, item and note are stored (no personal information is needed or kept). Requests are counted (not shown publicly) and used to decide what to add next. Some chains do not publish nutrition values at all, so a request does not guarantee coverage.

NameRequiredDescriptionDefault
itemNoMenu item name, if a specific item is missing.
noteNoOptional short context, e.g. "seasonal item", "new menu from October".
chainYesRestaurant chain name, e.g. 天下一品.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the generic safe-write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description adds substantive behavior: no personal data is stored, requests are counted but not shown publicly, they only influence future additions, and coverage is not guaranteed. This is exactly the kind of context annotations cannot carry.

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?

Five short sentences, each carrying a distinct fact (action, precondition, cardinality, data retention, outcome expectation), with the purpose front-loaded and no filler.

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 non-destructive, non-idempotent submission tool with no output schema, the description covers purpose, prerequisites, data handling and expected outcome, leaving nothing an agent needs in order to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents chain, item and note with limits and examples. The description adds only the reassurance that just those three values are stored, which is useful but does not extend parameter meaning beyond the schema.

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?

States a specific verb and resource ('Tell the site operator that a restaurant chain or menu item is missing') and names the exact siblings (search_menu / list_chains) it complements, so an agent can place it precisely in the workflow.

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?

Gives an explicit precondition ('only after search_menu / list_chains could not find it AND the user actually wanted it') plus a cardinality rule ('one request per chain or item'), which covers both when to use it and when not to.

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

search_menuSearch menu itemsA
Read-onlyIdempotent
Inspect

Search menu items of Japanese restaurant chains and stores, and packaged foods of Japanese food makers, and get their nutrition facts. Queries that return no results are counted anonymously (the query text and chain only) to decide which chains to add. query matches item name, size, category, genre and chain name (Japanese; spaces mean AND; katakana/hiragana and full/half width are treated alike; common chain nicknames like ケンタ, マック, サイゼ work). Combine with chain / genre / kcal range. Use nutrient to find items rich in a nutrient (only chains that publish it). Default order: with nutrient, by that nutrient descending; else with a query, by how well the item name matches ("relevance"); otherwise by kcal ascending. total includes discontinued items (listed last), so it can be larger than item_count in list_chains. Each item has an id for sum_items, a page url, and the chain's source_file.

NameRequiredDescriptionDefault
sortNoDefault: nutrient_desc when nutrient is given, else relevance when query is given, else kcal_asc.
chainNoChain id from list_chains, or its Japanese name / nickname.
genreNo
limitNo
queryNoWords to match, e.g. "牛丼 並盛", "チーズバーガー", "すき家 カレー".
offsetNo
max_kcalNo
min_kcalNo
nutrientNoOnly items that publish this nutrient. net_carb_g is net carbohydrate (carbohydrate minus fiber, 糖質); sugar_g is sugars (糖類) — different quantities. Keys: kcal=エネルギー(kcal), protein_g=たんぱく質(g), fat_g=脂質(g), saturated_g=飽和脂肪酸(g), carb_g=炭水化物(g), net_carb_g=糖質(g), sugar_g=糖類(g), fiber_g=食物繊維(g), salt_g=食塩相当量(g), sodium_mg=ナトリウム(mg), potassium_mg=カリウム(mg), calcium_mg=カルシウム(mg), phosphorus_mg=リン(mg), iron_mg=鉄(mg), vit_a_ug=ビタミンA(μg), retinol_ug=レチノール(μg), carotene_ug=β-カロテン当量(μg), vit_b1_mg=ビタミンB1(mg), vit_b2_mg=ビタミンB2(mg), niacin_mg=ナイアシン(mg), vit_c_mg=ビタミンC(mg), vit_d_ug=ビタミンD(μg), vit_e_mg=ビタミンE(mg), cholesterol_mg=コレステロール(mg), ash_g=灰分(g), weight_g=重量(g)

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description still adds real value beyond them: anonymous logging of zero-result queries (a privacy-relevant side effect), discontinued items being included and listed last so total can exceed list_chains' count, and nutrient-only-for-publishing-chains constraint. It does not cover rate limits or pagination limits beyond offset caps, which keeps it from a 5.

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 with purpose, then query semantics, then filter/ordering rules and return hints. Dense and nearly every clause carries information, but it reads as one long run-on block and repeats ordering rules that also appear in the sort parameter description.

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 9-param search tool with no output schema, the description covers matching behavior, ordering, pagination caveat (total vs item_count), and what each result contains (id, page url, source_file). An agent can invoke it correctly and interpret results without further documentation.

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

Parameters4/5

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

Schema coverage is only 44%, but the description compensates heavily: it explains query matching scope (item name, size, category, genre, chain name), AND semantics for spaces, kana/width normalization, nickname support, and nutrient meaning plus sort defaults. Gaps remain for limit/offset/min_kcal/max_kcal, which are undocumented in both schema and description.

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?

States a specific verb (search) and resource (menu items with nutrition facts) and scopes it to Japanese chains/stores and packaged foods. It also names the sibling relationships explicitly (id for sum_items, comparison with list_chains' item_count), so an agent can distinguish it from siblings without opening another schema.

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?

Gives concrete when-to-use guidance: combine free-text query with chain/genre/kcal filters, use nutrient only for nutrient-rich lookups on chains that publish it, and describes the default ordering rules per filter combination. It also explains what happens with zero-result queries, which is actionable behavior an agent should know before calling.

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

sum_itemsTotal a mealA
Read-onlyIdempotent
Inspect

Add up nutrition for a set of items (a meal, a day) using ids from search_menu. Nutrients that some items do not publish are reported in incomplete, because their total is an underestimate.

NameRequiredDescriptionDefault
itemsYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds genuinely non-obvious behavior: unpublished nutrients surface in an `incomplete` field and the total is an underestimate. That return-value caveat is exactly what annotations cannot convey and there is no output schema to carry it. It omits any mention of the 30-item cap or quantity bounds.

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?

Two tight sentences with zero filler; the core action is front-loaded and the caveat follows as supporting detail. Every clause earns its place.

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

Completeness4/5

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

For a single-parameter aggregation tool with no output schema, the description covers the action, the input source, and the one surprising output behavior (`incomplete`). It would be fully complete if it mentioned the item/quantity limits an agent must respect.

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

Parameters3/5

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

The description reinforces the source of the `id` value (search_menu) and frames `items` as "a set of items," but says nothing about the nesting, the per-item `quantity` field, its default of 1, or the 0.1–20 range and 30-item cap. It adds only marginal meaning over the schema.

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?

States a specific verb+resource ("Add up nutrition for a set of items") and scopes it with concrete use cases ("a meal, a day"). It also names the sibling tool that produces the required input ("ids from search_menu"), so it is distinguishable from list_chains and request_missing without opening a schema.

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?

Gives clear usage context (aggregating a meal or a day) and an implicit prerequisite: items must come from search_menu. It does not state when NOT to use it or name an alternative path, so it stops short of full when/when-not guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedsearch_menu1 field changed
      • changedInput schema / properties / genre / enum
        Previous value: -[
-  "デザート",
-  "ドリンク",
-  "ごはん・サイド",
-  "寿司",
-  "麺類",
-  "カレー",
-  "丼もの",
-  "バーガー",
-  "ピザ",
-  "揚げ物",
-  "ステーキ・肉料理",
-  "餃子・中華",
-  "定食・セット",
-  "サラダ・野菜",
-  "スープ・汁物",
-  "調味料・トッピング",
-  "その他"
-]New value: +[
+  "デザート",
+  "お菓子・スナック",
+  "ドリンク",
+  "ごはん・サイド",
+  "寿司",
+  "麺類",
+  "カレー",
+  "丼もの",
+  "バーガー",
+  "ピザ",
+  "揚げ物",
+  "ステーキ・肉料理",
+  "餃子・中華",
+  "定食・セット",
+  "サラダ・野菜",
+  "スープ・汁物",
+  "調味料・トッピング",
+  "その他"
+]
  2. 2 tool updates
    • Changedrequest_missing1 field changed
      • changedInput schema / properties / chain / description
        Previous value: -"Restaurant chain name, e.g. 丸亀製麺."New value: +"Restaurant chain name, e.g. 天下一品."
    • Changedsearch_menu1 field changed
      • addedInput schema / properties / sort / description
        Added value: +"Default: nutrient_desc when nutrient is given, else relevance when query is given, else kcal_asc."
  3. 1 tool update
    • Changedsearch_menu1 field changed
      • changedInput schema / properties / nutrient / description
        Previous value: -"Only items that publish this nutrient."New value: +"Only items that publish this nutrient. net_carb_g is net carbohydrate (carbohydrate minus fiber, 糖質); sugar_g is sugars (糖類) — different quantities. Keys: kcal=エネルギー(kcal), protein_g=たんぱく質(g), fat_g=脂質(g), saturated_g=飽和脂肪酸(g), carb_g=炭水化物(g), net_carb_g=糖質(g), sugar_g=糖類(g), fiber_g=食物繊維(g), salt_g=食塩相当量(g), sodium_mg=ナトリウム(mg), potassium_mg=カリウム(mg), calcium_mg=カルシウム(mg), phosphorus_mg=リン(mg), iron_mg=鉄(mg), vit_a_ug=ビタミンA(μg), retinol_ug=レチノール(μg), carotene_ug=β-カロテン当量(μg), vit_b1_mg=ビタミンB1(mg), vit_b2_mg=ビタミンB2(mg), niacin_mg=ナイアシン(mg), vit_c_mg=ビタミンC(mg), vit_d_ug=ビタミンD(μg), vit_e_mg=ビタミンE(mg), cholesterol_mg=コレステロール(mg), ash_g=灰分(g), weight_g=重量(g)"
  4. 1 tool update
    • Changedsearch_menu1 field changed
      • changedInput schema / properties / nutrient / enum
        Previous value: -[
-  "kcal",
-  "protein_g",
-  "fat_g",
-  "saturated_g",
-  "carb_g",
-  "sugar_g",
-  "fiber_g",
-  "salt_g",
-  "sodium_mg",
-  "potassium_mg",
-  "calcium_mg",
-  "phosphorus_mg",
-  "iron_mg",
-  "vit_a_ug",
-  "retinol_ug",
-  "carotene_ug",
-  "vit_b1_mg",
-  "vit_b2_mg",
-  "niacin_mg",
-  "vit_c_mg",
-  "vit_d_ug",
-  "vit_e_mg",
-  "cholesterol_mg",
-  "ash_g",
-  "weight_g"
-]New value: +[
+  "kcal",
+  "protein_g",
+  "fat_g",
+  "saturated_g",
+  "carb_g",
+  "net_carb_g",
+  "sugar_g",
+  "fiber_g",
+  "salt_g",
+  "sodium_mg",
+  "potassium_mg",
+  "calcium_mg",
+  "phosphorus_mg",
+  "iron_mg",
+  "vit_a_ug",
+  "retinol_ug",
+  "carotene_ug",
+  "vit_b1_mg",
+  "vit_b2_mg",
+  "niacin_mg",
+  "vit_c_mg",
+  "vit_d_ug",
+  "vit_e_mg",
+  "cholesterol_mg",
+  "ash_g",
+  "weight_g"
+]

Related MCP Connectors

Related MCP Servers

  • tabedata-mcp

    mrslbt
    A
    license
    A
    quality
    C
    maintenance
    MCP server for Japanese food nutrition data, enabling bilingual JP/EN lookups across konbini, restaurant chains, and grocery brands.
    6
    60 npm
    2
    MIT

  • TWFoodMCP

    NTUT-Vincent
    F
    license
    Not graded
    quality
    C
    maintenance
    Provides access to Taiwan packaged food and chain restaurant nutritional information, including search, nutrition calculation, and draft creation for new data.
    -

  • cn-food-mcp

    ruffood
    A
    license
    A
    quality
    D
    maintenance
    Provides comprehensive Chinese food nutrition data with tools to search, compare, and filter foods by nutrient values.
    5
    43 npm
    8
    MIT
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