Analyze Task

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

With no annotations, the description carries the full disclosure burden, yet it omits the most consequential behaviors visible only in the schema: it may create an orchestrated session and reuse existing sessions by default (side effects), and it accepts an override token for "chaotic requests." Terms like "baseline audit" and "chaos detection" are never explained, so an agent cannot predict what the call changes.

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?

A single compact sentence with the core action front-loaded and no filler. The problem is that the space saved is spent on unexplained jargon rather than on useful content, but structurally it is efficient.

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?

A five-parameter tool with default-on session side effects, no annotations, and no output schema needs more than one abstract sentence. Nothing explains the return value (routing decision? complexity score? audit report?) or the session-creation side effect, leaving an agent unable to call it confidently.

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 80%, so most parameters are documented in the schema itself, which sets the baseline at 3. The description adds nothing about the five parameters — notably it never clarifies the interaction between reuse_session and create_session or what qualifies as a chaotic request needing override_token.

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 verb+resource pair ("analyze task complexity") is identifiable, but the trailing clause "route appropriately with chaos detection, baseline audit and orchestration" is internal jargon that doesn't tell an agent what the tool concretely produces or how it differs from siblings like mcp_m7_scope, mcp_m7_task_graph, or mcp_m7_validate. Readable, but too abstract to differentiate.

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?

"Route appropriately" faintly implies this is an entry point to a workflow, but the description never states when to call this instead of mcp_m7_scope or mcp_m7_task_graph, nor any prerequisites. No exclusions, no alternates, no ordering guidance.

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