PlaceRoot

Persistent preferences

preferences

DestructiveIdempotent

Travel defaults.

Instructions

Travel defaults.

State "I bike everywhere, I have a dog" once. Routing tools use the
stored mode when you omit theirs; an explicit argument always wins.
pace and household are stored for later features and do not change
answers yet. lang (#410) is the stored result-language preference: the
name-lookup tools that accept their own `lang` use this one when
theirs is omitted, returning an Overture-tagged name variant (e.g.
"Munich" for "München" with lang="en") — a per-call `lang` always
wins. The same document is the placeroot://preferences resource.

Call with no arguments to read. Pass mode, pace, household tags, a
free-text note, or lang to merge those fields.
clear=true deletes the file and cannot be combined with other fields.
Nothing is sent off this machine. Over HTTP, preferences are
per-connection and not persisted (this session's values overlay the
host's file and are gone when the session ends).

Input Schema

Name	Required	Description
`lang`	No	Result-language code (2-3 lowercase letters, e.g. "de"). Overture-tagged name variants only — never transliterated or invented. Default: stored preference, else the primary name.
`mode`	No	Travel mode to store. Omit to leave it unchanged.
`note`	No
`pace`	No
`clear`	No
`household`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.0Aug 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing what clear actually does (deletes the file, cannot be combined with other fields), merge semantics, that nothing leaves the machine, and that over HTTP the store is per-connection and non-persistent. The destructiveHint=true annotation is consistent with the documented clear behavior, and the description adds the exclusivity and persistence nuance the annotation cannot express.

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?

Purpose is front-loaded and every sentence carries information, but the lang sentence is a dense run-on with an internal issue reference ('#410') that adds noise, and the parentheses stack multiple clauses. Slightly harder to parse than it needs to be.

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?

An output schema exists, so return values need no explanation, and the description still covers persistence model, HTTP session semantics, privacy, precedence rules, and the clear/merge conflict. For a 6-param stateful config tool this leaves nothing essential unstated.

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?

With schema coverage at only 33%, the description carries real weight: it explains lang precedence (per-call wins over stored), mode merge behavior, and clear's mutual exclusivity with other fields. pace/household are characterized as stored-but-inert and note as free-text, which is meaningful, though the exact accepted formats of pace and household are left implicit.

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+resource: stores travel-default preferences (mode, pace, household, lang) that other tools consume. It explicitly distinguishes its role from routing/name-lookup siblings, which read these defaults rather than write them, so an agent can place it instantly.

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?

Explicit when-to-use: call with no arguments to read, pass fields to merge, clear=true to delete. It also spells out the precedence relationship with sibling tools ('routing tools use the stored mode when you omit theirs; an explicit argument always wins'), so the agent knows exactly when this tool's values apply.

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