Create Python metric draft

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description adds a genuinely non-obvious behavioral trait: drafts are immutable, and any source or I/O change requires a brand-new draft and new previews — that materially changes how an agent should plan edits.

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?

Three short sentences with the core action and the immutability constraint front-loaded; no filler. The last sentence is slightly compressed to the point of ambiguity about whether it is an instruction or a statement of fact.

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 an 8-parameter mutation tool with a nested requirements object, 0% schema coverage and no output schema, the description leaves too much unexplained — particularly target_metric_id/target_version_id, which appear to drive draft linkage, and what the call returns. It covers lifecycle semantics well but not the call surface.

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 0% across 8 parameters, so the description carries the full burden and does not meet it. It hints obliquely at 'source' and 'input/output' but never explains output_type's number/boolean enum, the nested requirements object, or what target_metric_id / target_version_id are for.

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 ('Create an immutable Python metric draft') and names the immutability property up front. It does not explicitly differentiate itself from the closely related create_python_metric_preview or publish_python_metric_draft siblings, so the reader has to infer the boundary from the sequencing sentence.

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?

'Source or input/output changes require a new draft and new previews' and 'Create an asynchronous preview ... before publishing' imply the create → preview → publish workflow, which is useful routing. However, it never states when NOT to use this tool (e.g. editing an existing draft) and never names the sibling tools to call next, leaving the agent to infer them from the sibling list.

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