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

Beyond the annotations (readOnlyHint false, destructive false, idempotent false, openWorld false), the description discloses real runtime behavior: normalization and deduplication, skipping unreachable/duplicate rows, enforcement of the plan cap, and the requirement of a connected account. That is meaningful context the annotations cannot provide. It still does not say whether existing list members are preserved or replaced on import, or what a partial failure looks like.

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?

It is a single tight paragraph where every clause adds information: input mode, list creation, normalization, dedupe, plan cap, and auth requirement. No filler sentences. The dash-delimited style is slightly dense but readable, and the core purpose is front-loaded.

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 mutation tool with no output schema and four parameters, the description covers the input contract and side effects well. What is missing is outcome information the agent needs to plan a call: what the response reports (imported vs skipped counts, errors), and how this tool relates to the confirm_contact_import and inspect_contact_import siblings in what appears to be a multi-step import flow.

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 0%, so the description has to carry the semantics, and it largely does: list_name is auto-created if missing, contacts entries are shaped as {name,email,phone}, and csv is raw text whose header row is auto-mapped. The community_id parameter is never mentioned, and size/count limits from the schema are not restated, so the coverage is good but not complete.

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 gives a specific verb and resource: 'Import contacts into one of your distribution lists (your network)'. It clarifies that the list is created if new and what the payload looks like. It does not explicitly name siblings such as import_guest_list or save_people_as_list, so it is clear on its own but not sharply differentiated from the other import/list-building tools.

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?

It provides guidance within the tool ('give a list_name plus a contacts array and/or raw csv text'), which helps the agent choose between the two input modes. It does not say when to prefer this tool over save_people_as_list or import_guest_list, nor whether there is a follow-up confirm_contact_import / inspect_contact_import step. Usage is implied rather than stated.

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