taco-br-mcp

Overview Schema Source Related Servers Discussions Admin

Convert a household measure to grams

convert_household_measure

Read-only

Convert Brazilian household measures (e.g., 2 colheres de sopa, 1 fatia) for TACO foods to grams. Returns candidates for ambiguous measures and flags uncovered foods or measures instead of guessing.

Instructions

Convert a Brazilian household measure (e.g. 2 colheres de sopa, 1 unidade, 1 fatia) of a TACO food to grams, using the IBGE POF table through a hand-curated mapping. Only some foods are covered; it never guesses: on ambiguity it returns candidates, and for uncovered foods or measures it says so. Pass food_id (from search_food) or food_query.

Input Schema

Name	Required	Description
`food_id`	No	TACO food number, as returned by search_food. Preferred over food_query.
`measure`	Yes	Household measure in Portuguese, e.g. "colher de sopa", "unidade", "fatia", "concha", "copo americano".
`quantity`	No	How many of the measure (default 1; may be fractional, e.g. 0.5).
`food_query`	No	Food name in Portuguese, used only when food_id is not given; must match exactly one food.

Output Schema

Name	Required	Description
`food`	No	The resolved food (not set for ambiguous_food / no_food_match).
`grams`	No	quantity x grams_per_measure (status ok).
`notes`	Yes	Caveats and next steps.
`source`	Yes	Citation for the nutrient table.
`status`	Yes	ok: grams computed. ambiguous_food: the query matched several foods, pick an id from candidates. no_food_match: no food found. no_household_data: this food has no curated household measures, ask for grams. unknown_measure: use one of available_measures.
`measure`	No	The matched household measure (status ok).
`quantity`	No	How many of the measure (status ok).
`candidates`	No	Foods matching the query (status ambiguous_food), best first.
`household_source`	Yes	Citation for the household measure weights.
`grams_per_measure`	No	Weight of one measure in grams (status ok).
`available_measures`	No	Measures known for this food (status unknown_measure).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 31, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses important behavioral constraints: only some foods are covered, the mapping is hand-curated, it never guesses, ambiguity returns candidates, and uncovered cases are reported. These are exactly the edge-case behaviors an agent needs to know before calling.

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 front-loaded with purpose and coverage constraints, then ends with the key parameter routing. It is compact and every sentence contributes useful context.

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 the output schema, full parameter descriptions, and readOnly annotation, the description supplies the remaining critical context: source table, coverage limits, ambiguity handling, and uncovered-case behavior. Nothing essential for correct invocation appears to be missing.

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 the schema already defines food_id, measure, quantity, and food_query in detail. The description reinforces that food_id comes from search_food and gives measure examples, but it adds little beyond the structured parameter documentation.

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 uses a specific verb and resource: converting Brazilian household measures of TACO foods to grams. It also names the underlying source (IBGE POF) and scope, so an agent can distinguish this from search_food, get_nutrients, and other siblings without opening the schema.

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?

It clearly states when this tool is appropriate and what to do before calling it by pointing to search_food for food_id. It also sets expectations for uncovered foods and ambiguous measures. It stops short of explicitly naming alternatives to use instead of this tool, but the practical usage context is clear.

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

Deploy Server