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

With no annotations provided, the description carries the full burden. It discloses that the tool 'DIRECTS your research process — it never does the work for you,' reviews each stage, approves or returns for fixes, and controls what gets published. It also clarifies it is not a literature-search tool. This is strong transparency, though it does not fully explain the stateful run mechanism or exact side effects beyond publication control.

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 description is front-loaded with 'START HERE' and is structured with parenthetical clarifications. It is longer than typical but every sentence contributes to explaining the tool's purpose and boundaries. It avoids fluff and is logically organized, earning a high but not perfect score given its length.

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, multi-mode workflow tool, the description explains the overall process, its role in research, and its constraints. The schema provides detailed parameter specifications, and the description covers behavioral expectations. It does not explicitly describe the output format, but that is not required given the absence of an output schema. Overall, it is sufficiently complete for an agent to understand how to invoke it correctly.

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?

The schema description covers 100% of the parameters with detailed explanations of run_id and payload modes (diagnose, checkpoint, ask) and their fields. The description itself adds context about the workflow (e.g., stage-by-stage, review process) that indirectly relates to the payload, but it does not add direct parameter-level meaning beyond what the schema already provides. Baseline 3 is appropriate given the high schema coverage.

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 clearly states a specific purpose: guiding the research process with a step-by-step scientific method, including diagnosing research type, providing methods, reviewing submissions, and controlling publication. It explicitly distinguishes itself from literature-search tools and from other methodist_* siblings by positioning itself as the meta-workflow entry point ('START HERE').

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 guidance: 'START HERE with your research question' indicates when to use it, and it explicitly states 'It is NOT the tool for finding methods described in existing papers — for that, use the literature-search tools.' This directly routes the agent to the correct alternative, satisfying the when-not-to-use and alternatives criteria.

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