Parameter study progress and results

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without the description. The description adds the study state vocabulary (running, done, cancelled, failed) and the per-run field set, but this is largely restatement of return shape that the output schema already carries. With annotations doing the safety work, a 3 is appropriate.

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 dense sentence that front-loads the study state and then enumerates the finish-run fields with no filler. It is appropriately sized for the tool's scope, though the list of return fields is somewhat packed.

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?

Because an output schema exists, the description needn't explain return values, yet the surrounding context (read-only annotations, single optional param, output schema) is well covered. The primary gap is the absence of when-to-use guidance relative to sibling status/results tools, which keeps it from a 5.

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?

With a single optional parameter at 100% schema description coverage, the schema fully documents the 'study' argument and its default. The description never mentions the parameter, so it adds no meaning beyond the schema. This is the baseline 3 case where the schema does all the work.

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 names a concrete resource (a parameter study) and enumerates exactly what state and data are surfaced: overall state, the in-progress run, and one row per finished run. It clearly distinguishes this read of study status from siblings like cm_study_start, cm_study_cancel, and cm_results_list. It stops short of explicitly naming those siblings, so it is clear but not sibling-routed.

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?

There is no explicit statement of when to use this tool versus alternatives such as cm_status, cm_results_list, or cm_results_summary, and no prerequisites or exclusions are given. Usage can only be inferred from the tool name and the return contents. No conditional routing guidance is present.

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