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

Annotations already declare readOnlyHint=false and idempotentHint=true, but the description adds genuinely useful state semantics beyond them: the object lands in an unpublished draft state and is inert until publishIcp runs. The retry sentence mostly restates the idempotentHint plus the idempotencyKey schema description, so it earns less credit, and nothing is said about what a rejected/invalid definition does.

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?

Three short sentences, front-loaded with the core action and scope, with no filler. The idempotency sentence is the weakest since it partly duplicates the idempotencyKey schema description, but overall the text is tight.

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?

The draft-vs-published lifecycle and idempotency contract are covered, which is the critical behavior for a create tool. What is missing is material given the absence of an output schema and the very large undocumented nested body: the description never says what is returned (id? full ICP? validation errors?) or how definition content is validated, leaving the agent under-informed for a high-complexity payload.

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?

With only 50% schema coverage, the description must carry the undocumented body, and it does not. It mentions company fit and buyer groups, but ignores the deeply nested required blocks (geographies, industries, company_sizes, attributes, location_selection, schema_version const 2, contact_methods) whose semantics — allowed value vocabulary, why buyer_groups caps at 12, what schema_version 2 means — are nowhere explained.

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 ("Creates a new ICP") and scopes the input to "targeting only (company fit and buyer groups)", which is more precise than the title. However, the sibling set contains createIcpDraft, createManualIcp, and createIcpFromScan, and the description never says which of these this one is and is not — an agent still has to guess.

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 lifecycle statement ("saved as an unpublished draft until publishIcp publishes it") names a follow-up sibling and implies this is the first step in a create-then-publish workflow. It gives no guidance on when to pick this over createIcpDraft, createManualIcp, or createIcpFromScan, so the selection decision is only implied.

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