Forkmate

by ai.forkmate

Overview Discussions Admin

Server Details

Free AI calorie & macro tracker: tell your AI what you ate and it logs it to your private food diary

Ownership verified

Status: Healthy
Uptime: 100.0% over 54 days
OAuth: Works in Glama
Last Tested: 2026-10-10 18:13
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: shawnazar/forkmate-mcp
GitHub Stars: 0

TDQS

A4.1/5.0

Scored 2026-10-07 03:20 across 13 tools

Disambiguation5/5

The tools target distinct resources and actions: diary CRUD, profile get/update, food search, barcode lookup, usual foods, consent, feedback, and diagnostics. The read-diary tools (get_day, get_range, get_usual_foods) differ by scope and are clearly described.

Naming Consistency4/5

Most tools follow a consistent snake_case verb_noun pattern: get_*, update_*, delete_*, log_*, search_*, lookup_*, send_*, give_*. Only whoami deviates, using a conventional diagnostic name rather than the same verb_noun pattern.

Tool Count5/5

13 tools is well-scoped for a food-diary and health-preference assistant. Each tool supports a distinct capability, and there is no obvious bloat or missing core action.

Completeness4/5

Core diary lifecycle coverage is strong: log, read by day/range, update, and delete, plus profile and food lookup. Minor gaps remain around saved-recipe management, initial caffeine/fluid logging, and consent withdrawal, which is delegated to Settings.

Available Tools

14 tools

delete_mealA

DestructiveIdempotent

Inspect

Delete one food from a diary entry (by item_index), or the whole entry (without it). The entry is identified by id and local_date. Deletion is permanent, with no undo; deleting the last food removes the entry, and an id that matches no entry on that date returns a not-found error and deletes nothing. All calorie and macro values, including carbohydrates, are estimates from USDA FoodData Central, Open Food Facts, the user's own entry or an AI assistant's estimate — approximate, not lab-measured or specific to a package or batch, and not suitable for insulin dosing (including carb counting for a meal bolus), blood-glucose prediction or any other medical decision.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	The entry id, shown with each entry in the reply text when a meal is logged or a day or range is read.
`item_index`	No	Which food to remove (0-based). Omit to delete the whole entry.
`local_date`	Yes	YYYY-MM-DD diary date of the entry.

Output Schema

ParametersJSON Schema

Name	Required	Description
`entry`	Yes	What remains of the entry, or null.
`removed`	Yes
`day_totals`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

Despite annotations already carrying destructiveHint and idempotentHint, the description adds substantial unstated behavior: permanence with no undo, the cascade where deleting the last food removes the entry, and the fact that a non-matching `id` errors and deletes nothing. These are exactly the edge cases an agent needs before calling a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The deletion semantics are front-loaded and efficient, but the trailing multi-clause disclaimer about calorie/macro estimates from USDA, Open Food Facts and AI estimates has no bearing on a delete operation and consumes roughly half the text. That is off-topic filler in an otherwise tight definition.

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?

With a rich annotation set and an output schema present, the description supplies everything still needed: scope selection, permanence, cascade-to-entry-removal, and error behavior. Nothing required to invoke this tool correctly is 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 `id`, `item_index` (0-based, omit to delete the whole entry) and `local_date` are already fully documented. The description restates the same semantics (item_index selects a food, omission targets the entry) without adding format or boundary details beyond the schema, so the baseline 3 applies.

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 first sentence states a specific verb and resource ('Delete one food from a diary entry ... or the whole entry') and distinguishes the two scopes by the presence or absence of `item_index`. An agent can separate this from siblings like log_meal, update_meal, and get_day without opening any 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 the two operating modes and the condition that selects each ('by item_index' vs 'without it'), plus the not-found error case, which is genuine when-to-use guidance. It does not name update_meal as the non-destructive alternative, so it stops short of explicit alternative routing.

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

get_dayA

Read-only

Inspect

Read the user's food diary for one day: its entries, each listed with its id and each food with its item_index, quantity and macros, and calorie/macro totals. All calorie and macro values, including carbohydrates, are estimates from USDA FoodData Central, Open Food Facts, the user's own entry or an AI assistant's estimate — approximate, not lab-measured or specific to a package or batch, and not suitable for insulin dosing (including carb counting for a meal bolus), blood-glucose prediction or any other medical decision.

ParametersJSON Schema

Name	Required	Description	Default
`local_date`	No	YYYY-MM-DD; defaults to today.

Output Schema

ParametersJSON Schema

Name	Required	Description
`totals`	Yes
`entries`	Yes
`local_date`	Yes	A local date, YYYY-MM-DD.

TDQS

A4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial context beyond them: the exact shape of the returned data (entries with ids, item_index, quantity, macros, totals) and the critical caveat that values are estimates from varied sources and unsuitable for medical decisions.

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?

Front-loaded with the core action and return shape, then the disclaimer. The disclaimer is long but each clause (sources, approximation, medical exclusions) carries distinct information, so it is mostly earned rather than padded.

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?

With annotations covering safety, an output schema covering return values, and 100% parameter coverage, the remaining burden is domain caveats — which the description handles thoroughly by disclosing data provenance and medical limitations. Nothing an agent needs to call it correctly is 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?

