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

Annotations already provide readOnlyHint: true and idempotentHint: true. The description adds important context: 'Every call is read-only and idempotent', and details the error format ('returns {"error": ...}') and retry advice. Since annotations already handle the behavioral safety profile, the description earns a high score for supplementing with error-handling specifics without contradiction.

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 tightly written with no wasted sentences. It front-loads the core purpose in the first line, then provides example input/output, usage guidance, sibling differentiation, error handling, and behavioral notes—all in a compact, well-structured paragraph.

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 (2 parameters, clear output schema, strong annotations), the description is nearly complete. It covers purpose, usage, error behavior, and idempotency. Minor omission: it doesn't mention the output schema return shape beyond the example, but the presence of an output schema in the context signals reduces the need.

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 high (100%) for the two parameters. The description adds some semantic context beyond the schema by showing a typical input example ({"code": "<file contents>"}), but does not provide additional detail beyond what the schema describes for each parameter. Baseline 3 is appropriate as schema already handles the burden.

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 'Report structural complexity of a source file, function by function', with a specific verb ('report') and resource ('complexity of a source file'). The detail on what metrics are measured (length, nesting depth, branch count) and the flagging behavior clearly distinguishes this from siblings like 'security_deep_dive' or 'ai_code_smell_scan'.

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 explicit guidance: 'Use when structure rather than correctness is the question. Not for vulnerabilities (security_deep_dive).' It also explains error behavior and retry safety, helping the agent decide when to invoke this tool and when to choose an alternative.

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