Cooper Email

Create inbox rule

cooper_create_rule

Idempotent

Use this when mail like X should be labeled, filed, forwarded, or acknowledged on the server with no model call. Requires auth and message_update. Creating a rule with forward_to or auto_reply also needs message_send. HTTP 403 permission_denied with param actions when it does not, and nothing is stored. Inputs: inbox_id (required), name (required, 1–80 characters), conditions (required object; at least one of from, to, subject_contains, body_contains, has_attachment, auth, list), actions (required object; at least one of add_labels, folder, mark_read true, forward_to, auto_reply, or stop_processing), enabled (optional boolean, default true), position (optional integer; lower runs first), stop_processing (optional boolean), client_id (optional idempotency key, at most 128 characters). from is an email, @domain, or a domain. auth is pass or fail and uses DMARC. forward_to is another inbox on this account or a verified owner of this inbox. auto_reply.text is at most 2,000 characters. auto_reply.cooldown_hours is 1–720 and defaults to 24. An inbox stores at most 20 rules (HTTP 409 rule_limit). A bad rule is HTTP 400 invalid_rule. A disallowed forward_to is HTTP 400 forward_target_not_allowed. The same client_id returns the original rule and does not create a second one. Returns the inbox_rule.

Input Schema

Name	Required	Description
`name`	Yes	Rule name, 1 to 80 characters.
`actions`	Yes	add_labels, folder (inbox\|archive\|spam\|trash), mark_read, forward_to, auto_reply {text, subject?, cooldown_hours?}.
`enabled`	No	When false the rule is stored and does not run. Default true.
`inbox_id`	Yes	Inbox id (inb_…), username, or full email address owned by this key
`position`	No	Sort key. Lower numbers run first. Ties break by created_at. Omit to append.
`client_id`	No	Optional idempotency key, 1 to 128 characters. The same key returns the original rule.
`conditions`	Yes	All set conditions must match. from, to, subject_contains, body_contains (max 256), has_attachment, auth pass\|fail, list.
`stop_processing`	No	When true, later rules do not run after this one matches.

Output Schema

Name	Required	Description
`id`	No	Rule id. Pass it as rule_id.
`name`	No	Human-readable name.
`object`	No	Object type name, such as list, message, or thread.
`actions`	No	What happens to a matching message.
`enabled`	No	True when the object is active.
`inbox_id`	No	Inbox id (inb_…) this object belongs to. Null when it applies to every inbox.
`position`	No	Order the rule runs in. Lower runs first.
`client_id`	No	Caller idempotency key stored with the object, or null.
`conditions`	No	What a message must match.
`created_at`	No	ISO-8601 time the object was created.
`last_error`	No	Last action error, or null.
`updated_at`	No	ISO-8601 time the object last changed.
`match_count`	No	How many messages matched.
`last_matched_at`	No	ISO-8601 time of the last match, or null.
`stop_processing`	No	When true, later rules are skipped after a match.

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 new inbox rule.",
+  "properties": {
+    "actions": {
+      "description": "What happens to a matching message."
+    },
+    "client_id": {
+      "description": "Caller idempotency key stored with the object, or null."
+    },
+    "conditions": {
+      "description": "What a message must match."
+    },
+    "created_at": {
+      "description": "ISO-8601 time the object was created."
+    },
+    "enabled": {
+      "description": "True when the object is active."
+    },
+    "id": {
+      "description": "Rule id. Pass it as rule_id."
+    },
+    "inbox_id": {
+      "description": "Inbox id (inb_…) this object belongs to. Null when it applies to every inbox."
+    },
+    "last_error": {
+      "description": "Last action error, or null."
+    },
+    "last_matched_at": {
+      "description": "ISO-8601 time of the last match, or null."
+    },
+    "match_count": {
+      "description": "How many messages matched."
+    },
+    "name": {
+      "description": "Human-readable name."
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    },
+    "position": {
+      "description": "Order the rule runs in. Lower runs first."
+    },
+    "stop_processing": {
+      "description": "When true, later rules are skipped after a match."
+    },
+    "updated_at": {
+      "description": "ISO-8601 time the object last changed."
+    }
+  },
+  "type": "object"
+}

AddedOct 26, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it discloses failure semantics the agent could not otherwise know: 403 permission_denied with param actions stores nothing, 409 rule_limit at 20 rules, 400 invalid_rule, and 400 forward_target_not_allowed. It also explains idempotency concretely ('The same client_id returns the original rule and does not create a second one').

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

Conciseness3/5

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

The opening when-to-use sentence is properly front-loaded, but the remainder is a single dense run-on packing scopes, error codes, and per-parameter limits into one block with no grouping or line breaks. Nearly every fact earns its place, yet the lack of structure makes it harder to scan.

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 nested-object mutation tool this is thorough: auth scopes, cardinality limits, error codes, idempotency behavior, and nested field bounds are all covered, and the return value is summarized as the inbox_rule while a full output schema exists. An agent has what it needs to call it correctly and interpret failures.

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 a 3 is the baseline, but the description adds genuine constraints not present in the schema: from accepts an email, @domain, or bare domain; auth uses DMARC; forward_to must be another inbox on the account or a verified owner; auto_reply.text capped at 2,000 characters and cooldown 1–720 defaulting to 24. These are real additions rather than restatements.

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 description states a specific verb+resource ('Creating a rule', 'Returns the inbox_rule') and frames the intent as server-side mail handling ('labeled, filed, forwarded, or acknowledged on the server with no model call'). It does not explicitly name siblings like cooper_update_rule or cooper_list_rules, so differentiation is inferred from the create semantics rather than stated.

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?

It gives a clear when-to-use trigger ('when mail like X should be labeled... with no model call') and lists prerequisites (auth plus message_update, message_send for forward_to/auto_reply). It does not point to alternatives for modifying or verifying a rule (update_rule, test_rule, list_rules), leaving that routing to inference.

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.