Run specific or mixed traditional methods

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is well covered outside the description. The description adds the useful behavioral note that the server can plan from the question when requestedCapabilities is empty, but it does not disclose other non-obvious behavior such as return shape or expert-mode composition, which are left to the output schema.

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?

The opening sentence is action-oriented and the long list of named traditions genuinely supports the tool's purpose. The description is dense and would be clearer with short groupings or bullets, but every sentence earns its place and the critical usage conditions are front-loaded.

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 complex 22-parameter tool, the description is unusually complete: it gives the capability scope, the trigger conditions, the difference from focused tools, and the two valid invocation styles. The output schema fills most remaining return-semantics gaps, and the required question parameter is minimal enough to call the tool safely.

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 only 45%, so the description must compensate for parameter meaning, but it fully explains only requestedCapabilities and vaguely references the question. It clarifies that capability IDs are optional and the server can infer from the question, which is useful given the 22 optional parameters, but most parameters still rely on their own schema descriptions.

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 explicitly states 'Use this for expert, mixed-system, or named-method requests' and then enumerates the exact traditions covered, from Myeongri and Zi Wei to Qimen and dream traditions. It clearly identifies a concrete scope and distinguishes this broad tool from the focused sibling tools.

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?

It gives explicit trigger conditions ('expert, mixed-system, or named-method requests'), explains the capability-ID path versus letting the server plan from the question, and says to use focused tools for ordinary single-goal requests. It does not name the focused sibling tools explicitly, which would make the routing guidance fully explicit.

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