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

The description adds behavioral context by saying it is a preview and title says 'nothing changed yet,' which goes beyond the annotations (readOnlyHint is false, destructiveHint is false). It does not contradict the annotations because readOnlyHint false does not positively assert mutation. However, it omits details like whether any side effects occur, what the preview produces, or how approval requirements are surfaced.

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 very short and front-loaded: 'Preview interview-plan publish approval requirements only' immediately states the core behavior. Every phrase earns its place, and the title adds useful context. It is terse but not wasteful.

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?

With no output schema and five parameters including nested objects, a one-line description is insufficient. It never explains what the preview returns, how 'approval requirements' are represented, or the role of optional fields like approval_id and expected_draft_version. The tool is therefore incomplete for correct invocation.

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%, and the description does not compensate. It alludes to 'bind fields are rejected' but never identifies which fields those are, and it gives no meaning for draft_id, approval_id, expected_draft_version, request_id, or idempotency_key. Agents are left without guidance on how to supply parameters correctly.

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 uses a specific verb and resource: 'Preview interview-plan publish approval requirements only.' It also distinguishes itself from the binding operation by stating 'bind fields are rejected,' and the title reinforces 'nothing changed yet.' An agent can tell this from publish_bind siblings without opening the schema.

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?

Usage is only implied: the tool is for previewing approval requirements before publishing, and 'bind fields are rejected' hints it is not for actually binding. However, it never explicitly names the alternative tool (e.g., yardstick_interview_plans_publish_bind) or states when to choose preview over bind, so guidance remains implicit.

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