Cooper Email

Send email

cooper_send_message

Destructive

Use this when the user asks the agent to send an email from its Cooper address. Requires auth. Delivers real email on the public Internet and stores a copy. Inputs: inbox_id (required; inbox id, username, or email), to (required; array of recipient addresses), subject (required), text and/or html body, cc, bcc, reply_to, headers, labels, in_reply_to (optional; a msg_ id threads onto that message using its Message-ID header and thread_id; any other value is sent as In-Reply-To), attachments (optional [{filename, content_base64, content_type?, content_id?}]; content_id enables inline images), client_id (optional; retrying with the same client_id returns the original message and does not send twice), idempotency_key (optional; sent as the Idempotency-Key header; 1 to 256 characters of letters, digits, and - . _ ~; the same key and the same request within 24 hours returns the original message and does not send again). When both client_id and idempotency_key are set, client_id is checked first. Returns the stored message {id, thread_id, status, from, to, subject, text, html, created_at, delivery_events, …}. A replay includes idempotent true. HTTP 402 with upgrade_url means the monthly send limit was reached. A paused inbox returns HTTP 403 inbox_paused and does not send. A suppressed address returns HTTP 403 recipient_suppressed and nothing is sent, stored, or counted. Fails with 400 invalid_idempotency_key, 409 idempotency_key_conflict, or 409 idempotency_request_in_progress. When usage is at 80 percent of a plan limit, the response includes notices: [{type: limit_warning, resource, used, limit, upgrade_url}].

Input Schema

TableJSON Schema

Name	Required	Description
`cc`	No	Cc addresses
`to`	Yes	Recipient email addresses
`bcc`	No	Bcc addresses
`html`	No	Optional HTML body
`text`	No	Plain-text body
`labels`	No	Labels stored on the message. Defaults to ["sent"].
`headers`	No	Optional extra headers. Each name maps to a string value.
`subject`	Yes	Subject line
`inbox_id`	Yes	Inbox id (inb_…), username, or full email address
`reply_to`	No	Reply-To address. Defaults to this inbox.
`client_id`	No	Optional client_id. The same value returns the original message.
`attachments`	No	Optional files, base64-encoded
`in_reply_to`	No	Thread this send under a message. A msg_ id uses that message's Message-ID header and thread_id. Any other value is copied to In-Reply-To.
`idempotency_key`	No	Optional Idempotency-Key header. 1 to 256 characters: letters, digits, and - . _ ~. The same key and request within 24 hours returns the original message.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 9, 2026

changedInput schema / properties / client_id / description

Previous value: -"Optional idempotency key; reuse it when retrying"New value: +"Optional client_id. The same value returns the original message."

addedInput schema / properties / idempotency_key

Added value: +{
+  "description": "Optional Idempotency-Key header. 1 to 256 characters: letters, digits, and - . _ ~. The same key and request within 24 hours returns the original message.",
+  "type": "string"
+}

Changed6 schema fields changedOct 8, 2026

addedInput schema / properties / bcc

Added value: +{
+  "description": "Bcc addresses",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / cc

Added value: +{
+  "description": "Cc addresses",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / headers

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "Optional extra headers. Each name maps to a string value.",
+  "type": "object"
+}

addedInput schema / properties / in_reply_to

Added value: +{
+  "description": "Thread this send under a message. A msg_ id uses that message's Message-ID header and thread_id. Any other value is copied to In-Reply-To.",
+  "type": "string"
+}

addedInput schema / properties / labels

Added value: +{
+  "description": "Labels stored on the message. Defaults to [\"sent\"].",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / reply_to

Added value: +{
+  "description": "Reply-To address. Defaults to this inbox.",
+  "type": "string"
+}

Changed7 schema fields changedSep 29, 2026
- addedInput schema / properties / attachments / description
```
Added value: +"Optional files, base64-encoded"
```
- addedInput schema / properties / client_id / description
```
Added value: +"Optional idempotency key; reuse it when retrying"
```
- addedInput schema / properties / html / description
```
Added value: +"Optional HTML body"
```
- addedInput schema / properties / inbox_id / description
```
Added value: +"Inbox id (inb_…), username, or full email address"
```
- addedInput schema / properties / subject / description
```
Added value: +"Subject line"
```
- addedInput schema / properties / text / description
```
Added value: +"Plain-text body"
```
- addedInput schema / properties / to / description
```
Added value: +"Recipient email addresses"
```
First observedSep 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes far beyond the annotations with real-world consequences: mail is actually delivered and a copy stored, plus the full failure taxonomy (402 limit reached with upgrade_url, 403 inbox_paused, 403 recipient_suppressed with nothing sent/stored/counted, 400/409 idempotency errors) and the 80%-of-limit notice. The idempotentHint=false annotation is not contradicted — client_id/idempotency_key are explicit opt-in and their precedence is documented.

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 trigger and the real-world effect, then walks inputs and errors in a predictable order with no filler sentences. The inputs/error enumeration is dense and long, but each clause carries distinct operational information for a 14-parameter tool.

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?

With no output schema, the description still supplies the return shape ({id, thread_id, status, from, to, subject, ..., delivery_events}), the replay marker (idempotent true), and the notice structure. Combined with the error codes and auth requirement, an agent has everything needed to call and interpret this correctly.

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 already 100%, but the description adds semantics the schema lacks: msg_ ids thread via Message-ID/thread_id while other values are copied verbatim to In-Reply-To, content_id enables inline images, client_id is checked before idempotency_key, and the idempotency key charset/replay window are restated usefully. Not fully additive for every field (cc/bcc/labels only echoed), so short of the top score.

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 and resource ('send an email from its Cooper address') plus the substantive consequence ('delivers real email on the public Internet and stores a copy'). This cleanly separates it from the draft-oriented siblings (cooper_create_draft, cooper_send_draft) and cooper_reply_message.

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?

'Use this when the user asks the agent to send an email from its Cooper address' gives a clear triggering condition. It does not explicitly contrast with alternatives like cooper_send_draft or cooper_reply_message, so the agent must infer the boundary from purpose alone.

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

All Cooper Email tools Inspect

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.

Send email

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources