Cooper Email

Buy extra inboxes, domains, or email

cooper_set_addons

Idempotent

Use this when a Starter or Pro account needs more inboxes, custom domains, or monthly emails than the plan includes. Requires auth. A sub-account key returns HTTP 403 workspace_billing_forbidden. Free, a grandfathered account, and an account with no Stripe subscription return HTTP 402 plan_limit_exceeded and buy nothing. A past_due, unpaid, or incomplete subscription returns HTTP 402 subscription_not_current. Inputs: inboxes, domains, and email_packs are optional integers from 0 to 100. At least one is required. Each number replaces that add-on quantity. One extra inbox is $1 per month. One extra custom domain is $1 per month. One email pack is $1 per month and adds 1,000 emails. An increase is invoiced immediately, and the cap rises only after Stripe confirms payment. A decrease is not credited. A quantity below live usage returns HTTP 409 addon_below_usage. Email packs already used stay locked until the Stripe period ends. Setting a quantity to 0 removes unused extra capacity. Returns {object:"usage_addons", inboxes, domains, email_packs, previous, extra_emails, monthly_cents, lookup_keys, limits}. Lookup keys are cooper_overage_inbox_monthly, cooper_overage_domain_monthly, and cooper_overage_sends_1000_monthly. npm run stripe:setup creates those prices. HTTP 402 addon_payment_failed means the invoice was not paid and the quantity was not saved. HTTP 503 stripe_not_configured when Stripe is unset, stripe_price_missing when a price is absent, and usage_addon_failed when Stripe refuses the change for another reason.

Input Schema

Name	Required	Description
`domains`	No	Extra custom domains to keep on the subscription. Replaces the previous quantity. $1 per month each.
`inboxes`	No	Extra inboxes to keep on the subscription. Replaces the previous quantity. $1 per month each.
`email_packs`	No	1,000-email packs to keep on the subscription. Replaces the previous quantity. $1 per pack each month.

Output Schema

Name	Required	Description
`limits`	No	Plan limits that apply to this account.
`object`	No	Object type name, such as list, message, or thread.
`domains`	No	Extra custom domains on the subscription.
`inboxes`	No	Extra inboxes on the subscription.
`previous`	No	Quantities before this change.
`email_packs`	No	Extra email packs on the subscription.
`lookup_keys`	No	Stripe price lookup keys that were used.
`extra_emails`	No	Extra monthly emails the packs add.
`monthly_cents`	No	Monthly add-on cost in US cents.

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 add-on quantities now on the subscription.",
+  "properties": {
+    "domains": {
+      "description": "Extra custom domains on the subscription."
+    },
+    "email_packs": {
+      "description": "Extra email packs on the subscription."
+    },
+    "extra_emails": {
+      "description": "Extra monthly emails the packs add."
+    },
+    "inboxes": {
+      "description": "Extra inboxes on the subscription."
+    },
+    "limits": {
+      "description": "Plan limits that apply to this account."
+    },
+    "lookup_keys": {
+      "description": "Stripe price lookup keys that were used."
+    },
+    "monthly_cents": {
+      "description": "Monthly add-on cost in US cents."
+    },
+    "object": {
+      "description": "Object type name, such as list, message, or thread."
+    },
+    "previous": {
+      "description": "Quantities before this change."
+    }
+  },
+  "type": "object"
+}

AddedOct 20, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only say this is a non-read-only, idempotent, open-world call, so the description carries the real burden and does so thoroughly: immediate invoicing, caps rising only after Stripe confirms payment, decreases never credited, used email packs locked until period end, quantity 0 as removal. The 'each number replaces that add-on quantity' semantics align with idempotentHint, and nothing here contradicts destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The eligibility and billing mechanics are correctly front-loaded, but the body becomes a dense run-on that exhaustively enumerates HTTP codes and includes implementation details (npm run stripe:setup, raw lookup key strings) that a calling agent cannot act on. Several clauses could be consolidated into a compact error summary without losing signal.

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?

Given this is a billing mutation with a real cost and multiple failure modes, the description covers prerequisites, side effects, and error handling comprehensively. It also restates the return object even though an output schema exists, which is slightly redundant but harmless; the only real gap is the absence of alternative-tool routing for plan upgrades.

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% and the schema already documents replacement semantics and pricing, so the baseline is 3. The description still adds genuine meaning beyond the schema by tying each parameter to a failure mode (409 addon_below_usage for quantities under live usage, 402 addon_payment_failed when the invoice is unpaid) and to the returned usage_addons shape and lookup keys.

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?

The description states a concrete action and resource: buying/adjusting add-on capacity (inboxes, custom domains, email packs) beyond a Starter/Pro plan. This distinguishes it from creation-style siblings such as cooper_create_inbox, since the framing is about paid capacity on an existing subscription. It stops short of explicitly naming which sibling to use for plain inbox creation, so it lands at 4 rather than 5.

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?

Strong contextual guidance: it names eligible plan tiers and lists the exact preconditions that make the call fail (sub-account key, free/grandfathered plans, no Stripe subscription, past_due/unpaid state). What's missing is an explicit pointer to alternatives such as cooper_upgrade_link or cooper_create_inbox when the caller actually wants a plan change rather than an add-on, so no exclusion routing is provided.

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.