Cooper Email

Add an allow or block entry

cooper_create_list_entry

DestructiveIdempotent

Use this when an agent should only mail approved recipients, or should ignore unwanted senders. Requires auth. Inputs: direction (required; send, receive, or reply), type (required; allow or block), entry (required; email or domain), inbox_id (optional; omit for the account-wide list), reason (optional note). Returns the list entry. HTTP 201 when created, HTTP 200 when that entry already exists. A block match rejects the address. A non-empty allow list rejects everyone else. When an inbox has any entries for a direction, only that inbox's lists apply. Sends that hit a list return 403 recipient_blocked and are not sent, stored, or counted. Blocked inbound mail is not stored and fires message.blocked. Progress email to a verified owner is exempt. The per-inbox task allowlist is unchanged. Fails with 400 invalid_list, 400 invalid_entry, 400 list_full (1000 entries), or inbox_not_found.

Input Schema

Name	Required	Description
`type`	Yes	allow or block.
`entry`	Yes	Email address or domain to allow or block. Stored lowercase.
`reason`	No	Optional note stored with the entry.
`inbox_id`	No	Inbox id (inb_…), username, or full email. Omit for the account-wide list.
`direction`	Yes	send checks recipients. receive checks new inbound mail. reply checks mail that answers an outbound Message-ID.

Output Schema

Name	Required	Description
`type`	No	allow or block.
`entry`	No	The email address or domain on the list.
`object`	No	Object type name, such as list, message, or thread.
`reason`	No	Optional note stored with the entry.
`deleted`	No	True when the object was deleted.
`inbox_id`	No	Inbox the entry applies to, or null for the whole account.
`direction`	No	inbound or outbound.
`created_at`	No	ISO-8601 time the object was created.
`entry_type`	No	email or domain.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The list entry.",
+  "properties": {
+    "created_at": {
+      "description": "ISO-8601 time the object was created."
+    },
+    "deleted": {
+      "description": "True when the object was deleted."
+    },
+    "direction": {
+      "description": "inbound or outbound."
+    },
+    "entry": {
+      "description": "The email address or domain on the list."
+    },
+    "entry_type": {
+      "description": "email or domain."
+    },
+    "inbox_id": {
+      "description": "Inbox the entry applies to, or null for the whole account."
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    },
+    "reason": {
+      "description": "Optional note stored with the entry."
+    },
+    "type": {
+      "description": "allow or block."
+    }
+  },
+  "type": "object"
+}

AddedOct 8, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already flag destructive/idempotent, but the description adds substantial behavior: idempotency expressed as HTTP 201 vs 200, the enforcement consequences (block match rejects the address; non-empty allow list rejects everyone else), per-inbox list precedence, 403 recipient_blocked with no store or count, inbound blocks not stored plus a message.blocked event, verified-owner progress email exemption, and the 1000-entry cap. It also enumerates the failure codes (invalid_list, invalid_entry, list_full, inbox_not_found). This is far beyond what the annotations convey.

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-loaded with the use case, then inputs, then enforcement and error behavior in a logical order. It is dense and telegraphic, however, and a few sentences (the per-inbox task allowlist note, the progress-email exemption) are narrow edge cases that lengthen it without helping tool selection.

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 destructive, multi-mode list mutation with an output schema, the description covers scope, enforcement effects, idempotency, limits and error cases. An agent has everything needed to invoke it correctly and anticipate outcomes, even though return values need not be spelled out.

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

Parameters3/5

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

Schema coverage is 100% and the enum values and inbox_id/entry semantics are already documented in the schema. The description restates the three required inputs and the optional ones almost verbatim, adding only light context such as account-wide scope and the reason note. Baseline 3 applies since the schema does the heavy lifting.

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

Purpose4/5

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

The opening sentence frames the intent (only mail approved recipients / ignore unwanted senders) and the input list makes clear this creates a list entry of type allow or block. Verb is implied by the title rather than stated directly in the description, and no sibling (e.g. cooper_delete_list_entry, cooper_list_list_entries) is named to sharpen the boundary, so it is clear but not maximally differentiated.

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?

Explicit conditions are given: use when an agent should restrict outbound recipients or suppress unwanted senders, and 'omit inbox_id for the account-wide list' vs per-inbox scope. The direction semantics (send checks recipients, receive checks inbound, reply checks replies to an outbound Message-ID) directly guide selection. No explicit when-not-to-use or named alternative tool, which keeps it below a 5.

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.