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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds the concrete consequences: it writes real issues, it cannot be undone, a wrong statusMap silently moves live work out of dispatch, the server refuses a missing or empty map, and access is owner/admin only. It also documents the billing refusal path (BILLING_INACTIVE / MONTHLY_CAP_REACHED) and the `tellHuman` relay contract, none of which is recoverable from structured fields.

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?

Front-loaded with purpose and the irreversibility warning, and essentially every clause carries operational consequence. It is a single dense block of run-on sentences, though; the destination and statusMap rules would land faster as discrete lines given the volume of high-stakes instruction.

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?

Covers prerequisites, irreversible effects, permission requirements, and the failure/escalation path — strong for a 6-parameter destructive tool with no output schema. The one gap is the success path: it never says what a completed call yields or references latest_import / list_import_statuses for tracking the import.

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 bar is baseline 3, but the description meaningfully deepens `destination` (which value produces a project invisible from this context) and `statusMap` (maps EVERY source column id, must be the human's actual answer, refused if empty, silent dispatch breakage if wrong). `reviewerByStatus` is tied to the review-mapped columns, giving an agent the conditional relationship the schema alone doesn't state.

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 ('bring a backlog across') and enumerates the exact source systems Linear, Jira, Asana, ClickUp, Shortcut. That separates it cleanly from the surrounding import siblings (list_import_sources, list_import_targets, import_history, latest_import), which are discovery/polling calls rather than the mutation itself.

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?

Explicit gating: confirm with your human first, relay the re-import warning if import_history showed this source before, offer `this_project` first when the bound project is empty versus both options when it already has work. It also names the condition under which a refusal should escalate rather than be absorbed, which is the kind of when/when-not guidance most definitions omit.

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