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

Annotations already establish this as a write/destructive/call-once operation, and the description adds meaningful behavioral context beyond that: only specified fields are modified, all other data is preserved, and nested agentProfile updates merge. The write-tier approval note also informs the agent about possible first-use friction and the expected flow, which is useful beyond the annotations.

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 front-loaded with the core purpose, followed by a high-value naming caveat, routing prerequisite, and approval guidance. Each section earns its place, though the write-tier approval block is a little verbose. It remains well structured and scannable.

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?

For a mutating tool with a nested updates object and no output schema, the description covers all needed invocation context: prerequisites, exact id source, partial-update semantics, special-field constraints, validation rules, and approval expectations. Nothing necessary for correct selection and invocation is missing.

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 coverage is 100%, so the baseline is 3. The description adds extra parameter semantics by clarifying publicName as the public-facing label, warning against using the internal persona name/codename, and explaining how icp_id should come from get_icps. It also enriches the updates object with merge and validation behavior, going beyond the raw schema.

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 opens with a specific verb and resource: 'Update specific fields of a saved Ideal Customer Profile (ICP).' It also clarifies partial-update semantics and the publicName distinction, which separates this from create_icp and delete_icp. An agent can tell exactly what this tool does without inspecting 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?

The description gives explicit routing guidance: 'Call get_icps first — use its exact "id" value as icp_id.' It also implies the alternative by saying 'saved ICP,' so the agent knows this is for modifying an existing profile rather than creating one. It does not explicitly name create_icp/delete_icp as exclusions, but the context is clear.

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