send_draft

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

Beyond the destructiveHint annotation, the description discloses that sending marks the draft as sent but does not delete it, that it refuses to send when a scheduled send is pending to avoid duplicate delivery, and that it requires PROTONMAIL_ALLOW_SEND. This gives the agent a realistic model of side effects and failure conditions.

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 front-loaded with the core action and workflow placement, then adds only high-value behavioral and prerequisite details. Every sentence earns its place, including the rationale for refusing on pending scheduled sends, which prevents an agent from making a duplicate-delivery mistake.

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 destructive send operation with three parameters and no output schema, the description covers purpose, workflow context, side effects, prerequisites, and a critical conflict case. Combined with the fully documented input schema, an agent has what it needs to invoke this tool correctly.

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%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that draftId refers to a local draft (as opposed to remote drafts in sibling tools) and by explaining the high-level workflow role of the draft. It does not need to restate dryRun/confirmed since those are already well documented in the schema.

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 opens with a specific verb and resource: 'Send a previously saved local draft through Proton Bridge SMTP.' It clearly distinguishes this from related sending tools by scoping it to local drafts and a draft-review-send workflow, and the sibling list makes that differentiation useful.

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 explicitly says when to use this tool: 'Use as the final step in a draft-review-send workflow after create_draft and optional update_draft.' It also gives an exclusion condition by refusing when a pending scheduled send exists and tells the agent to cancel that first, which is actionable routing guidance.

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