Bryti

Change household settings

update_household_settings

Idempotent

Change the household's name, time zone, usual dinner time, address (which decides the stores nearby) or how the week is planned. Only the fields given change. One evening's dinner time is set_dinner_time.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_household_settings"
  }
}

Input Schema

Name	Required	Description
`name`	No	New household name, if changing.
`address`	No	New address, if changing; empty string clears it.
`timeZoneId`	No	IANA time zone id, e.g. 'Europe/Oslo', if changing. Only when the user says where they are or asks to change the zone — never guessed from the language they write in.
`pantryWeight`	No	How much the week leans on what the household already has at home. Usual: what they like and their favourites go first, the pantry breaks ties. Prefer («bruk gjerne det vi har»): a dish that uses what they have goes ahead of one they like a little better. UseUpFirst («bruk opp det vi har først»): the pantry goes before everything else — fewer purchases, less variety. Food about to go out of date is always used first, whatever the rung.
`alwaysNewDishes`	No	true makes that number a target instead of a ceiling: exactly that many new dishes every planned week, on the days the cookbook has least to offer. false only invents when the cookbook falls short.
`defaultDinnerTime`	No	New default dinner time as HH:mm, if changing.
`maxNewDishesPerWeek`	No	0–7: how many of the week's dinners Bryti may invent. The rest are taken from the household's own recipes and the built-in library. 0 = only dishes they already know.
`prefersLeftoverDinners`	No	true plans a leftovers evening roughly every third day, eating what the two days before cooked; false plans cooking every day.
`lunchboxWeekdayPortions`	No	0–6: how many extra portions the dinner the night before a weekday cooks for tomorrow's lunchboxes. 0 = none. One dinner's own number is set on its day card.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

addedInput schema / properties / lunchboxWeekdayPortions

Added value: +{
+  "description": "0–6: how many extra portions the dinner the night before a weekday cooks for tomorrow's lunchboxes. 0 = none. One dinner's own number is set on its day card.",
+  "type": "integer"
+}

First observedNov 7, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare that this is a non-read-only, idempotent, non-destructive mutation. The description adds useful behavioral context beyond that: changes are partial, and address changes affect nearby store selection. It does not mention persistence or permission requirements, but the core mutation semantics are clear.

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 two tight sentences, front-loads the changeable settings, and ends with a precise sibling exclusion. No sentence is wasted.

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 nine-parameter but zero-required settings update, the description plus rich schema descriptions give enough to call it correctly. It covers partial-update semantics and the main sibling distinction; the lack of output schema does not leave an important 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%, so the schema already carries most parameter meaning. The description adds only a little beyond it, notably that address determines nearby stores and that unspecified fields remain unchanged; that is useful but does not substantially re-explain the nine parameters.

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 uses a specific verb and resource, names the settings that can change, and explicitly distinguishes this from set_dinner_time for a single evening. An agent can identify the tool's scope 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?

It clearly explains the partial-update behavior ('Only the fields given change') and routes one-evening dinner-time changes to the sibling tool. It does not explicitly state when to prefer this over other household-setting siblings such as set_household_language, though the name and scope make that largely inferable.

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?