How do I use tabedata-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tabedata-mcp How many calories are in a Big Mac in Japan?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tabedata-mcp

by mrslbt

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

tabedata-mcp

npm version npm downloads License: MIT

Model Context Protocol server for Japanese food nutrition data. Bilingual JP/EN lookups across konbini, restaurant chains, and grocery brands. Macros, allergens, sodium, and menu navigation for any AI assistant operating in Japan.

460 sourced items across 21 chains. 42 come from Japan's MEXT food composition database (36 generic staples + 6 drinks); the rest are transcribed from official manufacturer labels and restaurant nutrition PDFs, with ~10% flagged as estimates where official figures weren't available. Size variants (並 / 大盛 / 特盛) on every restaurant chain that publishes them.

Who this is for

Tracking macros, sodium, or carbs on a Japanese diet
Looking up allergens on a menu you can't read
Travelers using an AI assistant to navigate Japanese restaurants and konbini
Comparing options across chains ("which chain has the leanest chicken?")
Building nutrition or meal apps that need real Japanese product data

Related MCP server: nutrition-mcp

Install

npm install -g tabedata-mcp

Or run on demand with npx -y tabedata-mcp.

Configuration

No API keys needed. Curated database ships with the package.

Variable	Required	Description
`MCP_TRANSPORT`	no	`stdio` (default) or `http`.
`MCP_AUTH_TOKEN`	http only	Bearer token. HTTP transport refuses to start without it.
`MCP_HTTP_PORT`	no	Default `8787`.
`MCP_HTTP_HOST`	no	Default `127.0.0.1`.
`MCP_HTTP_ALLOWED_ORIGINS`	no	Comma-separated CORS allowlist for HTTP transport.

Claude Desktop

Edit claude_desktop_config.json:

{
  "mcpServers": {
    "tabedata": {
      "command": "npx",
      "args": ["-y", "tabedata-mcp"]
    }
  }
}

Claude Code

claude mcp add tabedata -- npx -y tabedata-mcp

Cursor / Windsurf

Add to ~/.cursor/mcp.json with the same shape as Claude Desktop.

Tools

Tool	Description
`search_food`	Bilingual fuzzy search across the dataset. Accepts JP or EN queries (e.g. `salad chicken` or `サラダチキン`).
`konbini_item`	Chain-scoped lookup for 7-Eleven, Lawson, FamilyMart, Ministop. Includes allergens and ingredient lists where available.
`restaurant_meal`	Chain meal lookup with size variants (並 / 大盛 / 特盛) and allergen tags.
`analyze_meal`	Natural-language meal analyzer. Recognizes counts, weights (`200g rice`), fractions (`half avocado`), and restaurant size names (`Nakau large oyakodon`). Returns macro totals plus optional comparison to personalized targets.
`find_alternatives`	Swap an item for a better one along a chosen axis (higher protein, lower calorie, lower sodium). Returns each alternative with its improvement and tradeoff.
`daily_targets`	Mifflin-St Jeor BMR x activity multiplier x goal-driven deficit/surplus. Diabetes risk shifts the macro split. Hypertension surfaces a sodium guidance note.

Prompts

Prompt	What it does
`plan_my_day`	Given a goal (e.g. "cut to 70kg, hit 150g protein"), chains `daily_targets` → meal proposal → `analyze_meal` → `find_alternatives` into one guided workflow.

Coverage

Konbini (122 items)

Chain	Items
7-Eleven	46
Lawson	34
FamilyMart	29
Ministop	13

Restaurant chains (272 items)

Japanese chains: Nakau, Sukiya, Yoshinoya, Matsuya, CoCo Ichibanya, Marugame Seimen, Tenya, MOS Burger, Yayoiken, Ootoya, Ichiran.

Western and global chains: McDonald's Japan, KFC Japan, Subway Japan, Lotteria, Freshness Burger, Doutor.

Generic, drink, and brand items (66 items)

