Send an existing draft email by ID. Requires recipients and a from address. After sending, the email moves to Sent and the draft is removed.
Send an existing draft email. The draft must have recipients (to/cc/bcc) and a from address. After sending, the email is moved to the Sent folder and the draft keyword is removed.
| Name | Required | Description | Default |
|---|---|---|---|
| emailId | Yes | The ID of the draft email to send |
Changes observed during successful MCP inspections.
v1.8.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that after sending, the email is moved to Sent folder and draft keyword removed. This covers the key behavioral effects, though error handling is not mentioned.
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?
Two sentences with no wasted words. Front-loaded with the core action, then conditions and aftermath. Efficient and clear.
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 simple tool with one parameter and no output schema, the description covers purpose, prerequisites, and outcome. No gaps remain.
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?
Only one parameter with 100% schema coverage. The description does not add meaning beyond the schema, but the prerequisite conditions indirectly clarify the parameter's context. Baseline 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 clearly states the verb 'Send' and resource 'existing draft email', distinguishing it from siblings like 'create_draft' and 'send_email'. It also specifies prerequisites (recipients and from address).
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 provides explicit prerequisites (draft must have recipients and from address), guiding when to use. It does not explicitly name alternatives, but the context from sibling tools implies when not to use (e.g., use 'send_email' for non-drafts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.