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

Goes well past the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false): it discloses that the message is never auto-sent, that the leader opens/checks/sends it, that a card appears in their Stream, that sent messages are labelled 'via' the app and logged in that chat's Min AI. That is exactly the kind of delivery/authorization behavior an agent needs and annotations cannot convey.

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?

Purpose is front-loaded and every sentence carries routing or policy information, so length is justified for a tool with this much branching behavior. Prose is dense and jargon-heavy ('the spheres', 'Utskick', 'Min AI') with layered em-dash clauses that slightly impede scanning.

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?

Output schema exists, so return values need no explanation, and the description fully covers the decision space: target routing, draft-vs-send semantics, who sends, labelling, logging, and content restrictions. An agent has everything needed to invoke it correctly.

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 description coverage is 100%, so the baseline is 3; however, the description adds a constraint not present in the schema — the text must never contain ID numbers, passwords, bank or health details — plus the 'in the person's voice' framing and the parents-only scope of the mode behavior.

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?

States a specific verb and resource — write to a group the person leads — and enumerates the three target variants (team, parents, both). It explicitly differentiates itself from send_to_conversation by describing how the parents-only path behaves 'like send_to_conversation' while the team/both paths always create an Utskick draft.

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?

Explains the selection conditions well: which target routes to a draft in the Utskick list versus which routes into the chat, and that the mode parameter only applies to the parents path. It does not frame these as explicit 'use this instead of X when Y' exclusions, but the routing context is clear enough for selection.

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