imap_verify_account

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. It mentions verification but does not state whether this performs network calls, requires authentication, or has side effects. It also doesn't describe the output format (despite an output schema existing, the description could clarify typical outcomes like success/failure or connection details). This is inadequate for a tool with potentially significant network behavior.

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 a single short sentence, which is concise)Skip. However, it is under-specified; it does not front-load critical details like the requirement of an account_id or the fact that it checks connectivity. Every word is used, but the sentence is too terse to be truly helpful.

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?

Despite having an output schema (which mitigates return-value explanation), the description is incomplete for a tool checking connectivity and capabilities. It should mention that it verifies network access, authentication, and likely returns a report of capabilities. With no annotations and minimal description, an agent lacks essential context to use this tool effectively.

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?

The schema description coverage is 100% for the single parameter (account_id), and the description provided in the schema is complete. However, the tool description itself adds no additional meaning beyond the schema. Since coverage is 100%, a baseline of 3 is appropriate.

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 'Verify account connectivity and capabilities' states a clear verb and resource, but it is too generic and does not distinguish this tool from its siblings like imap_list_accounts or smtp_verify_account. The purpose is understandable but lacks specificity about what exactly is verified (e.g., IMAP server reachable, authentication works) and does not convey the scope of 'capabilities'.

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?

There is no guidance on when to use this tool versus alternatives. With siblings like imap_list_accounts (listing accounts) and smtp_verify_account (similar verification but for SMTP), the description gives no context about choosing between them. An agent would have to infer that this is for IMAP-specific verification, but no exclusions or alternative mentions are provided.

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