Skip to main content
Glama
Sign In

Bryti

by app.bryti
OverviewDiscussionsAdmin

Limit time at the stove

upsert_max_cooking_time_rule
Idempotent

Set the most minutes of active cooking a dinner may take, every day or on the weekdays named. One single date is set_max_cooking_time_for_date; the time until dinner is on the table, oven included, is upsert_max_total_time_rule. A rule about the same thing is changed, not added twice. Soft unless the household says it must hold.

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": {
      "minutes": "<minutes>",
      "strength": "<strength>"
    },
    "name": "upsert_max_cooking_time_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
minutesYesMaximum active minutes at the stove, 5-240.
strengthYesSoft unless the household says the rule must hold. Hard ONLY when the words are must/never/always (må/aldri/alltid/skal/kan ikke/ikke lov). Everything else is Soft — a preference the planner may bend on a tight week — including a bare statement said in passing («Taco på fredager», «Fisk to ganger i uka», «Maks 30 minutter på hverdager») and helst/gjerne/prøv. «Maks», «minst» and a number name the limit, not its strength: they do not make a rule Hard.
weekdaysNoThe weekdays the maximum holds on; omit for every day.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the 'changed, not added twice' sentence mostly restates structured data. The description adds that the rule is soft by default, but it does not describe what happens to existing conflicting rules or what the call returns.

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?

Four short sentences, front-loaded with the purpose and followed by routing and upsert behavior. The trailing 'Soft unless the household says it must hold' is slightly cryptic out of context and duplicates the strength parameter's own description.

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?

A simple three-parameter rule-setting tool with full schema coverage; the description covers scope, sibling routing, duplicate handling and the default strength. No output schema exists, but the tool's result is not something an agent needs explained to call it correctly.

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; the description earns a bump by disambiguating 'active cooking at the stove' from total time with the oven included, which is the main way minutes could be misread. It does not add numeric bounds, but those are already 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?

States a specific verb and resource ('Set the most minutes of active cooking a dinner may take') plus scope (every day or named weekdays), and explicitly separates itself from set_max_cooking_time_for_date and upsert_max_total_time_rule. An agent can pick the right tool 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 Guidelines5/5

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

Names both plausible alternatives and the condition that selects each: a single date goes to set_max_cooking_time_for_date, total time including oven goes to upsert_max_total_time_rule. It also states upsert semantics ('changed, not added twice'), removing ambiguity about creating duplicates.

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

All Bryti 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