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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower, and the description still adds real behavior beyond them. Two non-obvious traits are disclosed: omitted fields are left unchanged, and an empty list actively clears that list rather than being a no-op. It also reveals a side effect absent from annotations — any edit flags the profile as human-authored. It does not state permission requirements or whether the cleared data is recoverable.

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?

A single sentence with three clauses, each carrying distinct information: partial-edit scope, empty-list clearing, and the human-authored side effect. Nothing is repeated from the schema or annotations, and the most decision-relevant fact (partial edit) is front-loaded.

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 nine parameters at full schema coverage, annotations present, and no output schema, the description supplies what the structured fields cannot: mutation semantics and a side effect. It is nearly complete, though an agent would still benefit from knowing error behavior for a nonexistent ID and whether the updated profile is returned.

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 100%, so every parameter is already documented with examples, which sets the baseline at 3. The description adds one genuinely new parameter-level rule the schema does not state — that an empty array clears the corresponding list — but it does not explain interactions between fields or constraints on the ID beyond what the schema gives.

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: "Applies a partial edit to an Ideal Customer Profile." It also pins down the edit semantics (PATCH-style, omitted fields preserved), which distinguishes it from create_icp/delete_icp without naming them. It stops short of explicitly contrasting with siblings like create_icp or set_primary_icp, so it is clear but not fully differentiated.

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 partial-edit semantics imply when this tool is appropriate (modifying an existing ICP by ID) versus creating one, but there is no explicit when-to-use or when-not-to-use guidance. No prerequisites, no mention of what to do if the ID is unknown, and no routing to alternatives such as get_icp for inspection first.

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