42 items from Japan's MEXT Standard Tables of Food Composition (文部科学省食品成分表) — 36 generic staples (rice, egg, natto, tofu…) and 6 basic drinks (milk, tea, coffee). MEXT is the canonical reference used in Japanese nutrition research and clinical practice.
24 brand products: Oikos, SAVAS Milk Protein line, Meiji R-1 / Bulgaria / LG21 / TANPACT, Glico, Calbee, Ito En, Asahi, Kirin, Suntory, Fuji Pan, Snow Brand, Morinaga inZeri.

Example queries

How many calories are in a Big Mac in Japan?
日本のビッグマックは何キロカロリー？

I just had a Sukiya gyudon. Track it.
今日すき家の牛丼食べた。記録して

Compare a 7-Eleven salmon onigiri to a Lawson one
セブンとローソンの鮭おにぎり、どっちがいい？

Analyze my lunch: 1 oikos plain, 2 boiled eggs, 200g rice
ランチ記録して: オイコス1個、ゆで卵2個、白米200g

What sizes does Sukiya's gyudon come in?
すき家の牛丼のサイズ展開は？

Calculate daily targets: 80kg, 175cm, 30, male, moderate, cutting

Data provenance

This dataset is AI-compiled: each value was gathered by an AI assistant (Claude) reading the cited source, then schema-checked by script. It is not individually fact-checked by a human. Treat every number as a best-effort reference and confirm against the item's source.url before relying on it.

Each item carries:

A cited source — an official manufacturer or restaurant nutrition label, an official PDF, an entry from Japan's MEXT Standard Tables of Food Composition, or a flagged estimate (source.type: "estimated") where official figures weren't available.
Bilingual names — name_en and name_jp are mandatory.
Provenance fields — source.url, source.type, compiled_at (ISO date), compiled_by, and a confidence level.

Run npm run verify-data to validate structure: required fields, id uniqueness, and that each source.url still resolves. This confirms links are live and records are well-formed — it does not verify the correctness of the nutrition numbers. Items older than 365 days are flagged stale.

See DATA_SOURCES.md for the full compilation methodology.

Disclaimer

This is an unofficial, community-built MCP server. Not affiliated with, endorsed by, or sponsored by any of the listed restaurants, konbini chains, or product manufacturers; their names and trademarks belong to their respective owners. Nutrition values were AI-compiled by an assistant reading publicly published sources (manufacturer, restaurant, and MEXT government pages) and were not individually verified by a human. Published figures change and AI compilation can introduce errors, so treat every value as a reference, not a guarantee, and confirm against the official source before acting on it. The author accepts no liability for decisions made on the basis of this data.

Contributing

See CONTRIBUTING.md. Pull requests for new items welcome — include source.url, source.type, bilingual names, and a confidence level for each.

License

MIT

Available Tools

6 tools

analyze_mealAnalyze MealA

Read-onlyIdempotent

PREFERRED tool whenever the user describes a whole meal (two or more items): resolves every item in ONE call and returns macro totals plus target comparison. Do NOT decompose a meal into separate konbini_item/restaurant_meal/search_food lookups. In clients that support MCP Apps it also renders a visual nutrition label. Recognizes counts ('2 eggs'), weights ('200g rice'), fractions ('half avocado', '3/4 portion'), and restaurant size names ('Nakau large oyakodon'). Optional user_profile compares totals against personalized targets (pass it whenever the user shares their stats).

自然言語の食事リストを解析し、PFC・繊維・ナトリウムの合計を返します。「2個」「200g」「半分」「3/4」「Nakau 大盛」など多様な指定に対応。user_profile を渡すと個別目標との差分も返します。

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes	Free-form meal items (EN or JP). Examples: ['1 oikos plain', '200g rice', 'Nakau large oyakodon, 3/4 rice']. 食事項目。
`user_profile`	No	Optional user profile. When present, totals are compared against personalized targets. ユーザー情報。

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already indicate read-only and idempotent hints. The description adds key behaviors: resolves items in one call, returns macro totals plus target comparison, renders visual nutrition label in supported clients, and recognizes diverse input formats (counts, weights, fractions, sizes). 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.

Conciseness4/5

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

