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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the safety bar is pre-covered. The description adds genuinely useful state semantics: the result is a DRAFT and not a commitment until approve_scope runs. That is real context beyond the annotations, though permissions and idempotency behavior are not addressed.

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?

Two tight sentences with zero waste, and the core action ('Create a draft engagement') is front-loaded before the state caveat.

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?

An output schema exists, so return values need not be explained, and the draft/approval workflow is captured. However, for a 4-parameter creation tool with 0% parameter documentation, the description leaves the inputs semantically unexplained, which is a notable gap.

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 4 parameters, and the description adds no meaning for title, summary, currency, or clientName. The schema only supplies structural constraints (required, pattern, maxLength), so the semantic burden falls entirely on the description, which does nothing here.

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 a draft engagement') and distinguishes itself from the approval sibling by framing the output as a draft, explicitly referencing approve_scope. It does not differentiate from the other creation/save siblings (save_rate, save_deadline, save_scope_item), which keeps it from a 5.

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 through the workflow note that draft terms are not an approved commitment until approve_scope, which suggests this is the first step before approval. There is no explicit when-to-use/when-not guidance and no direct comparison against the save_* or list siblings.

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