Skip to main content
Glama
Sign In

Vitalli

by app.vitalli.mcp
OverviewDiscussionsAdmin

joiva_add_food_rule

DestructiveIdempotent

Record a food rule for the user ('Bananen soll ich laut Bericht meiden'), e.g. when transferring a list from a report or from a doctor. Stores the user's statement; Joiva adds no foods and establishes no tolerances on its own. An existing rule for the same food is replaced (one rule per food).

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": {
      "kind": "<kind>",
      "label": "<label>"
    },
    "name": "joiva_add_food_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesThe user's stance: 'avoid', 'caution' (small amounts), 'prefer' (explicitly fine, e.g. a report says 'avoid oranges, lemons are okay')
noteNoThe reason in the user's own words
labelYesThe food as the user names it, e.g. 'Bananen'
reasonNoReason category as it follows from what the user said; omitted when unclear.
sourceNoWhere the rule comes from, e.g. 'Viome-Bericht 08/2026'
aliasesNoFurther spellings the rule matches. Matters for short names: 'Pute' alone matches only that word; the alias 'Puten' also catches Putenbrust.
excludesNoNames not meant despite similarity, e.g. 'Kokosnuss' under a nut rule, as stated by the user.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Adds real substance beyond the annotations: it discloses that an existing rule for the same food is overwritten (one rule per food), which explains the destructiveHint=true and idempotentHint=true flags. It also sets expectations that no domain inference happens. It stops short of saying whether the whole record (note, source, aliases, reason) is replaced wholesale on overwrite, which is the key destructive detail.

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?

Three short sentences, front-loaded with the action and an example, followed by the scope limitation and the overwrite rule. Nothing is padded and each sentence contributes a distinct fact.

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 7-parameter write tool with full schema coverage and annotations present, the description covers scope, overwrite semantics and the no-inference guarantee. The only gap is that, with no output schema, it does not indicate what is returned (e.g. the stored rule or its identifier) after a successful write.

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 includes rich per-field guidance plus enums, so the schema already does the heavy lifting. The description's only added semantic is the quoted 'Bananen soll ich laut Bericht meiden' example, which illustrates label/note/reason usage but adds little beyond the field descriptions.

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 ('Record a food rule for the user') with a concrete example of the input, so the agent knows exactly what gets written. It clearly separates this from data-adding siblings by stating 'Joiva adds no foods and establishes no tolerances on its own', but it never names joiva_update_food_rule, which is the closest sibling and whose boundary is blurry given the 'existing rule is replaced' note.

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 a clear triggering context ('when transferring a list from a report or from a doctor') that maps directly to the tool's purpose. It does not state when not to use it, e.g. that modifying a single field of an existing rule should go through joiva_update_food_rule rather than re-adding the rule.

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

All Vitalli toolsInspect
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