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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuine value by disclosing what the operation will NOT do (no replies, notifications, or agent runs), but it never explains what pause/rescan does to already-migrated data, nor why a version check is enforced. The closing line 'Names/email never verify an account' is opaque and doesn't resolve into actionable behavior.

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 action list is front-loaded and the two scope sentences are compact, so there is little padding. However, the final sentence ('Names/email never verify an account') is ambiguous enough that it consumes space without conveying a usable rule, and space spent there would have been better used on keep_sync or expected_version.

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?

This is a destructive, non-idempotent mutation with five required parameters, no output schema, and near-zero schema documentation. Given that complexity, the description should cover the optimistic-concurrency contract for expected_version, the effect of keep_sync, and the consequences of pause/rescan — none of which appear, leaving an agent under-informed before an irreversible operation.

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 only 14% — only idempotency_key is documented in the schema. The description gestures at expected_version ('with its current version') and keep_sync ('optional incremental sync') but explains neither: no statement that a stale expected_version causes rejection, no statement of what keep_sync toggles on/off. company, environment and import are entirely undocumented anywhere.

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 names the exact actions (start, pause, resume, rescan) on an Intercom migration at its current version, which is far more specific than the title alone and clearly separates it from summer_imports_intercom_preview / _list / _profiles. It stops short of a 5 because the scope of a 'rescan' versus an 'optional incremental sync' is not disentangled.

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?

'Optional incremental sync reconciles the same original IDs' and the exclusions ('no replies, notifications or agent runs') hint at when the incremental path is appropriate, but usage is only implied. Nothing tells the agent when to choose this control tool over summer_imports_intercom_preview, or what prerequisite state (e.g. preview completed) must hold before start/pause/resume.

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