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

Annotations declare a non-read-only, non-idempotent, non-destructive mutation. The description adds real value beyond that: "GM only" discloses an authorization requirement, "Moving the day takes its notes with it" discloses a cascading side effect that the annotations do not express, and "Returns: The session" states the effect payload even though there is no output schema. The one gap is that it does not say what happens to the title or date when that parameter is omitted, nor whether the date move is reversible.

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?

Four short sentences, each earning its place: operation, side effect, permission, return value. The primary behavior is front-loaded, and nothing is padded or repeated.

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 three-parameter mutation with no output schema and no nested objects, the description covers the essentials: what changes, the cascading effect of the date change, who may call it, and what is returned. Annotations supply the safety profile, and the schema supplies the parameter details, so there is no meaningful gap left by the description.

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 100%, and the schema itself explains date ("The new play date"), title ("The new title") and campaign (slug or id), so the baseline is 3. The description adds only the note-carrying consequence of changing the date, which is useful semantic context. It does not clarify optionality, that title is nullable, or that both required parameters must always be supplied even for a pure rename.

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?

The description names a specific verb (change) and resource (a session) plus the two mutable fields: title and date. That distinguishes it from create_session and from the note-specific sibling update_session_note. It stops short of naming an alternative explicitly, so it is clear but not sibling-differentiated at the top.

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?

"GM only" is a useful authorization prerequisite that eliminates a large class of callers. Beyond that, there is no guidance on when to use this tool rather than update_session_note, for notes, or get_session, to inspect the session first. The guidance is implied rather than stated, so the tool meets the minimum viable bar, not more.

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