The description is front-loaded with the key value proposition and uses clear, purposeful sentences. The Japanese version is a minor redundancy but still efficient.

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?

Given no output schema, the description adequately explains what is returned (macro totals, target comparison, visual label). It covers input format thoroughly. Slight gap on explicit return structure, but sufficient for a read-only tool.

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 100% with descriptions for both parameters. The description enhances by providing concrete examples (e.g., '1 oikos plain', '200g rice') and explaining recognition capabilities, adding value 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?

The description clearly states the tool's purpose: analyzing a whole meal (two or more items) in one call, returning macro totals and target comparison. It distinguishes from sibling tools like konbini_item, restaurant_meal, and search_food, which is explicit and effective.

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?

The description explicitly states when to use this tool ('whenever the user describes a whole meal') and when not to ('Do NOT decompose a meal into separate... lookups'). It also advises on passing user_profile for personalized targets.

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

daily_targetsCalculate Personalized Daily TargetsA

Read-onlyIdempotent

Calculate personalized daily calorie, protein, carb, fat, fiber, and water targets. Uses Mifflin-St Jeor for BMR, an activity multiplier for TDEE, and a goal-driven deficit/surplus. Diabetes risk shifts the macro split toward fat (35%) to lower carb load. Hypertension surfaces a sodium guidance note.

個別の1日あたりカロリー・PFC・繊維・水分量を算出します。BMR は Mifflin-St Jeor、TDEE は活動係数、目標から赤字・黒字を決定。糖尿病リスクがある場合は脂質比率を高めて糖質負荷を抑えます。

ParametersJSON Schema

Name	Required	Description
`age`	Yes	Age in years, e.g. 30. 年齢。
`sex`	Yes	Biological sex (used by the BMR formula). 性別。
`goal`	Yes	Body composition goal. 目標。
`activity`	Yes	Activity level. 活動レベル。
`height_cm`	Yes	Height in centimeters, e.g. 175. 身長(cm)。
`weight_kg`	Yes	Body weight in kilograms, e.g. 70. 体重(kg)。
`conditions`	No	Optional health conditions. Adjusts macro split (diabetes_risk shifts toward fat) and surfaces guidance notes (hypertension flags sodium ceiling). 持病。

TDQS

A4.2/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=true and idempotentHint=true, signaling safe, deterministic behavior. The description adds beyond annotations by detailing the calculation method (Mifflin-St Jeor, activity multiplier) and condition-specific adjustments (diabetes risk shifts fat to 35%, hypertension adds sodium note). 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.

Conciseness5/5

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

The description is two concise sentences in English and Japanese, front-loaded with the core function. Every sentence provides essential information—calculation method, condition effects—with no redundant or filler content.

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?

Given 7 parameters (6 required), no output schema, but strong annotations, the description covers calculation logic and condition adjustments adequately. It does not specify return format or error handling, but this is acceptable for a read-only calculation tool.

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 description coverage is 100%, with descriptions for all 7 parameters. The description adds value by specifying that 'diabetes_risk' shifts macros toward 35% fat, providing concrete detail not in the schema. This adds meaning beyond the basic parameter names.

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 explicitly states it calculates personalized daily targets for calories, protein, carbs, fat, fiber, and water using Mifflin-St Jeor, activity multiplier, and goal-based deficit/surplus. It clearly differentiates from sibling tools (search, analysis, alternatives) which have different purposes.

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?

The description implies usage for calculating daily targets, but does not explicitly state when to use this tool versus alternatives or provide exclusions. Siblings are not related, so usage context is implied but not fully explicit.

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

find_alternativesFind Better Food AlternativesA

Read-onlyIdempotent

Find alternatives for a food along a chosen axis: higher protein, lower calorie, or lower sodium. Returns each alternative with its improvement and tradeoff.

ある食品の代替案を、たんぱく質・カロリー・ナトリウムなど指定軸で提案します。改善点とトレードオフを併記します。

ParametersJSON Schema

