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

Consistent with readOnlyHint=true and it adds beyond the annotation: it scopes results to 'user-visible' plans and explicitly denies side effects ('never hide, block, route, or enable other tools'), which prevents a serious misreading of a tool named like a control-plane operation. It stops short of saying what happens when no plan exists or what the returned plan contains.

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?

Two short sentences, the core behavior front-loaded in the first. The second sentence is slightly abstract ('Plan tools update plan state only' describes siblings, not this tool) but does useful boundary-setting work for a name that could be misread as a gating mechanism.

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?

With no output schema, the description never indicates the shape of the returned plan or the no-plan case, which matters for a getter. The annotations cover the safety profile and the parameter is fully documented, so the remaining gap is real but narrow.

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% and the single optional conversationId already documents that omission means 'use the current MCP conversation context' and forbids placeholders. The description adds no parameter guidance of its own, so it earns the baseline rather than more.

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 ('Returns the active ... plan') plus the scope ('for the current conversation') and restricts it to read-only, user-visible plans. It distinguishes itself conceptually from the mutating plan siblings but never names them (create_plan, complete_plan, update_plan_item), so an agent must infer the split.

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?

The phrase 'current conversation' implies when the tool applies and the read-only framing hints at a read-vs-mutate split, but there is no explicit 'use this when you need to inspect the plan' statement and no named alternative for listing or mutating plan state.

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