Bryti

Note a like or dislike

add_food_preference

Record that the household, or one member, likes or dislikes an ingredient, a dish, a category, a texture or a way of cooking. Allergies and intolerances are not likes: Bryti keeps them in the app.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "subjectType": "<subjectType>",
      "subject": "<subject>",
      "sentiment": "<sentiment>"
    },
    "name": "add_food_preference"
  }
}

Input Schema

Name	Required	Description
`subject`	Yes	The food, ingredient, or dish. For subjectType Taste prefer the canonical lowercase English keys: sweet, salty, sour, bitter, umami, spicy, rich, fresh.
`sentiment`	Yes	How strongly they feel.
`memberName`	No	Member the preference belongs to; omit for the whole household.
`subjectType`	Yes	What the subject refers to.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare this is a non-destructive, non-idempotent write with no open-world access, so the safety profile is covered. The description adds the domain boundary that allergies live outside this data, which prevents misuse. It does not address the non-idempotent flag — whether repeating a call creates a duplicate or overwrites — which is the main behavioral question an agent would have.

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?

Two sentences, front-loaded with the action and object, with no filler. The second sentence is valuable but its phrase "keeps them in the app" is slightly nebulous where a tool name would be sharper.

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 simple four-parameter additive note tool with a fully documented schema and no output schema, the description covers the essential framing: what counts as a preference, household vs. individual scope, and the allergy boundary. The only meaningful omission is duplicate/overwrite behavior on repeat calls.

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%, including enum docs and the canonical Taste keys, so the baseline is 3. The description does add scope meaning for memberName by saying the preference can belong to "the household, or one member", clarifying that omitting it means household-wide, but it adds nothing beyond that.

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 ("Record") and a precise resource ("a like or dislike") and enumerates the valid subject kinds (ingredient, dish, category, texture, way of cooking), which matches the subjectType enum. It never names the related sibling (delete_food_preference) to say what it is *not*, so differentiation is only partial.

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?

Provides one real exclusion — allergies and intolerances are not likes — which is genuinely useful negative guidance. But the redirect is vague ("Bryti keeps them in the app") with no tool named, and there is no guidance on removing a preference (delete_food_preference) or on what happens if the same preference is recorded twice.

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

All Bryti tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?