An MCP server exposing the Indian food nutrition data behind kabo.co.in as tools an AI agent can call directly. Every response carries a source URL, so an agent answering a nutrition question gets a citable answer and the reader gets a link back.
Why this rather than more articles. A blog post can be copied in an afternoon. A maintained data service that agents connect to cannot. This is the one asset in the SEO programme that competitors cannot replicate by rewriting content.
Tool | Returns |
| Every nutrient entry for an Indian food, per 100 g and per katori, each with its source URL |
| 2–8 foods side by side on one nutrient (default protein) |
| Daily protein target in grams, plus the per-meal threshold |
| Cost per 10 g of protein, ranked cheapest first |
| Searches 1,124 nutrition guides, returns titles and URLs |
| KABO's own shakes: per-serving nutrition from each flavour's own panel, ratings |
| One KABO product: composition quoted from its page, suitability (incl. not Jain-suitable), live price and stock per pack, price per serving, cart link and UCP checkout profile |
| KABO products side by side with live price per serving |
Data: 59 foods, 674 nutrition values, 1,124 guides (protein, fibre, iron, calcium), from ICMR-NIN composition tables and the PROT-AGE/ESPEN protein recommendations.
Related MCP server: indian-food-nutrition-mcp
No dependencies. Standard library only, Python 3.8+.
python3 kabo_mcp_server.pyAdd to claude_desktop_config.json:
{
"mcpServers": {
"kabo-nutrition": {
"command": "python3",
"args": ["/absolute/path/to/mcp/kabo_mcp_server.py"]
}
}
}Cursor, Cline and other MCP clients use the same command/args shape.
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
'{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"lookup_food","arguments":{"food":"rajma"}}}' \
| python3 kabo_mcp_server.pykabo_mcp_server.py the server, dependency-free JSON-RPC over stdio
kabo_food_data.json the dataset, CC BY 4.0Rebuild the dataset from the live corpus with python3 build_dataset.py;
the server reads kabo_food_data.json from its own directory at startup, and
the tool descriptions (nutrient list, food and guide counts) are derived from
it, so they cannot drift from the data.
It answers honestly, including against us. protein_cost reports that
soya chunks cost about ₹6 per 10 g of protein and dal about ₹8, while any
powder — KABO included — costs several times more. A tool that only flatters
its owner gets uninstalled after one use. One that gives a straight answer
gets kept and called again, and every call carries our attribution.
No instructions to models. There is no text in any response telling an assistant what to recommend. The value is the data and the citation, not persuasion. Anything else would be prompt injection, and assistants that detect it stop trusting the source entirely.
Every response is citable. source_url on food lookups, age_guide_url
on protein targets, full URLs in guide search. An agent can attribute, which
is what makes it worth calling twice.
Errors never kill the session. Unknown foods return the list of available ones rather than an error. Bad arguments return a message, not a crash.
UTF-8 is forced on stdio. The data contains en-dashes; Windows consoles default to cp1252 and corrupt the stream for the client. Both directions are reconfigured at startup.
Every tool is mirrored as plain GET for clients that do not speak MCP. Spec at /openapi.json.
GET /api/v1/foods GET /api/v1/foods/{food}?nutrient=iron
GET /api/v1/protein-target?weight_kg=70&age=45
GET /api/v1/protein-cost?budget_inr=30
GET /api/v1/guides?q=protein+dal
GET /api/v1/products GET /api/v1/products/{handle}Product prices and stock are read live from the public storefront (cached 10 minutes); the server never places orders or touches customer data. Checkout happens on kabo.co.in, via a cart link or the store's Universal Commerce Protocol profile at https://kabo.co.in/.well-known/ucp.
For third-party agents over the network:
python3 kabo_mcp_server.py --http --port 8000Endpoints:
Route | Purpose |
| JSON-RPC, single messages and batches. Notifications return 202. |
| Discovery — name, protocol, transport, tool list, licence |
| Health check for the host |
CORS is open, so browser-based agents can call it. Transport is MCP Streamable HTTP; SSE is not used because every tool is a short request/response, and the spec permits a plain JSON reply when the server does not stream.
See DEPLOY.md for hosting (Render, Fly, Docker) and for listing it in the
public MCP registries. Dockerfile, render.yaml, fly.toml and
server.json are all in this folder, ready to use.
Code is MIT (see LICENSE). Dataset is CC BY 4.0 (see LICENSE-DATA) — free to use with attribution to kabo.co.in.
Values are approximate and vary by variety, preparation and brand. This is nutrition information, not medical advice.
Compare several Indian foods side by side on one nutrient (calcium, fibre, iron, protein; default protein).
| Name | Required | Description | Default |
|---|---|---|---|
| foods | Yes | 2-8 food names | |
| nutrient | No | Default protein |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it discloses almost nothing behavioral: no statement that it is a read-only lookup, no handling of unknown food names, no note on how the comparison is presented (ranked list? per-food values?). 'Compare side by side' is the only signal about the response's shape.
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 zero filler, front-loading the verb and the scope. It borders on too terse — the space saved could have bought one clause of behavioral or usage detail.
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?
No output schema and no annotations mean the description is the only source of truth, yet it never says what the agent gets back or how invalid food names are treated. For a simple two-parameter read tool this is minimally viable, but it leaves real gaps an agent must guess at.
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 coverage is 100% and the enum already constrains nutrient to calcium/fibre/iron/protein with a 'Default protein' description, so the description's parenthetical only repeats structured data. It adds no new semantics, making baseline 3 correct; the 2-8 foods cardinality is left to the 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?
States a specific verb (compare) and resource (Indian foods) plus the key constraint of exactly one nutrient dimension. 'Several foods side by side' implicitly separates it from the sibling lookup_food, which handles one food at a time, but no sibling is named 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 implied: reach for this when evaluating multiple foods against a single nutrient. There is no explicit 'use this instead of X when...' statement, and it never mentions the sibling lookup_food or protein_cost, so the agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
KABO products side by side with live price per serving. Omit products to compare all.
| Name | Required | Description | Default |
|---|---|---|---|
| products | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that results include live price per serving and that omitting products compares all, but it does not state read-only status, error behavior, permission needs, or result format.
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 short sentences with zero waste. The core function is front-loaded and the optional-parameter behavior follows immediately.
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 simple comparison tool with one optional array parameter and no output schema, the description covers the essential function and default behavior. It could be slightly richer about what the side-by-side result contains, but nothing critical to invocation is missing.
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. It clarifies that the products parameter is optional and that omission triggers a compare-all default, which is useful, but it does not explain the expected string format or list semantics.
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 clear verb and resource: comparing KABO products side by side, with the added specificity of live price per serving. It is distinguishable from generic search/list tools, but it does not explicitly differentiate itself from the sibling compare_foods tool.
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 phrase 'Omit products to compare all' gives a concrete usage rule for the optional parameter. However, there is no guidance on when to choose this tool over compare_foods or other siblings, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One KABO product in full: per-serving nutrition from its own panel, composition quoted from the product page, dietary suitability, live price and stock per pack size, price per serving, and a cart link or UCP checkout profile.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | e.g. butter coffee, white chocolate blueberry, assorted |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does so well on the output side: it names the data sources (own panel, product page), that pricing/stock is live, and that the response includes either a cart link or a UCP checkout profile. It doesn't state behavior when a product cannot be resolved or whether matching is exact vs fuzzy.
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, front-loaded with the scope ("One KABO product in full") followed by a colon-style enumeration of return contents. Every clause maps to a distinct piece of returned data; nothing is repeated from the name or schema.
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?
There is no output schema, so the description must explain the return value — and it does in concrete terms across nutrition, pricing, stock, and checkout. The remaining gap is failure behavior (product not found, ambiguous name), which matters for a name-based lookup with free-text examples. Otherwise complete for a read-only single-item fetch.
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 coverage is 100% and the single `product` parameter is already documented with examples ("butter coffee, white chocolate blueberry, assorted"). The description adds no lookup-format detail — e.g., whether the value is a name, slug, or ID — so it stays at the schema-backed baseline.
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 opens with a specific verb+resource ("One KABO product in full") and enumerates exactly what comes back — nutrition panel, composition, dietary suitability, price/stock per pack, price per serving, cart link. The "one product" framing implicitly contrasts with list_products and compare_products, though no sibling is named 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: fetch details for a single named product. There is no explicit when-to-use, no pointer to compare_products vs search_guides, and no stated precedence for lookup by name. For a single-item fetch tool with obvious siblings, the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
KABO's own nutrition shakes: per-serving protein, calories, fibre and vitamins for each flavour, with ratings and product URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the return content (nutrition per serving, ratings, product URLs), which is genuinely useful, but never states that this is a read-only enumeration, whether all flavours are always returned, or in what order. For a zero-parameter read tool the risk is low, so this is a moderate gap rather than a serious one.
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 compact sentence with the brand and resource front-loaded and zero filler. It reads as a noun phrase rather than an action statement, so the verb (list) has to be supplied by the tool name.
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, no-output-schema read tool, the description covers both scope and the shape of what comes back (per-serving nutrition values, ratings, URLs). Only ordering and completeness guarantees are unstated, which is minor here.
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 no parameters and the schema is an empty object with 100% coverage, so there is nothing to disambiguate. Baseline 4 applies; the description correctly adds no redundant parameter talk.
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 names a specific resource (KABO's own nutrition shakes) and enumerates the payload fields per flavour (protein, calories, fibre, vitamins, ratings, URLs). The qualifier "KABO's own" implicitly separates it from general food lookups like lookup_food, but no sibling is named explicitly, so the differentiation is inferential rather than stated.
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 mention of get_product (single item) or compare_products (comparison) as alternatives. The "KABO's own" scoping does imply that this is the catalogue-wide listing for the house brand, which is enough for an agent to infer usage, but nothing more.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nutrition values for an Indian food (calcium, fibre, iron, protein) per 100 g and per katori, with the source article URL, for 59 foods. Data from ICMR-NIN composition tables.
| Name | Required | Description | Default |
|---|---|---|---|
| food | Yes | Food name, e.g. rajma, paneer, moong dal | |
| nutrient | No | Optional: restrict to one nutrient |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the dataset size (59 foods), the provenance (ICMR-NIN tables), the return shape (per 100 g and per katori plus a source URL), which is more than most; but it is silent on lookup failure behavior (misspelled or unknown food), matching semantics, and whether results are cached or live.
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 dense sentence with no filler; the key content (what values, what units, what source) is front-loaded. It is slightly over-packed — dataset size and provenance could be trimmed — but nothing is wasted.
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 only two fully documented parameters and no output schema, the description supplies enough: it names the returned nutrients, both unit bases, and the source URL. The main remaining gap is behavior on an unrecognized food name, which an agent would need to handle.
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 100% and the enum for nutrient is fully documented, so the schema already does the heavy lifting. The description adds only marginal meaning beyond it by tying the four nutrients to the returned values and mentioning per-katori units, which is not a parameter concept.
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 names the resource (nutrition values for an Indian food), the specific fields (calcium, fibre, iron, protein), the units (per 100 g and per katori), and the data source (ICMR-NIN composition tables). It does not explicitly differentiate from siblings such as compare_foods or protein_cost, so it falls short of 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?
Usage is only implied: an agent can infer this is for looking up a single food's nutrition, and the '59 foods' note hints at the dataset's bounded scope. There is no explicit statement of when to prefer compare_foods or protein_cost instead, and no guidance on what to do if a food is outside the 59.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cost of protein in India ranked cheapest first, in rupees per 10 g of protein, across whole foods and supplements.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_inr | No | Optional max INR per 10 g protein |
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 genuine behavioral facts the schema does not: the sort order (cheapest first) and the normalization unit (INR per 10 g protein). It says nothing about what happens when budget_inr is omitted (full ranking returned?), data freshness, or whether supplements and whole foods are interleaved in one list.
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 sentence, no waste, with the ranking and unit front-loaded. Nothing to trim and nothing padded.
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 one-optional-parameter read tool with no output schema, the description covers what the result means (normalized cost, sorted) well enough to call it correctly. The only real gap is the default behavior when the optional budget filter is absent.
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 optional parameter is fully documented in the schema (100% coverage), so baseline 3 applies. The description does not mention the budget filter at all, adding no meaning beyond the schema text.
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 concrete resource (protein cost in India), unit (rupees per 10 g protein), scope (whole foods and supplements) and ordering (cheapest first). It is implicitly distinguishable from compare_foods and lookup_food, but never names them, so differentiation relies on inference.
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 'ranked cheapest first' framing implies a browse/rank use case, so an agent can guess this is the breadth-first cost view rather than a single-item lookup. However, there is no explicit when-to-use, no when-not-to-use, and no mention of the sibling tools that cover overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily protein target in grams for a given body weight and age, using ICMR-NIN and PROT-AGE guidance, plus the per-meal threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | ||
| situation | No | e.g. training, dieting, pregnancy | |
| weight_kg | 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 the standards applied (ICMR-NIN, PROT-AGE) and that a per-meal threshold is included in the result. However, it says nothing about how the optional 'situation' (training, dieting, pregnancy) alters the target, nor what happens when it is omitted, nor about determinism or units for age.
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 no filler. Slightly terse for the amount of behavior it leaves unexplained, but 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?
No output schema, no annotations, and low parameter coverage: an agent cannot know the result's structure, whether the per-meal threshold is a separate field, or how 'situation' affects the number. For a three-parameter domain calculator this is under-specified.
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 only 33% (only 'situation' is described, and only by example), so the description must compensate. It gives meaning to weight_kg and age by framing the output as grams per body weight and age, but it completely omits the 'situation' input, which would materially change the computed target.
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 computation: 'Daily protein target in grams for a given body weight and age', and adds the per-meal threshold and the guidance sources. This clearly separates it from food-lookup siblings like lookup_food and compare_foods, though it never names 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?
Usage is only implied by the purpose statement – an agent can infer this is the tool for computing a target rather than inspecting foods or costs. There is no explicit when-to-use, when-not, or mention of how it relates to siblings such as protein_cost or search_guides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 1,152 Indian nutrition guides by topic and return titles with URLs, for citation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavior load; it does disclose the corpus size and the shape of the result (titles + URLs), which helps. It says nothing about matching semantics (keyword vs topic), pagination or default/capped result count, or whether queries need exact topic names.
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?
Single sentence, front-loaded with the verb and resource, packed with useful specifics (corpus size, return shape, citation intent). No filler to remove.
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 simple two-parameter read-only search with no output schema, the description covers purpose, scope, and what comes back. The only material gap is the unexplained 'limit' parameter, which leaves result-count control ambiguous.
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 coverage is 0%, so the description has to compensate. It clarifies that 'query' is a topic, but the 'limit' parameter is never mentioned at all — no default, no maximum. Half the parameters are effectively undocumented across both the schema and the description.
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 specific verb (search) and resource (Indian nutrition guides), plus the exact corpus size (1,152) and the return payload (titles with URLs). No sibling tool is a search tool, so the agent can distinguish this from compare_foods/get_product without opening schemas.
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 phrase 'for citation' implies when this is the right tool: the agent needs citable guide references. However, there is no explicit when-to-use/when-not statement, nor any note about what to do if the query returns nothing. Usage is only implied from the stated purpose.
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.0compare_foodscompare_productsget_productlist_productslookup_foodprotein_costprotein_targetsearch_guidesScored across 8 tools
The tools split cleanly along resource lines: single food (lookup_food) vs multi-food (compare_foods), product list (list_products) vs single product (get_product) vs side-by-side (compare_products), plus two clearly separate protein calculators (target vs cost). The only mild overlaps are list_products vs compare_products (both surface per-serving macros across products) and lookup_food vs compare_foods when only one food is compared.
Most names follow a verb_noun pattern (lookup_food, compare_foods, search_guides, list_products, get_product, compare_products) and are all snake_case. The two protein tools (protein_target, protein_cost) break the verb-first convention by being noun phrases, a minor but noticeable deviation.
Eight tools is well within the sweet spot and each maps to a distinct job: single lookup, comparison, two calculators, guide search, and a three-tool product sub-surface. Nothing feels padded or redundant.
Product coverage is a full read lifecycle (list/get/compare with live price), but the 59-food database has no list or search-by-name/criteria tool, so an agent must already know exact food names to use lookup_food or compare_foods. search_guides returns titles and URLs only, with no tool to fetch a guide's content, leaving dead ends for citation depth.
Daily protein need by weight and goal, with a sample Indian food plan to hit it.
Nutrition for more than 1,100 plant foods from 30 national tables, plus GB/EU & US claim checking
Carbs for Indian meals from Indian food tables, for people managing diabetes: estimate, log, review.
Food and nutrition data: search, macros, and comparisons