Name	Required	Description	Default
`constraint`	No	Restrict alternatives to the same chain, same category, or any. Defaults to any. 制約条件。	any
`max_results`	No	Maximum alternatives to return (1–10, default 3). 最大件数。
`current_food`	Yes	Current food (EN or JP), e.g. 'tuna mayo onigiri' or 'ツナマヨおにぎり'. 改善したい現在の食品。
`optimize_for`	Yes	Which axis to improve along. 改善したい指標。

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint true. The description adds that it returns alternatives with improvement and tradeoff, disclosing the output structure beyond what annotations provide. 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.

Conciseness5/5

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

The description is two sentences plus a Japanese translation, front-loaded with the main action and outcome. No filler, efficient.

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

Completeness3/5

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

The description covers the main purpose but lacks details on output format (e.g., structure of improvement/tradeoff) since no output schema exists. It is complete for a simple tool but could be improved with more specifics on what is returned.

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 coverage is 100%, so baseline is 3. The description does not add significant extra meaning beyond the schema descriptions; it includes bilingual text and examples like 'tuna mayo onigiri' but this is minimal. Parameter semantics are adequately covered by 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?

The description clearly states the tool finds alternatives for a food along a chosen axis (higher protein, lower calorie, lower sodium) and returns each with improvement and tradeoff. This distinguishes it from siblings like search_food or analyze_meal.

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?

The description implies usage for finding dietary alternatives based on nutritional goals. While it lacks explicit when-not-to-use or alternative tools, the sibling list context helps differentiate. It is clear enough for an agent to infer appropriate use.

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

konbini_itemKonbini Item LookupA

Read-onlyIdempotent

Look up konbini items (7-Eleven, Lawson, FamilyMart, Ministop) by chain. Most items are AI-compiled from official product labels; a small share are flagged estimates where label data was unavailable — each item returns its source URL, type, and confidence so you can check the value. Values are not individually human-verified; treat them as a reference.

コンビニ商品(セブン-イレブン・ローソン・ファミリーマート・ミニストップ)をチェーン別に検索します。多くは公式の商品表示からAIが編集していますが、一部は表示が入手できず推定値です。各商品に出典URL・種別・信頼度を付与しているため値を確認できます。人手による個別検証は行っていないため参考値としてご利用ください。

ParametersJSON Schema

Name	Required	Description	Default
`chain`	Yes	Konbini chain. コンビニチェーン。
`search`	No	Optional search within the chain (EN or JP). Omit to list the whole chain. 店内検索(英語または日本語)。
`category`	No	Subcategory filter. Defaults to any. サブカテゴリ。	any

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds valuable context: items are AI-compiled, some are flagged estimates, not human-verified, and each item returns source URL, type, and confidence. 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.

Conciseness4/5

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

The description is concise and front-loaded with English, followed by a Japanese duplicate. Every sentence adds value (purpose, data sources, caveats). The duplication slightly reduces conciseness but aids international users.

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 read-only lookup tool with excellent annotations and full schema coverage, the description adds necessary context about data quality and return fields (source URL, type, confidence). It is complete for the tool's purpose.

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 all three parameters are documented in the input schema. The description does not add new parameter-level information beyond what is already in 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?

The description clearly states it looks up konbini items by chain, listing the four main chains (7-Eleven, Lawson, FamilyMart, Ministop). It distinguishes itself from sibling tools like search_food or restaurant_meal by focusing specifically on convenience store items.

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?

The description implies usage for konbini items but provides no explicit guidance on when to choose this tool over alternatives like search_food or restaurant_meal. It does not state exclusions or prerequisites.

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

restaurant_mealRestaurant Chain Meal LookupA

Read-onlyIdempotent

Look up a restaurant chain meal with size variants, AI-compiled from official chain nutrition PDFs, allergen tables, and product labels — cited per item, with a small share flagged as estimates where official figures were unavailable. Values are not individually human-verified; treat them as a reference. Default size is 並 (regular); the modifications field is recorded but not yet applied to nutrition totals.

