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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the redundant "same every time" / "read-only" restatements add little. What does add value beyond the annotations is "no workspace" and "not metered" — operational facts an agent needs to know before spending a call that are nowhere in the structured metadata.

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 in the first clause, and the trailing operational constraints (read-only, no workspace, not metered) are efficiently packed. The middle em-dash enumeration is dense and jargon-heavy (SEP-2663, io.modelcontextprotocol/tasks) and slightly obscures the core message, but no sentence is wasted.

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?

An output schema exists, so return-value explanation is unnecessary, and the description correctly focuses on what the guide covers and the dual-host model. It omits any mention of the detail parameter's effect, but that gap is fully absorbed by the schema, leaving little an agent needs that is missing.

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 enum parameter (detail: summary/full) is fully documented in the schema, so the description need not restate it. The description never mentions the summary-vs-full distinction or when to prefer full, so it adds no parameter-level meaning beyond the schema — baseline 3 applies.

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 FinStat Task guide") and then enumerates the guide's contents: the MCP Tasks extension (io.modelcontextprotocol/tasks, SEP-2663), the ordinary-client parallel, and the shared submit / create_standard_statements workflow. It also distinguishes itself from the similarly named sibling tasks_get by noting the ordinary poll is FinStat's own and not part of the extension, so an agent won't confuse the two.

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 description conditions the guide's applicability on host capability ("for hosts that advertise it" vs "hosts that do not"), which tells an agent which path applies to it. It does not, however, state an explicit trigger such as "call this before using submit" or differentiate from other onboarding siblings like get_started or demo, so exclusions are only partial.

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