import_accounts

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

With no annotations, the description carries the full burden and does contribute: required credentials, the all-or-nothing coupling of the three mail fields, the legacy per-account sender path, and the 'never echo secrets' safety rule. But it is silent on the most consequential behavior — what `replace` does to existing stored accounts, whether the import merges or overwrites, and whether the operation is reversible. For a mutation tool with zero annotation coverage that is a material omission.

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-loads the required fields and uses labeled groupings ('Required:', 'Optional TOGETHER:'), which aids scanning. But the sentence 'Without a shared sender that binding awaits setup' is ambiguous about whether that is a soft deferral or an error, and the closing instruction about asking the user mixes agent workflow policy into a tool definition rather than describing the tool.

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?

An output schema exists, so return values need not be explained, and the description does a good job on the per-record fields and mail configuration. Given that this is a bulk mutation with no annotations and a fully undocumented schema, the omission of `replace` semantics (overwrite vs merge, effect on existing accounts) leaves the definition short of what an agent needs to invoke it safely.

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% and the accounts array is free-form (additionalProperties: string), so the description's enumeration of account_id, username, password, smtp_email, smtp_auth_code, notify_email is genuinely load-bearing and compensates for the opaque item schema. The second parameter, `replace`, is never mentioned at all, leaving the top-level boolean entirely undefined.

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+resource: import learning accounts into memory, plus a qualifier about optional per-account SMTP notices. An agent can tell it is a bulk-load operation rather than a login or update. It never differentiates itself from near-siblings like setup_learning_accounts, login_accounts, or add_parallel_learning_accounts, which is the missing step for a 5.

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?

Gives real conditional guidance inside the mail sub-problem: 'Prefer configure_smtp_sender ONCE, then each record supplies only notify_email' and 'Omit all mail fields to skip email', which explicitly names an alternative tool and its selection condition. However, there is no guidance on when to choose import_accounts over the sibling setup/login/credential tools, so the core routing question is left implicit.

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