Cooper Email

Request auto-forward confirmation

cooper_request_forwarding

Idempotent

Use this when every inbound copy on an inbox should also go to an external address, such as a team mailbox or an archive. Requires auth and inbox_update. Inputs: inbox_id (required), email (required), client_id (optional, 1–128 characters). Cooper emails a 6-digit code to that address only. The code is not stored in a Cooper inbox and is not returned. The human confirms it with POST /api/v1/inboxes/{id}/forwarding/confirm. Returns the destination with status pending (HTTP 202) or verified (HTTP 200 when it was already verified). The same client_id returns the original destination and does not send another code. An inbox stores at most 5 destinations (HTTP 409 forwarding_limit). That cap is technical and does not change Free, Starter, or Pro. The inbox itself, an address at cooperemail.com, and any Cooper inbox are HTTP 400 forwarding_target_not_allowed. Confirmation email is limited to 5 per hour per IP and 3 per day per address (HTTP 429 rate_limited). Actual forwards later use the send path and count toward the monthly send quota. rules forward_to is unchanged.

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_request_forwarding"
  }
}

Input Schema

Name	Required	Description
`email`	Yes	External address that should receive copies after the human confirms. Not this inbox and not a Cooper inbox.
`inbox_id`	Yes	Inbox id (inb_…), username, or full email address owned by this key
`client_id`	No	Optional idempotency key, 1 to 128 characters. The same key returns the original destination and does not email another code.

Output Schema

Name	Required	Description
`id`	No	Stable id of the returned object. Pass it to the matching get, update, or delete tool.
`email`	No	Email address.
`object`	No	Object type name, such as list, message, or thread.
`status`	No	pending until the human confirms, or verified when it already was.
`client_id`	No	Caller idempotency key stored with the object, or null.
`created_at`	No	ISO-8601 time the object was created.
`expires_at`	No	ISO-8601 time a pending code expires, or null once verified.
`updated_at`	No	ISO-8601 time the object last changed.
`verified_at`	No	ISO-8601 time the address was confirmed, or null.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 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: discloses the 6-digit code flow, that the code is neither stored nor returned, that a human must confirm via a separate endpoint, the 202-pending vs 200-already-verified distinction, and that the same client_id suppresses a second email. It also documents limits and failure modes the annotations cannot express — 5-destination cap with 409 forwarding_limit, 400 forwarding_target_not_allowed for self/cooperemail.com/Cooper targets, and 429 rate limits of 5/hour per IP and 3/day per address.

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 use case and prerequisites, and nearly every sentence carries distinct operational facts. It is a dense prose block, however — the return-status, cap, error, and rate-limit facts would scan faster as a short list, and the closing 'rules forward_to is unchanged' note is terse enough to be ambiguous.

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 two-step, rate-limited, quota-affecting mutation, the description covers the full lifecycle: request, out-of-band human confirmation, idempotent retry, limits, and how later forwards bill against the send quota. With an output schema present, the absence of a return-field inventory is not a gap.

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 already 100%, so the baseline is 3; the description earns above that by tying email to the 400 forwarding_target_not_allowed rule (not this inbox, not a Cooper inbox) and by restating the client_id idempotency contract as behavior rather than as a field note. It adds little on inbox_id beyond the schema's own enumeration of id/username/email.

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 condition-plus-action: 'Use this when every inbound copy on an inbox should also go to an external address,' which pins down the resource (inbox forwarding destination) and the trigger. The follow-on mention of the human confirmation step distinguishes it from a direct-set tool, but it never names the near siblings cooper_set_forwarding, cooper_list_forwarding, or cooper_forward_message, so the agent must infer the boundary.

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 when-to-use with concrete examples ('team mailbox or an archive') plus prerequisites (auth and inbox_update). It does not state when NOT to use it or name the alternative tool for pre-verified destinations or per-message forwarding, which is the remaining gap.

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.