Cooper Email

Confirm an owner with a code

cooper_confirm_owner

Idempotent

Use this when a human received the 6-digit confirmation code and you need to mark that owner verified so they can receive updates and open tasks. Requires auth. Inputs: inbox_id (required; inbox id, username, or email), owner_id (required), code (required; 6 digits). Returns the owner {id, inbox_id, email, status, digest, created_at, verified_at, unsubscribed_at}. A verified owner is returned again. Fails with 400 confirm_invalid, 400 confirm_expired, 400 confirm_locked, 404 owner_not_found, or 404 inbox_not_found.

Input Schema

Name	Required	Description
`code`	Yes	6-digit confirmation code from the confirmation email
`inbox_id`	Yes	Inbox id (inb_…), username, or full email address owned by this key
`owner_id`	Yes	Owner id (own_…) returned when the owner was registered

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 confirmed owner.",
+  "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"
+}

AddedOct 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Beyond the annotations (idempotent, non-destructive), the description discloses the auth requirement, the idempotent replay behavior ('a verified owner is returned again'), and the exact failure modes with status codes (confirm_invalid, confirm_expired, confirm_locked, owner_not_found, inbox_not_found). That is material context an agent can act on, though it doesn't say whether codes are rate-limited per attempt beyond confirm_locked.

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, then inputs, return shape, and error taxonomy in a tight sequence. The return-field enumeration is mildly redundant given an output schema exists, but the density of actionable information is high.

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

Completeness4/5

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

For a three-parameter confirmation mutation, the agent gets precondition, auth need, idempotent replay semantics, and every failure code. Restating the return schema is unnecessary since an output schema exists, which is the only real gap.

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 description mostly restates the schema (inbox_id accepting id/username/email, 6-digit code). Nothing about code formatting edge cases or owner_id scoping is added beyond structured fields, so baseline 3 applies.

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?

The description states a specific verb and resource ('mark that owner verified') plus the precondition (human received the 6-digit code). It clearly distinguishes this from siblings like cooper_add_owner (registration) or cooper_wait_for_code (fetching the code).

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 triggering condition: use when a human has the 6-digit code and you need to mark the owner verified to receive updates and open tasks. It doesn't explicitly name cooper_wait_for_code as the sibling that retrieves the code, so the hand-off between tools is left implicit.

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.