飲食チェーンのメニューをサイズ違いで検索します。各社公式の栄養PDF・アレルゲン表・商品表示をもとにAIが編集し、商品ごとに引用URLを保持(一部は公式値が入手できず推定値)。人手による個別検証は行っていないため参考値としてご利用ください。既定サイズは並。「玉子追加」などの変更項目は記録のみで、栄養への反映は未対応です。

ParametersJSON Schema

Name	Required	Description	Default
`item`	Yes	Menu item to look up (EN or JP), e.g. 'gyudon' or '牛丼'. 検索するメニュー名。
`size`	No	Size variant. Defaults to regular (並). サイズ。既定値: regular(並)。	regular
`chain`	Yes	Restaurant chain slug. Live for 17 chains; saizeriya, pepper-lunch, kichiri-misshoku, starbucks-jp, and burger-king-jp are coming soon and currently return no items. 飲食チェーン。17チェーンが利用可能。サイゼリヤ・ペッパーランチ・きちり・スターバックス・バーガーキングは準備中で現在は結果なし。
`modifications`	No	Modifications such as 'no rice' or '玉子追加'. Recorded but not yet applied to nutrition totals. メニューの変更指示。

TDQS

A4.1/5.0

Behavior5/5

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

The description discloses key behaviors: data is AI-compiled from official sources with estimates flagged, no human verification, modifications recorded but not applied, and some chains returning no items. These go beyond the readOnlyHint and idempotentHint annotations, providing important caveats about data quality and current limitations.

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?

The description is front-loaded with the main action and provides essential details in a logical order. Including both English and Japanese adds length but serves the bilingual audience. Every sentence adds value, though the Japanese translation could be considered redundant for monolingual users.

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?

The description covers data provenance, accuracy caveats, default size behavior, and chain availability (some coming soon). Missing output format details are compensated by the tool's purpose (lookup); the description gives enough context for a user to decide to use it, even without an output schema.

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?

All parameters have schema descriptions (100% coverage), so baseline is 3. The tool description adds specific context: 'Default size is 並 (regular)' and 'modifications field is recorded but not yet applied to nutrition totals'. This extra information clarifies default behavior and modification handling beyond what the schema provides.

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 clearly states 'Look up a restaurant chain meal with size variants' and details the AI-compiled data sources from official nutrition PDFs, allergen tables, and product labels. This immediately distinguishes it from sibling tools like search_food (general food lookup) and konbini_item (convenience store items). The purpose is specific and well-defined.

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

Usage Guidelines2/5

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

The description does not explicitly guide when to use this tool over alternatives. While it provides context about data sources and limitations, it lacks direct comparisons or exclusions. The user must infer from sibling names that this tool is for restaurant chain meals only.

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

search_foodSearch Japanese Food DatabaseA

Read-onlyIdempotent

Search an AI-compiled 460-item Japanese food database by English or Japanese keyword (e.g. 'salad chicken' or 'サラダチキン'), returning macros, allergens, and a cited source per item. Sources are manufacturer labels, restaurant nutrition PDFs, Japan's MEXT food-composition database, or flagged estimates; each item carries a confidence level and a source URL to check the value against. Values are AI-compiled from those sources, not individually human-verified — treat them as a reference.

AIが編集した日本の食品データベース(460件)を日本語・英語のキーワードで検索し、各商品のマクロ栄養素・アレルゲン・出典を返します。出典はメーカー表示・飲食店の栄養PDF・文部科学省食品成分データベース・推定値のいずれかで、各商品に信頼度と確認用の出典URLが付きます。値はAIが各出典から編集したもので、人手による個別検証は行っていません。参考値としてご利用ください。

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search term (English or Japanese), e.g. 'salad chicken' or 'サラダチキン'. 検索語(英語または日本語)。
`category`	No	Restrict to a category. Omit to search all. カテゴリで絞り込み。
`language`	No	Match against EN names, JP names, or both. Defaults to both. 検索対象の言語。	both
`max_results`	No	Maximum number of results (1–50, default 10). 最大結果数。

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds valuable behavioral context: each result includes a confidence level, source URL, and the note that values are AI-compiled from sources (manufacturer labels, nutrition PDFs, MEXT database, or estimates) and not individually verified. This goes beyond annotations to set appropriate expectations.

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?

