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

With no annotations, the description carries the burden of behavioral disclosure. It explains the behavior of different check kinds (contains, regex, equals, etc.), how compare_to works, and when target_path is required. It also clarifies how expected values are graded. This is substantial added context, though it doesn't cover every possible side effect (e.g., return values, permissions), which would push it higher.

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 a single dense paragraph but front-loads the purpose before diving into configuration details. It is information-dense without being redundant, though bullet points or clear section breaks would improve readability. Every sentence adds value and doesn't waste words, so it earns a 4 rather than a 5.

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?

Given the tool's complexity (nested check_config, enum metric_type, no annotations, no output schema), the description is incomplete. It fully details the 'check' metric type but gives no guidance for the 'llm_judge' type, leaving rubric_bands and instruction parameters unexplained. It also omits any mention of return values or errors. For a create tool with this much complexity, a 2 is appropriate because major areas are unaddressed.

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 input schema has 0% description coverage, so the description must compensate. It thoroughly explains check_config parameters like value, pattern, min/max, json_path, compare_to, and expected_path, and distinguishes between constant and expected comparisons. However, it does not explain simpler parameters like name, tag_names, instruction, or rubric_bands, leaving some gaps, but the complex parameters are well covered.

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 'Create a metric with evaluation criteria' with specific verb and resource. It distinguishes from sibling tools like metrics_update by focusing on creation, and provides a detailed breakdown of configurable check kinds and their required keys, making its purpose unambiguous.

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?

The description gives clear guidance on when to use the tool (for creating metrics) and provides detailed configuration instructions for deterministic checks, including required keys per check kind and how to compare against expected values. However, it does not explicitly compare against alternative tools like metrics_update or mention scenarios where creation is inappropriate; the guidance is tool-internal rather than cross-tool, so it's not a full 5.

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