Checks food and cosmetic ingredients against each household member's allergies, incl. hidden names.
Scored across 3 tools
Each tool targets a clearly distinct unit of work: checking a full product against a household, listing supported allergens, and resolving a single ingredient. The descriptions make the boundaries explicit, so an agent can reliably choose between checking a product and looking up an ingredient.
All three names follow a predictable verb_noun pattern: check_product_allergens, list_supported_allergens, lookup_ingredient. The verbs are varied but purposeful and consistent in style, with no camelCase/snake_case mixing.
Three tools is well-scoped for a focused allergen-checking service. Each tool earns its place: one for full-product checks, one for discovery of supported allergens, and one for ingredient-level resolution.
The core workflow is covered: users can discover supported allergens, resolve individual ingredients, and check a product against one or more household members. Minor gaps remain around managing household allergy profiles or batch-checking multiple products, but agents can work around these.
Check a product's ingredient list against the allergies of one or more people in a household. Catches allergens listed under other names (e.g. "arachis oil" for peanut, "casein" for milk, Latin plant names in cosmetics) and does not let "free from" claims hide a real ingredient. Covers food and cosmetics. Call this whenever the user asks if a product or ingredient list is safe for someone with allergies, even if the answer seems obvious, and before recommending or buying a food, cosmetic or household product for someone with allergies.
| Name | Required | Description | Default |
|---|---|---|---|
| household | Yes | One entry per person, each with their allergens. | |
| ingredients | Yes | The product's ingredient list, or the product page text that contains it. | |
| product_name | No | Product name, for the answer only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: alias matching (arachis oil, casein, Latin names) and that 'free from' marketing claims are not trusted. It does not describe the shape of the result, which matters since there is no output schema.
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?
Front-loaded with the core action and the alias-catching behavior before the usage directive. Slightly padded by the closing sentence, which re-lists 'food, cosmetic or household product' already implied by 'Covers food and cosmetics'.
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?
Given three parameters at full schema coverage and rich annotations, the only real omission is what the response contains (per-person verdicts? matched ingredients?), which is not covered by any output schema. Otherwise an agent has everything needed to call it correctly.
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%, so the schema already explains ingredients, household entries, per-person allergens and severity. The description adds conceptual color (household = multiple people, hidden ingredient names) but no parameter-specific guidance beyond that, so the baseline 3 applies.
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 (check) plus a precisely scoped resource (a product's ingredient list against the allergens of one or more household members). The mention of alias detection and coverage of both food and cosmetics clearly separates it from lookup_ingredient and list_supported_allergens.
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?
Explicit triggering condition: 'whenever the user asks if a product or ingredient list is safe' plus a proactive directive ('even if the answer seems obvious', 'before recommending or buying'). It does not name when NOT to use it or point to lookup_ingredient / list_supported_allergens as alternatives, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the allergens this service can check (food and cosmetic), with the other names users may type for them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing that results include alternate names users might type, but says nothing about result ordering, size, or whether the list is static.
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; the scope qualifier and the alias-names detail both earn their 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?
With no output schema, the description must sketch the return value, and it does: allergen names plus alternative spellings, limited to food and cosmetic domains. Adequate for a trivial zero-param listing tool, though it could note whether categories or IDs are returned.
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 the baseline of 4 applies; there is nothing for the description to clarify beyond the implicit fact that no filtering arguments exist.
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 and resource ('List the allergens this service can check') and adds scope (food and cosmetic) plus the fact that alias names are included. It is clearly a reference/enumeration tool, distinguishable in kind from check_product_allergens and lookup_ingredient, though it never names those siblings 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 should call this to discover valid allergen names or resolve aliases. There is no explicit when-to-use clause, no statement that this should precede check_product_allergens, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell which allergens, if any, an ingredient name belongs to, e.g. "sodium caseinate" -> milk, "Prunus amygdalus dulcis oil" -> tree nuts, "DMDM hydantoin" -> formaldehyde releasers.
| Name | Required | Description | Default |
|---|---|---|---|
| ingredient | Yes | One ingredient name as printed on a label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, and non-destructive, so safety is covered. The description usefully reveals that matching is synonym/INCI-aware (e.g. 'Prunus amygdalus dulcis oil' → tree nuts), but it doesn't say what happens for an unrecognized ingredient or how many allergen groups can come back.
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 the purpose stated first and examples used as compact illustration. No wasted words.
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 no output schema, the description does convey the return value ('which allergens, if any') including the empty case via 'if any'. The only gap is behavior on unrecognized or ambiguous ingredient names.
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 parameter is already documented as 'One ingredient name as printed on a label.' The examples reinforce the expected input format but add little beyond the schema, so the baseline of 3 applies.
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 ('Tell which allergens') and resource ('an ingredient name'), with three concrete examples that make the ingredient→allergen-group mapping unmistakable. It doesn't explicitly distinguish itself from check_product_allergens, but the singular-ingredient scope is clear from the phrasing and examples.
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 examples imply usage (label-printed ingredient names, INCI-style names), but there is no explicit when-to-use or when-to-prefer-a-sibling guidance, e.g. no statement that this is the ingredient-level lookup versus the product-level check_product_allergens.
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.
check_product_allergenslist_supported_allergenslookup_ingredientCan this person eat this? Allergens, additives and nutrition from a barcode.
Look up a packaged food by barcode, search and compare products, and check listed allergens.
Household-aware cooking brain: pantry, meal suggestions, dietary safety, recipes, shopping lists.
Check products against FDA food, drug and device recalls; drug labels, NDC, 510(k) via openFDA
Add one secure layer between your agents and this server.