Cooper Email

Register a human owner

cooper_add_owner

DestructiveIdempotent

Use this when a human should receive the agent's progress updates by email and be able to reply with instructions. Requires auth. Sends that person one confirmation email with a link and code; they receive nothing else until they confirm. Inputs: inbox_id (required), email (required; the human's address), digest (optional; immediate (default) or daily). Returns the owner {id, inbox_id, email, status (pending|verified|unsubscribed), digest, created_at, verified_at, confirmation}. Calling again for the same email is safe.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "inbox_id": "<inbox_id>",
      "email": "<email>"
    },
    "name": "cooper_add_owner"
  }
}

Input Schema

Name	Required	Description
`email`	Yes	Human address that will receive updates
`digest`	No	immediate (default) or a daily digest
`inbox_id`	Yes	Inbox id (inb_…), username, or full email address

Output Schema

Name	Required	Description
`id`	No	Owner id.
`email`	No	The human owner's address.
`digest`	No	immediate or daily.
`status`	No	pending, verified, or unsubscribed.
`inbox_id`	No	Inbox id (inb_…) this object belongs to. Null when it applies to every inbox.
`created_at`	No	ISO-8601 time the object was created.
`verified_at`	No	ISO-8601 time the owner confirmed, or null.
`confirmation`	No	State of the confirmation email that was sent.
`unsubscribed_at`	No	ISO-8601 time the owner unsubscribed, or null.

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 owner. They get one confirmation email.",
+  "properties": {
+    "confirmation": {
+      "description": "State of the confirmation email that was sent."
+    },
+    "created_at": {
+      "description": "ISO-8601 time the object was created."
+    },
+    "digest": {
+      "description": "immediate or daily."
+    },
+    "email": {
+      "description": "The human owner's address."
+    },
+    "id": {
+      "description": "Owner id."
+    },
+    "inbox_id": {
+      "description": "Inbox id (inb_…) this object belongs to. Null when it applies to every inbox."
+    },
+    "status": {
+      "description": "pending, verified, or unsubscribed."
+    },
+    "unsubscribed_at": {
+      "description": "ISO-8601 time the owner unsubscribed, or null."
+    },
+    "verified_at": {
+      "description": "ISO-8601 time the owner confirmed, or null."
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedSep 29, 2026
- addedInput schema / properties / digest / description
```
Added value: +"immediate (default) or a daily digest"
```
- addedInput schema / properties / inbox_id / description
```
Added value: +"Inbox id (inb_…), username, or full email address"
```
First observedSep 27, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Adds genuine behavior beyond the annotations: auth is required, exactly one confirmation email is sent, nothing further is sent until the person confirms, and the return shape is listed. However, annotations declare destructiveHint=true and the description never explains what is destructive or irreversible about the call, leaving a significant declared trait unexplained. The idempotency claim is consistent with idempotentHint=true.

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 usage condition and side effects before the input list, and every sentence carries information. The 'Inputs:' enumeration largely duplicates the schema and could be trimmed, but the text remains tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers auth, side effects, idempotency, and output shape for a three-parameter mutation, which is substantial. Gaps remain: the destructiveHint=true trait is unexplained, and the relationship to cooper_confirm_owner (the follow-up the text implies) is never stated. Because an output schema exists, the return-value listing is redundant rather than compensatory.

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 description coverage is 100%, so all three parameters are already documented, including the digest enum values. The description restates them ('email — the human's address', 'digest — immediate (default) or daily') without adding format, validation, or edge-case meaning beyond the schema, so baseline 3 applies.

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?

States a specific verb+resource: registering a human owner who receives the agent's progress updates by email and can reply. The lead sentence ('Use this when a human should receive the agent's progress updates') makes the effect concrete. It does not, however, differentiate against adjacent siblings such as cooper_confirm_owner, cooper_ask_owner, or cooper_set_owner_preferences, even though it alludes to a confirm step.

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 a clear usage condition tied to the outcome the agent wants (a human receiving updates and able to reply). No explicit when-not conditions or named alternatives, so the agent must infer routing among the owner-related siblings.

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.