Cooper Email

Update inbox rule

cooper_update_rule

Idempotent

Use this to change a stored inbox rule. Requires auth and message_update. Replacing actions with forward_to or auto_reply, or enabling a disabled rule that has them, also needs message_send. HTTP 403 permission_denied with param actions otherwise. Disabling a rule or removing those actions stays on message_update. Inputs: inbox_id (required), rule_id (required), and any of name, enabled, position, conditions, actions, stop_processing. Omitted fields stay as they are. forward_to is checked again. Returns the updated inbox_rule. An unknown rule is HTTP 404 rule_not_found. A bad body is HTTP 400 invalid_rule. A disallowed forward_to is HTTP 400 forward_target_not_allowed.

Input Schema

Name	Required	Description
`name`	No	Replacement name, 1 to 80 characters.
`actions`	No	Replacement actions. Replaces the stored object.
`enabled`	No	Turn the rule on or off.
`rule_id`	Yes	Rule id (rul_…).
`inbox_id`	Yes	Inbox id (inb_…), username, or full email address owned by this key
`position`	No	Replacement sort key. Lower numbers run first.
`conditions`	No	Replacement conditions. Replaces the stored object.
`stop_processing`	No	Whether a match stops later rules.

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 inbox rule after the update.",
+  "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.3/5.0

Behavior5/5

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

Goes well past the annotations (readOnly=false, idempotent=true, destructive=false) by disclosing auth scopes, patch semantics ('Omitted fields stay as they are'), the forward_to re-check, and the returned inbox_rule. It also enumerates concrete failure modes with HTTP status and error codes (404 rule_not_found, 400 invalid_rule, 400 forward_target_not_allowed, 403 permission_denied).

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 purpose, then permission conditions, then inputs, then error codes — a sensible order with no filler sentences. It is dense and reads as one long block rather than separated segments, which slightly hurts scannability.

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 an 8-parameter mutation with nested objects, annotations, and an output schema, the description covers everything an agent needs: permissions, patch semantics, side validations, return value, and per-error behavior. Return-shape detail is correctly deferred to the output schema.

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 description coverage is 100%, so the baseline is a 3; the description still adds real meaning by listing which fields are required, enumerating the optional patch fields, and stating the partial-update rule that omitted fields are untouched. 'forward_to is checked again' adds a validation semantic not present in the schema.

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?

Opens with a specific verb + resource ('change a stored inbox rule') and the update-versus-create distinction is unambiguous. It never names a sibling such as cooper_create_rule, cooper_delete_rule, or cooper_test_rule, so routing relies on the tool name rather than on the description.

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 unusually precise when-conditions around scope requirements: forward_to/auto_reply actions or enabling a disabled rule with them additionally need message_send, and a 403 permission_denied with param actions otherwise, while disabling or removing them stays on message_update. It does not point to an alternative tool (e.g., test_rule to preview, create_rule for a new rule), so tool-to-tool routing guidance is absent.

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.