Skip to main content
Glama

Cooper Email

by com.cooperemail
OverviewDiscussionsAdmin

Create a draft

cooper_create_draft
Destructive

Use this when you want to prepare a message without sending it yet. Requires auth and message_send or draft_write. draft_write does not send mail. Inputs: inbox_id (required; inbox id, username, or email), to, cc, bcc, reply_to, subject, text, html, attachments, labels, headers, in_reply_to or forward_of (one source message; not both), reply_all (only with in_reply_to), include_attachments (forward only; default true), send_at (optional ISO-8601 timestamp; sets the scheduled label and send_status scheduled), client_id (optional). Reply recipients and Re: come from the source message, so omit to on a reply. A forward keeps your text and merges the original body and attachments when it sends. A held source message returns HTTP 409 message_held. Returns the draft. The same client_id returns the original draft and does not create another. send_at on an inbox whose send_mode is approval emails verified owners. No verified owner returns HTTP 409 owner_required and stores nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoCc addresses. On a reply these are merged with the derived recipients.
toNoRecipient addresses. Omit on a reply. An empty list clears them on update.
bccNoBcc addresses.
htmlNoHTML body.
textNoPlain-text body.
labelsNoLabels to set. The scheduled label is reserved.
send_atNoISO-8601 time to send. Null is ignored on create. Must be within 366 days.
subjectNoSubject. A reply or forward fills this from the source message when omitted.
inbox_idYesInbox id (inb_…), username, or full email address
reply_toNoReply-To address, or a comma-separated list.
client_idNoIdempotency key. The same value returns the original draft.
reply_allNoWhen true with in_reply_to, address the whole thread. Requires in_reply_to.
forward_ofNoMessage id to forward. Mutually exclusive with in_reply_to.
attachmentsNoFiles to store on the draft. Each item is {filename, content_base64, content_type?, content_id?}.
in_reply_toNoMessage id to reply to. Mutually exclusive with forward_of.
include_attachmentsNoOn a forward, copy the original attachments when the draft sends. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true) by disclosing required auth/scopes, HTTP 409 outcomes (message_held, owner_required with 'stores nothing'), reply/forward body-merging rules, and the approval-mode emailing behavior of send_at. The client_id idempotency nuance is consistent with idempotentHint=false since idempotency is conditional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose before diving into inputs, and every clause carries operational detail. However, the 'Inputs: ...' enumeration largely restates schema fields already documented at 100% coverage, making the paragraph longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter mutation tool with no output schema, it covers auth, error codes, idempotency, reply/forward derivation, scheduling semantics, and notes the return (the draft). Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter semantics the schema does not: 'omit to on a reply' because recipients derive from the source, send_at sets the scheduled label, and a forward merges the original body/attachments. It also encodes the in_reply_to vs forward_of exclusivity and reply_all dependency.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (create draft) and resource, and immediately scopes it against the send path: 'prepare a message without sending it yet.' An agent can tell this apart from cooper_send_draft, cooper_send_message, and cooper_reply_message without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear when-to-use condition (prepare without sending) plus conditional constraints (reply_all only with in_reply_to, include_attachments forward-only, send_at schedules). It does not name alternative tools like cooper_send_message or cooper_reply_message explicitly, so it stops just short of a full when/when-not/alternative statement.

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

All Cooper Email toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources