Skip to main content
Glama

update_preferences

DestructiveIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
add_likesNoFoods the user enjoys, e.g. 'salmon'.
diet_styleNoThe user's diet style; 'none' clears it.
add_dislikesNoFoods the user dislikes, e.g. 'mushrooms'. A taste preference, not an allergy or a restriction.
remove_likesNoFoods to take off the likes list.
add_allergiesNoAllergens to add, from the major US allergen list.
user_approvedYesTrue 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_dislikesNoFoods to take off the dislikes list.
remove_allergiesNoAllergens to remove.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
likesNo
removedYes
dislikesNo
allergiesNo
not_foundYes
diet_styleNo
portion_noteNo
allergy_disclaimerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema 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."
  2. Added

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.