Cooper Email

Set owner email style

cooper_set_owner_preferences

Idempotent

Use this when the human asks for shorter, longer, or friendlier email from Cooper. Requires auth. Sets the account default (omit owner_id; needs an unscoped key with owner_manage) or one owner's style (inbox_id and owner_id). Inputs: style (concise, detailed, casual, or null to inherit), note (optional plain text up to 280 characters, or null to clear), inbox_id and owner_id (optional). Every Cooper email to owners (digest, approval request, owner updates, confirmations, recovery, send-mode notices) follows the effective style. A style the owner chose from the Change email style link in their email cannot be changed here: 409 owner_style_locked. Cooper never puts the note into an email. Returns the same shape as cooper_get_owner_preferences.

Input Schema

Name	Required	Description
`note`	No	Optional plain-text preference for the agent, at most 280 characters. null clears it.
`style`	No	concise (default), detailed, or casual. null clears it so the owner inherits the account default.
`inbox_id`	No	Inbox id, username, or address. Needed with owner_id.
`owner_id`	No	Owner id (own_…). Omit to set the account default.

Output Schema

Name	Required	Description
`owner`	No	The owner's setting {id, email, email_style, email_style_note, email_style_set_by}, when one was changed.
`account`	No	Account default {style, note, source}.
`effective`	No	The style that now applies {style, note, source}.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Owner email style preferences after the change.",
+  "properties": {
+    "account": {
+      "description": "Account default {style, note, source}."
+    },
+    "effective": {
+      "description": "The style that now applies {style, note, source}."
+    },
+    "owner": {
+      "description": "The owner's setting {id, email, email_style, email_style_note, email_style_set_by}, when one was changed."
+    }
+  },
+  "type": "object"
+}

AddedOct 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Well beyond the annotations: it discloses the auth requirement, that the account-default path needs an unscoped key with owner_manage, the 409 lock condition, and that the note is never included in any email. It also names which outgoing emails the effective style governs, which the readOnly/idempotent hints do not 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 trigger condition and the two scoping modes before the reference details. The long parenthetical enumeration of email types (digest, approval request, owner updates, confirmations, recovery, send-mode notices) is informative but the densest part of an otherwise tight paragraph.

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?

Output schema exists and the description correctly delegates return values by referencing cooper_get_owner_preferences' shape. Auth, scoping, error case, and the note's non-delivery are all covered, leaving nothing an agent needs before calling.

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; the description earns a bump by explaining the parameter interaction (inbox_id and owner_id together scope one owner, omission scopes the account) and by contrasting the two null semantics (null style inherits the account default, null note clears). Most of the remaining per-parameter detail is already in the schema, so it is not a 5.

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 ('Sets the account default ... or one owner's style') and immediately distinguishes the two scoping modes (omit owner_id vs inbox_id + owner_id). An agent can tell this apart from the read-only sibling cooper_get_owner_preferences 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 Guidelines5/5

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

Gives an explicit trigger ('Use this when the human asks for shorter, longer, or friendlier email from Cooper') and an explicit exclusion with the exact failure mode ('A style the owner chose from the Change email style link ... cannot be changed here: 409 owner_style_locked'). It also names the sibling whose return shape this mirrors.

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.