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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description usefully reinforces this with 'Changes nothing.' It also discloses what the agent gets back — ranked methods each with steps and a console link — which annotations alone would not convey. No contradictions with the declared safety profile.

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 purpose is front-loaded, but the second sentence is a long run-on that crams parenthetical question lists and a seven-item enumeration of import paths into prose. The content is useful, yet the lack of structure (bullets or separation of the two modes) makes it harder to parse than necessary.

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 no annotations beyond safety hints, the description carries responsibility for describing results, and it does so adequately: questions in one mode, ranked import methods with steps and a console link in the other. Some uncertainty remains about result shape and ranking criteria, but an agent can call it correctly with what is given.

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% and the single optional parameter is fully documented there, so the baseline is 3. The description earns a bump by adding meaning beyond the schema: it gives concrete example source strings ('Mixpanel', 'Shopify', 'our Postgres users table', 'a Google Sheet') and states what happens when it is omitted, clarifying the accepted input granularity.

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 resource (an audience/its source) and the two modes of the tool (discovery questions vs. ranked import paths), and the closing line 'Changes nothing' signals this is advisory rather than an execution tool. However, it never explicitly contrasts itself with execution siblings like import_contacts or connect_integration, so the boundary is inferred rather than stated.

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 gives an explicit conditional: 'Without source' returns questions to ask the person, 'With source' returns concrete import paths best-first. That is clear guidance on when each mode applies. It stops short of naming alternatives (e.g., use import_contacts to actually perform the import), so the agent must infer the handoff.

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