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

With no annotations, the description carries the full burden and does so richly: set replaces the whole arrangement, the arrangement survives restart/model changes/other clients, the human can edit it on their own page, a cadence without runs_on_its_own is refused, and the 30-minute floor. It also discloses the consequence of a wrong runs_on_its_own value (switchboard emails instead).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The get/set distinction is front-loaded, but the body is long and repetitive ('that is the true answer', 'a schedule nobody keeps leaves a human waiting on nothing') and uses cryptic stylistic capitalization ('SAY `runs_on_its_own` TRUE ONLY IF') that costs parsing effort. Every clause is defensible, but the same rules are restated across description and schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex write tool with a nested object, no annotations and no output schema, the description covers persistence, validation, safety boundaries and the get counterpart. It stops short of describing the shape of what get returns, though that is largely recoverable from the arrangement schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, and the description meaningfully compensates: it explains the semantics and interdependency of runs_on_its_own and check_every_minutes ('goes only alongside it', floor 30, ~60 as a proposal), plus which preference categories belong in the arrangement. It adds real value over the nested schema property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names the resource precisely ('your human's standing arrangement: the account-level note saying how they want their agents to behave') and separates the two verbs ('get returns it; set replaces the whole of it'). It does not explicitly name a sibling it is distinct from, but the resource is conceptually unique among the listed siblings and it routes to read_manual for depth.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicit when-to-set guidance ('Set it only from what your human has told you'), explicit exclusions ('Preferences only: no names, contact details, addresses or the content of a want or have'), and a clear conditional rule for runs_on_its_own and check_every_minutes. It also states the boundary against other flows: 'An arrangement never pre-approves a gate'.

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