Checks PyPI for the latest version of the food-mcp package and provides upgrade directives.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@food-mcp evaluate macros and check leucine threshold for 60g ragi, 40g toor dal, 80g paneer"
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.
Precision food chemistry, global nutrition databases (USDA, Open Food Facts, IFCT), and recipe formulation for AI agents.
food-mcp equips LLMs and autonomous agents with exact molecular nutrition data: essential amino acid profiles (WHO/FAO 2007), Muscle Protein Synthesis (MPS) Leucine threshold verification, electrolyte and mineral synergy ($Na:K$ and $Ca:Mg$ ratios), Iron bioavailability dynamics, Glycemic Load (GL) calculation, and NOVA ultra-processed food detection.
Run directly without manual installation using uvx (recommended) or npx:
# Python / uvx (zero install)
uvx food-mcp
# Or use the CLI alias
uvx --from food-mcp food-chemistry-mcp
# Node / npx (zero install thin bridge)
npx food-mcpAdd food-mcp to your MCP client config (claude_desktop_config.json, ~/.cursor/mcp.json, or Antigravity):
uvx (Recommended){
"mcpServers": {
"food-mcp": {
"command": "uvx",
"args": ["--from", "food-mcp", "food-mcp"]
}
}
}npx{
"mcpServers": {
"food-mcp": {
"command": "npx",
"args": ["-y", "food-mcp"]
}
}
}Related MCP server: mcp-usda-fdc
Database / Engine | Coverage | Highlights |
ICMR-NIN IFCT 2017 | 35+ core South Asian staples | Exact per-100g macros, calcium, iron, zinc, potassium, and full essential amino acid assays for Ragi, Jowar, Bajra, Toor dal, Moong dal, Paneer, Ghee, Moringa, Amla, etc. |
USDA FoodData Central | Curated reference whole foods | High-yield proteins (Chicken breast, Wild Salmon, Eggs), plant lipids (Avocado, EVOO), and modern formulation staples (Hemp seeds, Lupin flour, Whey isolate, Nutritional yeast). |
Open Food Facts | Global packaged barcodes & search | Millions of consumer products with real-time barcode lookup, ingredient lists, NOVA classification (1 to 4), and Nutri-Score. |
Molecular Nutrition Engine | Mathematical formulation | WHO/FAO 2007 EAA pattern, 2.5g Leucine MPS threshold, $Na:K$ cardiovascular ratio, $Ca:Mg$ bone/vascular ratio, iron bioavailability pairing, and weighted Glycemic Load. |
lookup_food(query: str, region: str = "global", limit: int = 5)Searches across IFCT, USDA, and Open Food Facts. Returns matched food items with standard IDs (ifct:ragi, usda:chicken_breast, off:737628064502) and macro previews.
{
"query": "ragi",
"region": "south_asia",
"limit": 3
}get_food_chemistry(food_id_or_barcode: str)Returns the full molecular profile: per-100g calories, protein, fat, carbohydrates, fiber, net carbs, minerals ($Na, K, Ca, Mg, Fe, Zn$), 11 essential & semi-essential amino acids (mg), fatty acid breakdown, Glycemic Index, NOVA group, Nutri-Score, allergens, and additives.
{
"food_id_or_barcode": "ifct:ragi"
}formulate_recipe(ingredients: List[dict], servings: int = 1, title: Optional[str] = None)Evaluates a multi-ingredient dish or meal plan:
Aggregate & per-serving macros (Calories, Protein, Fat, Carbs, Fiber, Net Carbs).
Caloric macro distribution (% protein, % fat, % net carbs).
Amino Acid Completeness: Compares against WHO/FAO 2007 adult scoring pattern, identifies limiting amino acid, and verifies if serving clears the 2.5g Leucine MPS threshold.
Micronutrient Synergy:
$Na:K$ ratio (evaluates against $< 1.0$ target).
$Ca:Mg$ ratio (evaluates against optimal $\approx 2:1$ physiological balance).
Iron bioavailability & ascorbic acid enhancement notes.
Glycemic Load (GL): Calculates weighted meal GI and categorizes GL ($\le 10$ Low, $11-19$ Medium, $\ge 20$ High).
Cleanliness / Processing Score: Computes weighted NOVA score ($1.0 - 4.0$) and flags ultra-processed additives.
{
"title": "High-Protein Millet & Paneer Bowl",
"servings": 1,
"ingredients": [
{ "name": "Ragi", "grams": 60 },
{ "name": "Toor Dal", "grams": 40 },
{ "name": "Paneer", "grams": 80 },
{ "name": "Moringa Leaves", "grams": 30 },
{ "name": "Ghee", "grams": 10 }
]
}optimize_recipe_macros(ingredients: List[dict], target_protein_g: float = 40.0, max_carbs_g: float = 30.0)Analyzes a recipe and provides actionable, quantitative adjustments:
Recommends nutrient-dense swaps (e.g. swapping high-carb flours for lupin or almond flour, cauliflower rice).
Recommends protein boosters (hemp seed hearts, nutritional yeast, paneer, whey isolate) to hit protein targets and clear the 2.5g Leucine threshold.
Recommends mutual amino acid complementation (pairing Lysine-rich pulses with Methionine-rich seeds).
Simulates projected post-optimization macros.
lookup_barcode(barcode: str)Direct lookup of any global packaged food barcode via Open Food Facts API (https://world.openfoodfacts.org/api/v2/product/{barcode}.json).
doctor()Runs diagnostic checks across local IFCT datasets, USDA database, Open Food Facts API latency, and skills availability.
skills_list() and skill_read(name: str)Inspects and loads dynamic food chemistry playbooks directly into the agent's context.
check_for_updates(force: bool = False)Checks PyPI for latest version and upgrade directives.
food-mcp includes decoupled playbooks that provide domain guidance:
recipe-formulation: Deep dive into caloric distribution, $Na:K$ and $Ca:Mg$ mineral ratios, iron bioavailability levers, and Glycemic Load categorization.
amino-acid-optimization: WHO/FAO 2007 reference adult pattern, Liebig's law of the minimum, 2.5g Leucine MPS threshold mechanics, and South Asian mutual supplementation.
ultra-processed-food-audit: NOVA classification rules, industrial cosmetic additives (emulsifiers, artificial sweeteners, maltodextrin), and gut mucosal implications.
Call skill_read(name="recipe-formulation") from your agent to load any skill.
food-mcp collects anonymous usage telemetry (tool name, latency, error taxonomy, OS/Python version) to prioritize dataset expansion and bug fixes:
No ingredients, recipe titles, meal names, or user content are ever collected or logged.
Opt out anytime by setting any of the following environment variables:
export FOOD_MCP_TELEMETRY=false
# or
export MCP_TELEMETRY_OPT_OUT=1
# or
export DO_NOT_TRACK=1MIT License. Copyright (c) 2026 Surendran B.
Check PyPI for the latest version of food-mcp.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discloses little beyond the target registry. It doesn't say whether this performs a network request, whether results are cached, or what the 'force' parameter changes about behavior. For a tool whose only parameter implies cache-bypass semantics, that gap matters.
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?
A single short sentence that front-loads the action and target with no wasted words. It is appropriately sized, though the brevity comes at the cost of the missing information noted elsewhere.
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?
An output schema exists, so return values need not be explained here. However, with no annotations and an undocumented 'force' parameter, an agent lacks enough behavioral context to call this correctly — it cannot tell what forcing does or what the call costs.
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 0% and the single parameter 'force' (boolean, default false) is never mentioned in the description. Since the schema provides no textual semantics either, the parameter's meaning is entirely undocumented — the description fails to compensate.
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?
States a specific verb ('Check') and resource ('PyPI for the latest version of food-mcp'), making the operation unambiguous. No sibling tool performs version checking, so the agent can identify it immediately from the name plus description.
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?
No guidance on when to invoke this tool or when not to. There is an implicit 'when you want to know if an update exists,' but no mention of context such as startup checks, cost of the network call, or interaction with the other food tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tests connectivity to Open Food Facts, USDA, and local IFCT dataset.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries full burden. It discloses the scope (three data sources) but doesn't say whether it's read-only, what failures look like, or how it reports results. Output schema exists, so return format needn't be explained, but behavioral context is thin.
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?
A single sentence that is fully front-loaded and contains no waste.
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?
With an output schema present, return values are covered. However, for a diagnostic tool with no annotations and no parameters, the description could better explain what 'tests connectivity' entails (e.g., network calls, failure modes). It's adequate but leaves 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?
Zero parameters, so baseline is 4. The description adds meaning by naming the three connectivity targets, which is extra context beyond the empty 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 states a specific verb (tests) and resource (connectivity to Open Food Facts, USDA, and IFCT). It doesn't explicitly differentiate from siblings like check_for_updates, though the diagnostic nature implies differentiation.
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?
No explicit guidance on when to use this tool vs alternatives such as check_for_updates. The diagnostic purpose is implied but not stated as a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Formulates a multi-ingredient recipe and returns aggregate and per-serving macros,
caloric distribution, amino acid completeness (WHO/FAO 2007 pattern + 2.5g Leucine MPS threshold), micronutrient synergies (Na:K ratio, Ca:Mg ratio, Iron bioavailability), glycemic impact (GI and Glycemic Load), and cleanliness score (weighted NOVA).
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| servings | No | ||
| ingredients | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses the computed outputs but says nothing about permissions, side effects, whether it is read-only or computational, or any execution constraints. This leaves significant behavioral gaps.
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 a single front-loaded sentence that begins with the tool's core purpose. However, it then enumerates a long list of return values that are likely already defined by the output schema, so not every phrase earns its place.
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?
The tool is complex and has no annotations, yet the description focuses almost entirely on return values, which the output schema already covers. It omits usage context and parameter semantics, making it insufficient for an agent to invoke the tool correctly without opening the schema.
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 0%, and the description adds no information about the three input parameters. It does not explain the expected structure of the ingredients array or the role of servings and title, leaving the schema's undocumented parameters entirely unclarified.
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 states a specific verb and resource: it formulates a multi-ingredient recipe. It also clearly enumerates the types of nutritional analysis returned. However, it does not distinguish itself from the sibling optimize_recipe_macros or other related tools, so a 4 rather than 5.
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 no guidance on when to use this tool versus alternatives such as optimize_recipe_macros or lookup_food. It describes what the tool returns but not the context or conditions for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full molecular profile for a food ID or packaged barcode:
macros, micros, amino acids, fatty acids, NOVA group (1 to 4), Nutri-Score, allergens, and additives.
| Name | Required | Description | Default |
|---|---|---|---|
| food_id_or_barcode | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Returns' and the get_ prefix make the read-only nature reasonably clear, and the field list conveys the breadth of the payload, but there is no mention of error behavior for unknown IDs, permission requirements, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the action stated first, followed by an informative enumeration of returned data domains. The list is long but each item earns its place by telling the agent what the profile contains.
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?
An output schema exists, so return-value detail is not strictly required, and the description is adequate for a simple one-parameter read. However, with no annotations and unresolved overlap with lookup_food/lookup_barcode on the same input type, the agent is left to guess which sibling to pick.
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 0% and the description is the only place that explains the single parameter: it accepts either an internal food ID or a packaged barcode. That adds real meaning beyond the schema, but it doesn't specify accepted formats (e.g., UPC/EAN digit length), so it only partially compensates.
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?
States a specific verb ('Returns') plus resource ('full molecular profile') and enumerates the exact data domains returned (macros, micros, amino acids, NOVA, Nutri-Score, allergens, additives). It does not differentiate itself from the sibling tools lookup_food or lookup_barcode, which handle overlapping inputs, so 4 rather than 5.
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 never says when to call this tool instead of lookup_food or lookup_barcode, despite all three accepting food/barcode identifiers. The only hint is that it accepts either an ID or a barcode, which is implied usage rather than explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instant lookup of any global packaged food barcode via Open Food Facts API.
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does add two useful behavioral facts: lookups hit an external API (Open Food Facts) and coverage is limited to packaged food products. It says nothing about unknown-barcode behavior, coverage gaps, rate limits, or offline failure modes, so it is only partially transparent for an unannotated tool.
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?
A single tight sentence with the capability front-loaded and no filler. Nothing to trim.
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?
An output schema exists, so return values are not the description's responsibility, and a one-parameter tool is low complexity. Still, for an unannotated tool the description omits barcode format and not-found behavior, leaving a real gap for correct invocation.
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?
The single barcode parameter has 0% schema description coverage, so the description must compensate and largely does not: no format guidance (EAN/UPC digits, checksum, leading zeros), no acceptance of multiple codes. 'Any global packaged food barcode' gives vague scope but no callable format detail.
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?
States a specific verb (lookup) and resource (packaged food barcode) plus the backing data source (Open Food Facts API), so the agent knows exactly what it returns. It implicitly separates itself from lookup_food (name-based), though it never names that sibling explicitly.
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?
There is no when-to-use guidance, no statement of when to prefer lookup_food or get_food_chemistry instead, and no prerequisites. The agent can only infer usage from the word 'barcode' in the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches food chemistry databases across ICMR-NIN IFCT, USDA, and Open Food Facts.
Returns matched foods with food IDs and per-100g macro previews.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| region | No | global |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose useful behavior: the search spans three named databases and returns food IDs plus per-100g macro previews (i.e., partial data, not full chemistry). It does not mention matching/fuzzy behavior, result ordering, rate limits, or how region affects which databases are consulted.
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 sentences with zero waste: the search scope is front-loaded and the return format follows. Every clause earns its place.
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?
The presence of an output schema lowers the bar on return values, but with no annotations and 0% schema description coverage, the description leaves limit, region, and the search-then-retrieve workflow unexplained. For a 3-parameter tool with a regional data source, that is a real gap.
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 0%, so the description must compensate for all three parameters — but it says nothing about query semantics, the meaning of limit (default 5), or what values region accepts and how 'global' versus a regional source like ICMR-NIN IFCT changes results. Naming the databases faintly implies regional variance but explains no parameter.
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?
States a specific verb+resource ('searches food chemistry databases') and names the three concrete data sources (ICMR-NIN IFCT, USDA, Open Food Facts). It is distinguishable from get_food_chemistry (detail retrieval) and lookup_barcode (barcode entry), though it never explicitly contrasts with them.
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?
There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The agent must infer that this is the discovery step that yields food IDs for a later get_food_chemistry call, and nothing tells it when to prefer lookup_barcode instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes a recipe and suggests precise gram adjustments or nutrient-dense swaps
(e.g., swapping flour for lupin/almond flour, adding hemp seeds, paneer, nutritional yeast) to hit target macros and clear the 2.5g Leucine MPS threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| servings | No | ||
| ingredients | Yes | ||
| max_carbs_g | No | ||
| target_protein_g | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Analyzes ... and suggests' strongly implies a non-mutating advisory operation, which is useful, and it discloses the domain constraint it optimizes against (2.5g Leucine MPS). However, it says nothing about whether it returns a revised ingredient list vs. prose suggestions, or any rate/cost/compute considerations.
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 compact sentences with the core action front-loaded and the examples safely quarantined in a parenthetical, so the reader gets the purpose before the elaboration. No filler sentences, though the example list is longer than strictly needed.
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?
An output schema exists, so return-value explanation is reasonably omitted, and the domain goal is well conveyed. The gap is on the input side: four undocumented parameters including the required ingredients array, plus no guidance on how this relates to formulate_recipe, leave the definition only minimally complete.
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 0% across four parameters (ingredients, servings, max_carbs_g, target_protein_g), so the description must compensate. 'Hit target macros' loosely gestures at target_protein_g and max_carbs_g, but servings and especially the required ingredients structure are never addressed, leaving the required-parameter format undocumented.
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?
States a specific verb pair (analyzes/suggests) and resource (recipe macros) with concrete examples of the adjustments offered (lupin/almond flour, hemp seeds, paneer, nutritional yeast) and the concrete goal (2.5g Leucine MPS threshold). It is clearly an optimizer over an existing recipe, which implicitly separates it from formulate_recipe, but it never names or contrasts that sibling explicitly.
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?
Usage is only implied: an agent can infer it applies when it has a recipe and macro targets to hit. There is no explicit when-to-use, no when-not-to-use, and no mention of formulate_recipe or lookup_food as alternatives, which matters in a toolset that contains both a recipe formulator and food lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a specific food chemistry skill/playbook by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. 'Read' implies a non-mutating operation and the content is a playbook, but nothing is said about required permissions, behavior when the name is unknown, or whether the payload is cached/static versus dynamic.
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?
A single lean sentence with the resource and lookup key front-loaded. Nothing is wasted, though there is little substance to be concise about.
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?
An output schema exists, so return values need no explanation, and the tool is a simple one-parameter lookup. Still, the description omits how names are discovered and what happens on a miss, which are the two things an agent needs to use it reliably.
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 0% and the single 'name' parameter has no title or description, so the description must compensate. 'By name' only weakly signals that the value is a skill identifier; the expected format (exact slug vs. display title vs. fuzzy match) is left unspecified.
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?
Specific verb ('Read') plus resource ('food chemistry skill/playbook') and the lookup key ('by name'). An agent can distinguish it from lookup_food or get_food_chemistry, though it never explicitly contrasts with the sibling skills_list that presumably enumerates the valid names.
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?
No when-to-use guidance, no prerequisites, and no pointer to skills_list as the source of valid names. The agent must infer that it should first list skills before reading one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available food chemistry and recipe optimization skills.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond the verb. Read-only/non-destructive behavior is only weakly implied by "List," and nothing is said about whether skills are filtered, paged, or scope-limited.
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?
A single, front-loaded sentence with zero filler that states the action and the domain in one pass.
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 zero-parameter listing tool with an output schema, the description covers what an agent needs to invoke it correctly. The remaining gap is that it does not connect the listed skills to the sibling skill_read, which would complete the workflow picture.
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?
The tool takes zero parameters, so there is nothing to document; the baseline of 4 applies. The description adds no parameter detail because none is needed.
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 gives a clear verb ("List") and resource ("skills") and scopes it to "food chemistry and recipe optimization," so an agent knows what it returns. It stops short of distinguishing itself from the sibling skill_read, which is the natural follow-up tool, so it is not a 5.
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?
"List available ... skills" implies a discovery step that logically precedes skill_read, so usage is reasonably inferable. However, there is no explicit when/when-not guidance and no mention of the skill_read alternative for acting on a listed skill.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_for_updatesdoctorformulate_recipeget_food_chemistrylookup_barcodelookup_foodoptimize_recipe_macrosskill_readskills_listScored across 9 tools
Most tools have distinct resource/action pairings, but lookup_barcode and get_food_chemistry both handle packaged barcodes, creating potential overlap. formulate_recipe and optimize_recipe_macros are also adjacent, though their descriptions differentiate creation from analysis/optimization.
All names use snake_case, but the patterns are mixed: verb_noun (lookup_food, get_food_chemistry), noun_verb (skills_list, skill_read), a bare noun (doctor), and a longer verb phrase (check_for_updates). The convention is readable but not predictable.
Nine tools is well-scoped for a food chemistry and recipe optimization server. The set balances core domain operations with useful meta tools without becoming bloated.
The surface covers lookup, detailed chemistry, barcode resolution, recipe formulation, optimization, and supporting utilities. Minor gaps exist, such as direct nutrient-based search or multi-food comparison, but core workflows are covered.
Free public MCP for AI agents — 193 tools, 44 workflows. No API key.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Package intelligence MCP for AI agents — 22 tools, 19 ecosystems, AGPL SDK, free.
Geocoding, routing, isochrones, traffic, weather, and place search for AI agents. 19 MCP tools.