Only one parameter, and schema coverage is 100%, so the schema fully documents local_date's format and default. The description's "one day" phrasing hints at the date scope but adds no syntax or defaulting detail beyond the schema, matching the baseline.

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?

States a specific verb and resource ("Read the user's food diary") and scopes it precisely to "one day," which implicitly separates it from get_range and the mutation siblings. It doesn't name an alternative explicitly, so it falls just short of the top tier.

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 one-day scope implies when to use it versus get_range, and the closing disclaimer clearly rules out medical uses (insulin dosing, glucose prediction). However, there is no explicit when-to-use or when-not-to-use routing to the sibling tools, leaving usage largely inferential.

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

get_notifications

Read-only

Inspect

Reads the user's Forkmate notifications, newest first: notices that something the user reported was fixed, Forkmate release notes (what's new), and account messages. Each one has a kind, a title, a body, an optional link, the day it arrived and whether it is unread, and the reply includes the unread count. Read-only: reading marks nothing as read. Notifications older than 180 days are not kept.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many to return, newest first (1 to 20, default 10).
`unread_only`	No	Only unread notifications. Defaults to false.

Output Schema

ParametersJSON Schema

Name	Required	Description
`unread_count`	Yes
`notifications`	Yes

get_preferencesA

Read-only

Inspect

Read the user's food profile: diet style, allergies (a structured list of the major US allergens), foods they like, foods they dislike, and a typical-portion note. Allergies are self-reported and not a safety guarantee; the response includes an allergy_disclaimer. Likes and dislikes are taste preferences, not allergies or restrictions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`likes`	Yes
`dislikes`	Yes
`allergies`	Yes
`diet_style`	Yes
`portion_note`	Yes
`allergy_disclaimer`	Yes

TDQS

A4/5.0

Behavior5/5

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

Beyond the annotations' read-only safety profile, the description discloses important behavioral caveats: allergies are self-reported and not a safety guarantee, the response includes an allergy_disclaimer, and likes/dislikes are taste preferences rather than restrictions. These are exactly the kind of semantic warnings an agent needs before relying on the returned data.

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 three sentences, front-loaded with the core purpose and followed by two clearly relevant caveats. Every sentence earns its place and there is no redundant or filler content.

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 parameterless read-only tool with annotations and an output schema, the description covers the key return semantics and the critical allergy caveat. The output schema can carry structural return details, so no further explanation is required for correct invocation.

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?

The tool takes zero parameters, so there is no parameter semantics to document in the description. The baseline for a parameterless tool is 4, and nothing in the description misleads about input requirements.

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 uses a specific verb ('Read') and resource ('the user's food profile'), then enumerates the returned fields: diet style, allergies, likes, dislikes, and portion note. It is clearly distinguishable from write-oriented siblings like update_preferences in practice, but it does not explicitly name or contrast any alternative tool.

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 says what is read but gives no explicit when-to-use condition, prerequisites, or comparison to alternatives such as update_preferences or get_usual_foods. An agent must infer that this is the read path for food preferences.

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

get_rangeA

Read-only

Inspect

Read the user's food diary across a date range, with per-day calorie/macro totals and each entry listed with its id. All calorie and macro values, including carbohydrates, are estimates from USDA FoodData Central, Open Food Facts, the user's own entry or an AI assistant's estimate — approximate, not lab-measured or specific to a package or batch, and not suitable for insulin dosing (including carb counting for a meal bolus), blood-glucose prediction or any other medical decision.

ParametersJSON Schema

Name	Required	Description	Default
`end`	Yes	YYYY-MM-DD (inclusive).
`start`	Yes	YYYY-MM-DD (inclusive).

Output Schema

ParametersJSON Schema

Name	Required	Description
`end`	Yes	A local date, YYYY-MM-DD.
`days`	Yes
`start`	Yes	A local date, YYYY-MM-DD.
`entries`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, non-destructive, closed-world), and the description adds meaningful context beyond them: the data provenance (USDA FoodData Central, Open Food Facts, user or AI estimates) and an explicit warning that values are not suitable for insulin dosing or glucose prediction. That is genuine domain-specific behavioral disclosure, not restatement of 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?

Front-loads what the tool returns before the disclaimer, which is the right order for an agent. The second sentence is long and somewhat repetitive in its list of prohibited uses, but each clause carries distinct safety meaning rather than filler.

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?

An output schema exists, so return values need not be re-explained, and the description still summarizes them usefully while adding the estimate caveat. For a two-parameter read tool this is effectively complete; only the missing routing guidance to get_day is a minor gap.

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% and both start/end are documented as inclusive YYYY-MM-DD, so the baseline is 3. The description adds no format or boundary semantics of its own.

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?

