import_prospects_from_csv

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it succeeds thoroughly. It exposes the one-way doNotContact ratchet, domain-only skip behavior, overwrite re-linking semantics, and the complete return payload including skippedDetails and errorDetails.

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 description is dense but every clause carries necessary information: input format, output fields, dedup policy semantics, edge cases, and limits. There is no filler or repetition of schema trivia; it is front-loaded with the core action and resource.

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 tool with no annotations and no output schema, this description is remarkably complete. It documents return fields, error/skip details, dedup edge cases, the doNotContact ratchet, and the max row count; only the exact CSV column contract is left to the 'canonical' term, which is a reasonable shared assumption.

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 67%, and the description substantially enriches the dedupPolicy parameter by explaining exactly how 'overwrite' matches prospects and why domain-only matches are skipped. It also adds the meaning of 'canonical CSV string' and the significance of omitting projectId, going well beyond the schema's enum and minLength.

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 opening clause states the operation precisely: 'Import prospects from a canonical CSV string.' It clearly distinguishes this bulk-import tool from sibling tools like add_prospects or list_tenant_prospects by focusing on CSV ingestion, dedup policy, and import results.

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 description gives strong situational context: it explains dedupPolicy behavior, tenant-only behavior when projectId is omitted, and the 1000-row limit. It does not explicitly name alternatives such as add_prospects for non-CSV or single-prospect scenarios, so exclusions are 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.