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

Annotations already declare a non-read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds real behavioral context beyond that: the tool performs column checking, may return status needs_review instead of importing, and requires reusing the same idempotency_key on retries. Return payload shape is only partially described (one status value), which keeps it from a 5.

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 core action and prerequisite are front-loaded in the first clause, and the retry rule is placed last where it belongs. The middle clause ('as Start in the import drawer does: Sergio checks its columns') is a bit dense and mixes UI analogy with agent behavior, costing a small amount of clarity.

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 no output schema and only two parameters, the description covers the essentials: prerequisite, the two possible outcomes (imported vs. needs_review), and retry semantics. What's missing is minor, such as what a successful import returns or how long a needs_review job persists before it can still be started.

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 50%: idempotency_key is fully documented in the schema, while jobId has only a UUID format and no explanation. The description partially compensates by linking the id to something produced by upload_spreadsheet, but it never says explicitly that jobId is the upload job identifier returned by that call.

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 states a specific verb and resource ('Starts the import of a spreadsheet') and pins the scope to a spreadsheet already uploaded via upload_spreadsheet. It also distinguishes itself from review_import_mapping by describing the branch where review is needed, so an agent can tell the three import tools apart without opening schemas.

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 prerequisite is explicit: the spreadsheet must first be uploaded with upload_spreadsheet. It also names the downstream alternative (review_import_mapping) for the uncertain-mapping case, though it doesn't state exclusions such as when not to call it (e.g., already-imported or cancelled jobs via cancel_import).

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