The English description is front-loaded with the core purpose and returns structure. It is concise but includes important caveats. The bilingual repetition (English then Japanese) adds length but is justified for a Japanese food database tool. Every sentence adds value, and the structure is logical.

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 no output schema, the description thoroughly explains what is returned: macros, allergens, cited source, confidence level, and source URL for each item. It also describes the database size (460 items), source types, and the AI-compiled nature. This provides an agent with a complete picture of the tool's behavior and output.

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 coverage is 100%, so the schema already documents all parameters. The description adds some context by mentioning English/Japanese keywords and categories, but these are already covered in the schema descriptions. Thus, the description adds minimal new semantic meaning beyond what the schema provides.

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

Purpose4/5

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

The description clearly states it searches a 460-item Japanese food database by keyword, returning macros, allergens, and source. The title 'Search Japanese Food Database' reinforces the purpose. However, it does not explicitly differentiate from sibling tools like 'konbini_item' or 'restaurant_meal', which may have similar search functionality.

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?

The description implies usage when searching for food items by English or Japanese keywords. It also cautions that values are AI-compiled and not human-verified, setting expectations. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'konbini_item' or 'analyze_meal', nor does it specify when not to use it.

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. Dates show when Glama detected each change.

6 tool updatesv1.4.2Jul 30, 2026
- First observedanalyze_meal
- First observeddaily_targets
- First observedfind_alternatives
- First observedkonbini_item
- First observedrestaurant_meal
- First observedsearch_food

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: general food search, convenience store items, restaurant meals, whole meal analysis, alternative suggestions, and daily target calculation. No overlap exists.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with verb_noun or noun_noun structure, making them predictable and easy to distinguish.

Tool Count5/5

Six tools is well-scoped for the server's purpose of Japanese food lookup and analysis. Each tool addresses a distinct need without being overwhelming.

Completeness4/5

The tool set covers core use cases: searching foods, analyzing meals, finding alternatives, and setting daily targets. Minor gaps exist (e.g., no ability to add custom foods or track history), but the set is sufficient for reference and planning.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Open Food Facts Mcp
io.github.varvararatta
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
Open Data Research & Data
2
Japan Food DB A
dev.toriigate
Resolve Japanese food names to nutrition facts. All 2,538 foods from Japan's official tables.
Health & Wellness Databases Open Data
22
iNutriPlan Supplement Database MCP Server A
io.github.okyalos76
MCP server exposing supplements database used by iNutriPlan.com
Health & Wellness Databases
62
nutrition A
io.github.pipeworx-io
Nutrition MCP — wraps Open Food Facts API (free, no auth)
Open Data Health & Wellness Research & Data
2

Related MCP Servers

foodvisor-mcp
Health & Wellness Fitness Tracking
cldt-fr
A
license
Not graded
quality
D
maintenance
MCP server integrating Foodvisor nutrition API for food search, meal logging, daily summaries, and progress tracking via LLM agents like Claude.
Updated 4 months ago (2026-05-09 09:43 UTC)
MIT
nutrition-mcp
Health & Wellness Open Data Databases
asachs01
A
license
Not graded
quality
D
maintenance
MCP server for USDA nutrition data lookup, meal logging, and daily macro tracking.
Updated 7 months ago (2026-02-08 23:17 UTC)
20
MIT
Wellness Nourish
Health & Wellness Search
davidmosiah
A
license
B
quality
A
maintenance
A local-first nutrition MCP server for food search, barcode lookup, meal estimation, intake logging, hydration, and nutrition coaching workflows.
Updated 8 days ago (2026-08-29 10:35 UTC)
46
390
9
MIT
openfoodfacts-mcp-server
Open Data Search Health & Wellness
AiAgentKarl
A
license
A
quality
D
maintenance
MCP server for Open Food Facts, enabling food product lookup by barcode, search, nutrition facts, allergen checks, and eco-scores without an API key.
Updated 5 months ago (2026-04-08 07:39 UTC)
8
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mrslbt/tabedata-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server