States a specific verb ('Read') and resource ('the user's food diary') plus the scope and return shape (per-day totals, each entry with its `id`). This clearly distinguishes it from the single-day sibling get_day, 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'across a date range' and the required start/end parameters, but the description never says when to prefer this over get_day or how it relates to the other diary tools. No exclusions or alternatives are offered, so 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.

get_usual_foodsA

Read-only

Inspect

Read what the user usually and recently eats. usual lists their most-logged foods, most frequent first, each with how many times it was logged, the date last eaten, the meal it is usually logged under, and the portion and macros from the last time. recent lists each distinct food from the last seven days with the date last eaten, its meal and how many times. An optional meal narrows both lists to one meal. All calorie and macro values, including carbohydrates, are estimates from USDA FoodData Central, Open Food Facts, the user's own entry or an AI assistant's estimate — approximate, not lab-measured or specific to a package or batch, and not suitable for insulin dosing (including carb counting for a meal bolus), blood-glucose prediction or any other medical decision.

ParametersJSON Schema

Name	Required	Description	Default
`meal`	No	Only foods logged under this meal.

Output Schema

ParametersJSON Schema

Name	Required	Description
`meal`	Yes
`usual`	Yes
`recent`	Yes
`recent_window`	Yes

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already establish read-only, non-destructive, closed-world behavior, and the description adds substantial context on top: the provenance of every calorie/macro value (USDA FoodData Central, Open Food Facts, user entry, AI estimate), the fact that values are approximate and not batch- or package-specific, and an explicit prohibition on medical use such as insulin dosing or glucose prediction. This is exactly the kind of behavioral disclosure annotations cannot carry.

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?

Front-loads the purpose, then mode details, then the filter interaction, then the safety caveat — a logical progression with no filler. The disclaimer is long but every clause (provenance, approximation, medical unsuitability) earns its place for a nutrition tool.

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 a single optional enum parameter, an existing output schema, and annotations covering the safety profile, the description supplies everything an agent needs: what each mode returns, how the filter applies, and the reliability limits of the data. Nothing material is missing.

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%, so the `meal` enum is already documented as 'Only foods logged under this meal.' The description adds real meaning beyond that by clarifying the filter applies to BOTH the usual and recent lists, which the schema alone does not convey. Baseline 3 is exceeded but no format or default nuance is added.

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?

States a specific verb and resource (read what the user usually/recently eats) and cleanly splits the tool into two named modes, `usual` and `recent`, with the exact fields each returns. It does not, however, distinguish itself from siblings like search_foods or get_day, so an agent must infer the boundary from the mode semantics alone.

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 makes the trigger conditions for each mode implicit but clear: `usual` for most-logged foods, `recent` for the last seven days, and `meal` to narrow either. There is no explicit when-not guidance or named alternative (e.g., when to prefer search_foods or get_range), so usage is inferred rather than stated.

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

give_consentA

Idempotent

Inspect

Records the user's consent to Forkmate storing and processing their health-related data, as summarised in the consent text that a refused log reply shows. Valid only as the user's own explicit agreement given in this conversation; an assistant agreeing on the user's behalf is not consent. Stores the consent version, the time, the connected app and the user's words, then logs any meal that was waiting for consent. Withdrawal is in Forkmate Settings.

ParametersJSON Schema

Name	Required	Description	Default
`version`	Yes	The consent version shown to the user.
`user_statement`	Yes	The user's own words agreeing, as they replied, e.g. 'yes, I agree'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`logged`	Yes	Meals held until consent, now logged.
`version`	Yes
`consented`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare non-read-only, idempotent, non-destructive behavior, so the bar is lower, but the description goes further: it discloses what is persisted (consent version, time, connected app, user's words) and the side effect of logging a pending meal. It could say more about failure handling if the version mismatches, but the added context is substantial.

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?

Three dense sentences that are front-loaded with the purpose and the consent-validity constraint, followed by storage side effects and the withdrawal path. Every sentence carries information, though the prose is a little packed.

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 consent-recording mutation with full annotation coverage and an output schema, the description covers the authorization requirement, the stored fields, the meal-logging side effect, and how consent is withdrawn. Nothing needed to invoke it correctly is missing.

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%, so the baseline is 3, but the description adds genuine semantics: user_statement must be the user's own words and version corresponds to the consent text shown. This clarifies intent beyond the enum and maxLength 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 names a specific verb and resource ('Records the user's consent to Forkmate storing and processing their health-related data') and adds the downstream effect ('logs any meal that was waiting for consent'). This is clearly distinguishable from siblings like log_meal or update_preferences.

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?

It states the triggering context (a refused log reply shows the consent text), an explicit exclusion ('an assistant agreeing on the user's behalf is not consent'), and where withdrawal happens (Forkmate Settings). When-to-use and when-not-to-use are both covered.

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

log_mealInspect

Add a meal to the user's food diary: one or more food items, each with an optional quantity and macros, plus an optional meal label, date, note and provenance source. The reply names the new entry's id and local_date, which identify it for a later edit or deletion. A restaurant meal's numbers depend most on the restaurant, the specific menu item, its size and its add-ons (cheese, fries, sauce, dressing); a bare dish name is logged as a typical serving. When the user names one of their saved recipes ("my chicken and rice", "half my chili"), send their words as one item's name, with any amount in quantity; Forkmate logs the recipe's own foods and numbers in its place. All calorie and macro values, including carbohydrates, are estimates from USDA FoodData Central, Open Food Facts, the user's own entry or an AI assistant's estimate — approximate, not lab-measured or specific to a package or batch, and not suitable for insulin dosing (including carb counting for a meal bolus), blood-glucose prediction or any other medical decision.

ParametersJSON Schema

Name	Required	Description
`at`	No	ISO-8601 instant the meal was eaten; defaults to now.
`meal`	No	Which meal of the day this was.
`note`	No	Optional free-text note stored with the meal, e.g. 'post-run'.
`said`	No	Optional. The user's own words describing this meal, verbatim (e.g. 'a pint of IPA and wings at the bar'). Only the meal description — not other parts of the conversation.
`items`	Yes	The foods in this meal, one entry per food.
`source`	No	Optional provenance for these items: the `source` label of the food-database candidate they came from ('USDA', 'Open Food Facts', 'Forkmate' or 'product label'), or 'estimate'. Defaults to 'estimate'; unrecognized values are recorded as an estimate.
`local_date`	No	YYYY-MM-DD diary date; defaults to the user's local date (from their timezone).

Output Schema

ParametersJSON Schema

Name	Required	Description
`entry`	Yes	One diary entry: a meal with its foods.
`day_totals`	Yes

lookup_barcode

Read-only

Inspect

Look up a packaged food by its UPC/EAN barcode in Open Food Facts. Returns macros per 100 g, a source label ('Open Food Facts'), and, when known, serving_grams/serving_label for one household serving. All calorie and macro values, including carbohydrates, are estimates from USDA FoodData Central, Open Food Facts, the user's own entry or an AI assistant's estimate — approximate, not lab-measured or specific to a package or batch, and not suitable for insulin dosing (including carb counting for a meal bolus), blood-glucose prediction or any other medical decision.

ParametersJSON Schema

Name	Required	Description	Default
`upc`	Yes	UPC/EAN barcode, digits only (8–14 digits).

Output Schema

ParametersJSON Schema

Name	Required	Description
`candidates`	Yes

search_foods

Read-only

Inspect

Search USDA FoodData Central, Open Food Facts and Forkmate's curated restaurant menus for a named food. Returns up to 5 candidates, each with macros per 100 g, a source label ('USDA', 'Open Food Facts', 'Forkmate' or 'product label', a packaged product's published label read from a cited page and not yet checked by Forkmate), and, when known, serving_grams/serving_label for one household serving. Curated chain-menu candidates include a provenance object that may carry a portion caveat. A query names a food (at least 2 letters, no wildcards); there is no paging. For a bare generic dish ("a burger", "coffee"), the reply also lists details_that_change_it: the details that change that dish's numbers most, such as where it is from, which item, its size and add-ons. All calorie and macro values, including carbohydrates, are estimates from USDA FoodData Central, Open Food Facts, the user's own entry or an AI assistant's estimate — approximate, not lab-measured or specific to a package or batch, and not suitable for insulin dosing (including carb counting for a meal bolus), blood-glucose prediction or any other medical decision.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max candidates to return (default and maximum 5).
`query`	Yes	Food to search, e.g. 'greek yogurt' or 'Chipotle chicken'. At least 2 letters; wildcards are not supported.

Output Schema

ParametersJSON Schema

Name	Required	Description
`candidates`	Yes
`details_that_change_it`	No	For a bare generic dish: the details that change its numbers most (where it's from, which item, size, add-ons).

send_feedbackAInspect

Sends the user's feedback about Forkmate to the Forkmate team: a bug, a food or calorie figure that looked wrong, trouble connecting, or an idea. A person on the Forkmate team reads the note together with the user's account email. It changes nothing in the diary. The note is kept in the user's own account and deleted with it.

ParametersJSON Schema

Name	Required	Description
`about`	No	What the note is about: logging (saving or editing meals), accuracy (a food or number that looked wrong), connect (connecting this AI app), or other.
`rating`	No	The user's thumbs up or down on Forkmate, when they gave one.
`message`	Yes	The feedback, in the user's words (at most 4000 characters).

Output Schema

ParametersJSON Schema

Name	Required	Description
`sent`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Goes well beyond the annotations: it discloses that a human on the team reads the note alongside the account email, that it changes nothing in the diary, and that the note is retained in the user's account and deleted with it. These privacy/retention and side-effect details are genuinely useful and consistent with readOnlyHint=false and destructiveHint=false.

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?

Four tight sentences, front-loaded with the action and content types, then the human-review, no-diary-effect, and retention facts. Every sentence carries unique information with no redundancy.

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?

An output schema exists, so return values need no explanation. The description covers purpose, content categories, privacy handling, side effects, and retention, leaving nothing an agent needs to call this correctly.

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 message, about, and rating with enum meanings. The description adds no parameter-level syntax or format detail beyond what the structured fields provide, so the baseline of 3 applies.

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?

States a specific verb+resource (sends the user's feedback about Forkmate) and enumerates the actual content categories (bug, wrong figure, connection trouble, idea). No sibling tool offers feedback submission, and an agent can identify this immediately 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?

The enumerated categories (bug, inaccurate figure, connecting trouble, idea) make the intended trigger context clear. There is no explicit when-not or named alternative, but no sibling tool overlaps this capability, so routing ambiguity is minimal.

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

update_meal

DestructiveIdempotent

Inspect

Correct a food already in the user's diary — its name, quantity, macros, caffeine or fluid — or change an entry's meal label or note. The entry is identified by id and local_date, and a food by its item_index. Only the fields sent change; macros are merged onto the existing values and overwritten in place, with no history kept. A new quantity sent without macros rescales the food's macros, caffeine and fluid by the new amount ÷ the old one when both are the same kind of amount (a weight, a volume or a count), so '150 g' to '300 g' doubles them; otherwise the macros stay as they were and the reply says so. An entry cannot be moved to another day. All calorie and macro values, including carbohydrates, are estimates from USDA FoodData Central, Open Food Facts, the user's own entry or an AI assistant's estimate — approximate, not lab-measured or specific to a package or batch, and not suitable for insulin dosing (including carb counting for a meal bolus), blood-glucose prediction or any other medical decision.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	The entry id, shown with each entry in the reply text when a meal is logged or a day or range is read.
`meal`	No	Move the entry to a different meal label.
`name`	No	Corrected name of the food.
`note`	No	Replacement note for the entry.
`said`	No	Optional. The user's own words describing this meal, verbatim (e.g. 'a pint of IPA and wings at the bar'). Only the meal description — not other parts of the conversation.
`macros`	No	Corrected macros. Only the components included are changed.
`fluid_ml`	No	Corrected fluid/hydration volume, in millilitres.
`quantity`	No	Portion as stated, e.g. '2' or '1 cup'.
`item_index`	No	Which food in the entry's items[] to edit (0-based). Required when changing a food's name/quantity/macros/caffeine/fluid; omit for an entry-level change (meal/note).
`local_date`	Yes	YYYY-MM-DD diary date of the entry.
`caffeine_mg`	No	Corrected caffeine content, in milligrams.

Output Schema

ParametersJSON Schema

Name	Required	Description
`entry`	Yes	One diary entry: a meal with its foods.
`day_totals`	Yes

update_preferencesA

DestructiveIdempotent

Inspect

Edit the user's food profile: add or remove foods they like or dislike, add or remove allergies from the major US allergen list, or set their diet style. Only the fields sent change. A removal matches a saved name in any casing; a name that matches nothing is reported in not_found and nothing else is affected. Adding a food to likes takes it off dislikes, and the reverse. Lists hold up to 50 foods of up to 80 characters each. The reply is the whole updated profile. It saves what the user states about their own tastes and allergies, not inferences from the diary. Every call carries user_approved: true, meaning the user saw this exact change and said yes to it; a call without it changes nothing and returns the change for the user to approve. A user stating a preference (e.g. 'I dislike olives') has not approved saving it: approval is a later message agreeing to the change as proposed. The server cannot verify that a person gave the approval. Removals work without health-data consent and then return only what was removed. The user can see and edit the same profile in Forkmate's Settings.

ParametersJSON Schema

Name	Required	Description
`add_likes`	No	Foods the user enjoys, e.g. 'salmon'.
`diet_style`	No	The user's diet style; 'none' clears it.
`add_dislikes`	No	Foods the user dislikes, e.g. 'mushrooms'. A taste preference, not an allergy or a restriction.
`remove_likes`	No	Foods to take off the likes list.
`add_allergies`	No	Allergens to add, from the major US allergen list.
`user_approved`	Yes	True only when the previous assistant message proposed this exact change and the user's latest message agreed to it. The user stating the preference itself is not approval.
`remove_dislikes`	No	Foods to take off the dislikes list.
`remove_allergies`	No	Allergens to remove.

Output Schema

ParametersJSON Schema

Name	Required	Description
`likes`	No
`removed`	Yes
`dislikes`	No
`allergies`	No
`not_found`	Yes
`diet_style`	No
`portion_note`	No
`allergy_disclaimer`	No

TDQS

A4.6/5.0

Behavior5/5

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

Adds extensive behavior beyond the annotations: partial-update semantics, case-insensitive removal matching with not_found reporting, cross-field side effects (adding a like drops the dislike), list caps of 50 items/80 chars, consent exemptions for removals, and the approval workflow including the server's inability to verify a human approval. This is exactly the disclosure a destructive mutation needs.

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?

Long, but the length is justified for an 8-parameter destructive mutation with an approval gate, and the core purpose is front-loaded. Some approval wording is repeated across the description and the user_approved schema field, and the Forkmate Settings sentence is marginal, keeping it from a 5.

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 high-complexity tool with an output schema, it covers everything an agent needs: mutation scope, consent rules, list limits, conflict resolution, and a brief note that the reply is the whole updated profile. Nothing material is missing.

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%, so the baseline is 3, and the description adds genuinely new semantics: attention to partial updates, the add-to-likes/remove-from-dislikes interaction, and how removals match saved names by casing. It does not re-explain individual parameter formats, which the schema already handles.

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?

States a specific verb and resource ("Edit the user's food profile") and enumerates the exact operations: add/remove likes and dislikes, add/remove allergies, set diet style. Combined with "Only the fields sent change," an agent can immediately distinguish it from the read counterpart get_preferences without opening a 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?

Gives real usage context: it saves only what the user states about themselves, not diary inferences, and describes the approval gate that must precede a successful call. It stops short of explicitly naming the alternative (e.g. get_preferences for reading) or when-not-to-call, so it is strong but not exhaustive.

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

whoamiA

Read-only

Inspect

Diagnostic: confirms that this connection is signed in to a Forkmate account. Returns no account id, email or other identifier.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`connected`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing what it does NOT return (no account id, email or identifier), preempting a common misuse expectation.

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?

Two short sentences, front-loaded with the diagnostic purpose and followed by the key output caveat. No wasted words.

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?

For a no-parameter diagnostic with an output schema and full annotation coverage, the description supplies the essential behavioral caveat. It is complete enough to invoke correctly, with only the absence of explicit usage routing as a minor gap.

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?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description does not need to compensate for any parameter gap.

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?

States a specific verb+resource: a diagnostic that confirms the connection is signed in to a Forkmate account. It is clearly distinguishable from the food-logging siblings, though it does not explicitly name or contrast them.

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 word 'Diagnostic:' implies usage as a connectivity/auth check, but there is no explicit when-to-use, when-not, or relationship to alternatives like get_preferences. Context is implied rather than stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesOct 10, 2026

Changedlog_meal1 field changed

addedInput schema / properties / said

Added value: +{
+  "description": "Optional. The user's own words describing this meal, verbatim (e.g. 'a pint of IPA and wings at the bar'). Only the meal description — not other parts of the conversation.",
+  "maxLength": 300,
+  "type": "string"
+}

Changedupdate_meal1 field changed

addedInput schema / properties / said

Added value: +{
+  "description": "Optional. The user's own words describing this meal, verbatim (e.g. 'a pint of IPA and wings at the bar'). Only the meal description — not other parts of the conversation.",
+  "maxLength": 300,
+  "type": "string"
+}

1 tool updateOct 9, 2026

Changedsearch_foods1 field changed

addedOutput schema / properties / details_that_change_it

Added value: +{
+  "description": "For a bare generic dish: the details that change its numbers most (where it's from, which item, size, add-ons).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

3 tool updatesOct 9, 2026

Changedlog_meal2 fields changed

changedInput schema / properties / source / description

Previous value: -"Optional provenance for these items: the `source` label of the food-database candidate they came from ('USDA', 'Open Food Facts' or 'Forkmate'), or 'estimate'. Defaults to 'estimate'; unrecognized values are recorded as an estimate."New value: +"Optional provenance for these items: the `source` label of the food-database candidate they came from ('USDA', 'Open Food Facts', 'Forkmate' or 'product label'), or 'estimate'. Defaults to 'estimate'; unrecognized values are recorded as an estimate."

changedInput schema / properties / source / enum

Previous value: -[
-  "USDA",
-  "Open Food Facts",
-  "Forkmate",
-  "estimate"
-]New value: +[
+  "USDA",
+  "Open Food Facts",
+  "Forkmate",
+  "product label",
+  "estimate"
+]

Changedlookup_barcode1 field changed

changedOutput schema / properties / candidates / items / properties / provenance / description

Previous value: -"Chain-menu citation: the chain, its data date, its published page, the assumed build and a caveat."New value: +"Citation: the chain or a product label's brand, its data date, its published page, the assumed build and a caveat."

Changedsearch_foods1 field changed

changedOutput schema / properties / candidates / items / properties / provenance / description

Previous value: -"Chain-menu citation: the chain, its data date, its published page, the assumed build and a caveat."New value: +"Citation: the chain or a product label's brand, its data date, its published page, the assumed build and a caveat."

1 tool updateOct 8, 2026
- Addedget_notifications
2 tool updatesOct 7, 2026
- Addedgive_consent
- Addedsend_feedback

1 tool updateOct 3, 2026

Changedupdate_preferences1 field changed

changedInput schema / properties / user_approved / description

Previous value: -"True when the user approved this exact change in the conversation just before the call."New value: +"True only when the previous assistant message proposed this exact change and the user's latest message agreed to it. The user stating the preference itself is not approval."

14 tool updatesOct 1, 2026

Removedadd_pantry_item

Changeddelete_meal1 field changed

changedOutput schema / properties / entry / anyOf

Previous value: -[
-  {
-    "description": "One diary entry: a meal with its foods.",
-    "properties": {
-      "at": {
-        "description": "ISO-8601 UTC instant the food was eaten.",
-        "type": "string"
-      },
-      "created_at": {
-        "type": "string"
-      },
-      "id": {
-        "type": "string"
-      },
-      "items": {
-        "items": {
-          "properties": {
-            "caffeine_mg": {
-              "type": "number"
-            },
-            "fluid_ml": {
-              "type": "number"
-            },
-            "macros": {
-              "description": "Calories and macros. Estimates, not lab-measured; not for insulin dosing.",
-              "properties": {
-                "carb_g": {
-                  "type": "number"
-                },
-                "fat_g": {
-                  "type": "number"
-                },
-                "kcal": {
-                  "type": "number"
-                },
-                "protein_g": {
-                  "type": "number"
-                }
-              },
-              "required": [],
-              "type": "object"
-            },
-            "name": {
-              "type": "string"
-            },
-            "quantity": {
-              "type": "string"
-            },
-            "source": {
-              "description": "Where the macros came from (e.g. usda, off, client).",
-              "type": "string"
-            }
-          },
-          "required": [
-            "name"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "local_date": {
-        "description": "A local date, YYYY-MM-DD.",
-        "type": "string"
-      },
-      "meal": {
-        "description": "breakfast, lunch, dinner or snack, when set.",
-        "type": "string"
-      },
-      "note": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "id",
-      "at",
-      "local_date",
-      "items"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "One diary entry: a meal with its foods.",
+    "properties": {
+      "at": {
+        "description": "ISO-8601 UTC instant the food was eaten.",
+        "type": "string"
+      },
+      "id": {
+        "description": "Identifies the entry for a later edit or deletion.",
+        "type": "string"
+      },
+      "items": {
+        "items": {
+          "properties": {
+            "caffeine_mg": {
+              "type": "number"
+            },
+            "fluid_ml": {
+              "type": "number"
+            },
+            "macros": {
+              "description": "Calories and macros. Estimates, not lab-measured; not for insulin dosing.",
+              "properties": {
+                "carb_g": {
+                  "type": "number"
+                },
+                "fat_g": {
+                  "type": "number"
+                },
+                "kcal": {
+                  "type": "number"
+                },
+                "protein_g": {
+                  "type": "number"
+                }
+              },
+              "required": [],
+              "type": "object"
+            },
+            "name": {
+              "type": "string"
+            },
+            "quantity": {
+              "type": "string"
+            },
+            "unknown_macros": {
+              "description": "Macros missing from the source data: shown as 0 but unknown, not a real zero.",
+              "items": {
+                "enum": [
+                  "protein_g",
+                  "carb_g",
+                  "fat_g"
+                ],
+                "type": "string"
+              },
+              "type": "array"
+            }
+          },
+          "required": [
+            "name"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "local_date": {
+        "description": "A local date, YYYY-MM-DD.",
+        "type": "string"
+      },
+      "meal": {
+        "description": "breakfast, lunch, dinner or snack, when set.",
+        "type": "string"
+      },
+      "note": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "at",
+      "local_date",
+      "items"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

Changedget_day4 fields changed

removedOutput schema / properties / entries / items / properties / created_at
```
Removed value: -{
-  "type": "string"
-}
```
addedOutput schema / properties / entries / items / properties / id / description
```
Added value: +"Identifies the entry for a later edit or deletion."
```

removedOutput schema / properties / entries / items / properties / items / items / properties / source

Removed value: -{
-  "description": "Where the macros came from (e.g. usda, off, client).",
-  "type": "string"
-}

addedOutput schema / properties / entries / items / properties / items / items / properties / unknown_macros

Added value: +{
+  "description": "Macros missing from the source data: shown as 0 but unknown, not a real zero.",
+  "items": {
+    "enum": [
+      "protein_g",
+      "carb_g",
+      "fat_g"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

Removedget_pantry

Changedget_preferences2 fields changed

addedOutput schema / properties / likes

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "diet_style",
-  "allergies",
-  "dislikes",
-  "portion_note",
-  "allergy_disclaimer"
-]New value: +[
+  "diet_style",
+  "allergies",
+  "likes",
+  "dislikes",
+  "portion_note",
+  "allergy_disclaimer"
+]

Changedget_range4 fields changed

removedOutput schema / properties / entries / items / properties / created_at
```
Removed value: -{
-  "type": "string"
-}
```
addedOutput schema / properties / entries / items / properties / id / description
```
Added value: +"Identifies the entry for a later edit or deletion."
```

removedOutput schema / properties / entries / items / properties / items / items / properties / source

Removed value: -{
-  "description": "Where the macros came from (e.g. usda, off, client).",
-  "type": "string"
-}

addedOutput schema / properties / entries / items / properties / items / items / properties / unknown_macros

Added value: +{
+  "description": "Macros missing from the source data: shown as 0 but unknown, not a real zero.",
+  "items": {
+    "enum": [
+      "protein_g",
+      "carb_g",
+      "fat_g"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

Addedget_usual_foods

Changedlog_meal6 fields changed

changedInput schema / properties / source / description

Previous value: -"Optional provenance for these items, e.g. 'usda' or 'off' for a food-database result. Defaults to 'client' (an estimate); unrecognized values are recorded as 'client'."New value: +"Optional provenance for these items: the `source` label of the food-database candidate they came from ('USDA', 'Open Food Facts' or 'Forkmate'), or 'estimate'. Defaults to 'estimate'; unrecognized values are recorded as an estimate."

changedInput schema / properties / source / enum

Previous value: -[
-  "client",
-  "usda",
-  "off",
-  "usda-index",
-  "mfp-import",
-  "manual",
-  "chain-menu"
-]New value: +[
+  "USDA",
+  "Open Food Facts",
+  "Forkmate",
+  "estimate"
+]

removedOutput schema / properties / entry / properties / created_at
```
Removed value: -{
-  "type": "string"
-}
```
addedOutput schema / properties / entry / properties / id / description
```
Added value: +"Identifies the entry for a later edit or deletion."
```

removedOutput schema / properties / entry / properties / items / items / properties / source

Removed value: -{
-  "description": "Where the macros came from (e.g. usda, off, client).",
-  "type": "string"
-}

addedOutput schema / properties / entry / properties / items / items / properties / unknown_macros

Added value: +{
+  "description": "Macros missing from the source data: shown as 0 but unknown, not a real zero.",
+  "items": {
+    "enum": [
+      "protein_g",
+      "carb_g",
+      "fat_g"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

Changedlookup_barcode7 fields changed

addedOutput schema / properties / candidates / items / properties / provenance

Added value: +{
+  "description": "Chain-menu citation: the chain, its data date, its published page, the assumed build and a caveat.",
+  "properties": {
+    "as_of": {
+      "description": "A local date, YYYY-MM-DD.",
+      "type": "string"
+    },
+    "assumed_build": {
+      "type": "string"
+    },
+    "caveat": {
+      "type": "string"
+    },
+    "chain": {
+      "type": "string"
+    },
+    "source_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "chain",
+    "as_of"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / candidates / items / properties / serving / description
```
Added value: +"The basis the macros are for, e.g. '100 g'."
```

addedOutput schema / properties / candidates / items / properties / serving_approx

Added value: +{
+  "description": "serving_grams is estimated from a drink's volume.",
+  "type": "boolean"
+}

addedOutput schema / properties / candidates / items / properties / source / description
```
Added value: +"Where the figures came from, as a label."
```

addedOutput schema / properties / candidates / items / properties / source / enum

Added value: +[
+  "USDA",
+  "Open Food Facts",
+  "Forkmate",
+  "your entry",
+  "estimate"
+]

addedOutput schema / properties / candidates / items / properties / unknown_macros

Added value: +{
+  "description": "Macros missing from the source data: shown as 0 but unknown, not a real zero.",
+  "items": {
+    "enum": [
+      "protein_g",
+      "carb_g",
+      "fat_g"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / candidates / items / required

Previous value: -[
-  "name",
-  "macros",
-  "source"
-]New value: +[
+  "name",
+  "serving",
+  "macros",
+  "source"
+]

Removedremove_pantry_item

Changedsearch_foods9 fields changed

changedInput schema / properties / limit / description

Previous value: -"Max candidates to return (default 5, clamped to 1–10)."New value: +"Max candidates to return (default and maximum 5)."

changedInput schema / properties / query / description

Previous value: -"Food to search, e.g. 'greek yogurt' or 'Chipotle chicken'."New value: +"Food to search, e.g. 'greek yogurt' or 'Chipotle chicken'. At least 2 letters; wildcards are not supported."

addedOutput schema / properties / candidates / items / properties / provenance

Added value: +{
+  "description": "Chain-menu citation: the chain, its data date, its published page, the assumed build and a caveat.",
+  "properties": {
+    "as_of": {
+      "description": "A local date, YYYY-MM-DD.",
+      "type": "string"
+    },
+    "assumed_build": {
+      "type": "string"
+    },
+    "caveat": {
+      "type": "string"
+    },
+    "chain": {
+      "type": "string"
+    },
+    "source_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "chain",
+    "as_of"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / candidates / items / properties / serving / description
```
Added value: +"The basis the macros are for, e.g. '100 g'."
```

addedOutput schema / properties / candidates / items / properties / serving_approx

Added value: +{
+  "description": "serving_grams is estimated from a drink's volume.",
+  "type": "boolean"
+}

addedOutput schema / properties / candidates / items / properties / source / description
```
Added value: +"Where the figures came from, as a label."
```

addedOutput schema / properties / candidates / items / properties / source / enum

Added value: +[
+  "USDA",
+  "Open Food Facts",
+  "Forkmate",
+  "your entry",
+  "estimate"
+]

addedOutput schema / properties / candidates / items / properties / unknown_macros

Added value: +{
+  "description": "Macros missing from the source data: shown as 0 but unknown, not a real zero.",
+  "items": {
+    "enum": [
+      "protein_g",
+      "carb_g",
+      "fat_g"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / candidates / items / required

Previous value: -[
-  "name",
-  "macros",
-  "source"
-]New value: +[
+  "name",
+  "serving",
+  "macros",
+  "source"
+]

Changedupdate_meal4 fields changed

removedOutput schema / properties / entry / properties / created_at
```
Removed value: -{
-  "type": "string"
-}
```
addedOutput schema / properties / entry / properties / id / description
```
Added value: +"Identifies the entry for a later edit or deletion."
```

removedOutput schema / properties / entry / properties / items / items / properties / source

Removed value: -{
-  "description": "Where the macros came from (e.g. usda, off, client).",
-  "type": "string"
-}

addedOutput schema / properties / entry / properties / items / items / properties / unknown_macros

Added value: +{
+  "description": "Macros missing from the source data: shown as 0 but unknown, not a real zero.",
+  "items": {
+    "enum": [
+      "protein_g",
+      "carb_g",
+      "fat_g"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

Addedupdate_preferences

Changedwhoami4 fields changed

addedOutput schema / properties / connected
```
Added value: +{
+  "type": "boolean"
+}
```

removedOutput schema / properties / scopes

Removed value: -{
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

removedOutput schema / properties / user_id

Removed value: -{
-  "type": "string"
-}

changedOutput schema / required

Previous value: -[
-  "user_id",
-  "scopes"
-]New value: +[
+  "connected"
+]

2 tool updatesOct 1, 2026

Changeddelete_meal1 field changed

changedInput schema / properties / id / description

Previous value: -"The entry id, as returned when reading a day."New value: +"The entry id, shown with each entry in the reply text when a meal is logged or a day or range is read."

Changedupdate_meal1 field changed

changedInput schema / properties / id / description

Previous value: -"The entry id, as returned when reading a day."New value: +"The entry id, shown with each entry in the reply text when a meal is logged or a day or range is read."

12 tool updatesSep 30, 2026

Changedadd_pantry_item1 field changed