A
licenseA
qualityB
maintenanceMCP server for Japanese food nutrition data, enabling bilingual JP/EN lookups across konbini, restaurant chains, and grocery brands.
6
72 npm
2
MIT
Japan Food DB
Server Details
Resolve Japanese food names to nutrition facts. All 2,538 foods from Japan's official tables.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 39 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- yuki00yossi/toriigate-platform
- GitHub Stars
- 0
- Server Listing
- Japan Food DB
TDQS
A3.7/5.0
Scored across 2 tools
Disambiguation4/5
The two tools have distinct actions: search_food finds candidates and get_nutrition fetches a specific ID. However, search_food already returns nutrition facts, so an agent might wonder whether get_nutrition provides extra detail or is simply redundant, creating a small amount of ambiguity.
Naming Consistency5/5
Both tool names follow a clean snake_case verb_noun pattern (search_food, get_nutrition). The verbs are descriptive and consistent, making the naming scheme predictable and easy to follow.
Tool Count3/5
With only two tools, the server is on the low end of the range. For a narrow, read-only Japanese food nutrition lookup, two tools can be justified, but the set feels thin and just barely covered.
Completeness3/5
The workflow of search-then-get-nutrition is present, but there are no tools for browsing categories or retrieving more extensive food metadata. Because search already returns nutrition data, get_nutrition adds only marginal capability, leaving the surface slightly incomplete for broader Japanese food database use.
Available Tools
2 toolsget_nutritionGet nutrition facts by food IDAInspect
Get nutrition facts per 100g for a food ID returned by search_food.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Food ID from search_food, e.g. "chicken-breast" |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the tool gets nutrition facts per 100g, which is adequate for a simple retrieval, but does not mention potential errors, authentication, or rate limits.
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 a single, front-loaded sentence with no wasted words, achieving high efficiency.
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 simple tool with one parameter and no output schema, the description covers the unit (per 100g) and source of ID, but omits details on the structure of returned data.
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 sole parameter 'id' is described in the schema with an example. Schema coverage is 100%, so the description adds minimal value beyond what the schema already 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 the verb (get), the resource (nutrition facts per 100g), and the input requirement (food ID from search_food), distinguishing it from the sibling search_food.
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 after search_food and with a specific food ID. It does not explicitly exclude alternatives, but the context is clear given only one sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_foodSearch Japanese foodsAInspect
Search Japanese foods by name (Japanese or romaji-free text). Returns candidates with nutrition per 100g, source, and disclaimer.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5) | |
| query | Yes | Food name in Japanese, e.g. "鶏むね肉" or "ごはん" |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results include 'nutrition per 100g, source, and disclaimer', which is helpful. However, it does not describe response structure, pagination, or any other behavioral traits, leaving gaps for the agent.
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, front-loaded with purpose, followed by output details. Every sentence is informative and there is no unnecessary text.
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?
Given the tool's simplicity, the description covers the main purpose and output highlights. However, without an output schema, more detail on the return format would be beneficial. The sibling relationship is not addressed, slightly reducing completeness.
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% with descriptions for both parameters. The tool description adds minimal value beyond confirming the 'query' parameter accepts Japanese or romaji text, which is already implied by the schema description.
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 that the tool searches Japanese foods by name, specifying the verb 'search' and resource 'Japanese foods'. However, it does not differentiate from the sibling 'get_nutrition', missing the chance to clarify when to use this tool vs the alternative.
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 searching foods by name but provides no explicit guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites. The sibling 'get_nutrition' is present but not mentioned.
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.
2 tool updates
- First observed
get_nutrition - First observed
search_food
Related MCP Connectors
Food and nutrition data: search, macros, and comparisons
Nutrition for 910 plant foods across 11 national datasets, plus GB/EU & US claim checking
Search foods, compare nutrients, and look up the full USDA FoodData Central database.
USDA FoodData Central nutrition data: search foods, compare macros, and analyze meals.
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables deterministic recipe and portion math with USDA-sourced macros, gram conversions, cooked yields, and per-eater portions.12MIT
- FlicenseNot gradedqualityCmaintenanceEnables AI chatbots to look up standardized Korean food composition data, retrieve nutrient values, and check or grade nutrition answers against the National Standard Food Composition DB 10.4 with source attribution.-
- AlicenseAqualityDmaintenanceProvides SQL access to the ANSES Ciqual French food composition database, enabling query of nutritional data for over 3,000 foods with full-text search support.1MIT
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.