tabedata-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.2
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.
Average 4.2/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on June 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tabedata-mcp MCP server](https://glama.ai/mcp/servers/mrslbt/tabedata-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mrslbt/tabedata-mcp)

Score Badge

Copy to your README.md:

[![tabedata-mcp MCP server](https://glama.ai/mcp/servers/mrslbt/tabedata-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mrslbt/tabedata-mcp)

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