Skip to main content
Glama

Cooper Email

Create another inbox

cooper_create_inbox
Destructive

Use this when the signed-in account needs an additional email address (for example one per agent, project, or customer). Requires auth. Inputs: username (optional; 1–32 characters; becomes @cooperemail.com; omit it and Cooper picks box plus 8 hex characters, the same generator as a batch with no prefix), domain (optional hostname), display_name (optional From name), metadata (optional object; at most 256 keys, keys at most 256 characters, values string number or boolean, serialized at most 16 KB), client_id (optional idempotency key, at most 128 characters), check_username (optional boolean). When custom-domain mail is off, domain is ignored. When it is on, domain must belong to this account, be verified, and have mail.receiving true, and the address is username@domain. Returns the new inbox {id, username, email, display_name, created_at, require_sender_auth, labels, expires_at, status, paused_at, metadata, client_id} plus next_steps. next_steps.recommended suggests adding a human owner email. That line is a recommendation, not a requirement. Optional notify_url registers a message.received webhook for the new inbox and returns webhook. The URL must be public http or https. Localhost and private addresses are rejected. The same client_id on this account returns the original inbox with idempotent true and HTTP 200 and does not create another. Fails with 409 inbox_exists if the address is taken, 400 invalid_metadata, 404 domain_not_found, 409 domain_not_verified, 409 domain_receiving_not_ready, or 402 with upgrade_url if the plan's inbox limit is reached. When check_username is true, do not create an inbox. Return the same availability object as cooper_onboard. The same 30 per minute per IP limit applies. Over the limit the result is rate_limited. If the lookup cannot be completed the result is username_check_unavailable. If the limit cannot be checked the result is rate_limit_unavailable. Auth is still required. Omit username and the result is invalid_username. When usage is at 80 percent of a plan limit, the response includes notices: [{type: limit_warning, resource, used, limit, upgrade_url}].

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoOptional customer hostname. Ignored while custom-domain mail is off. When on, the domain must be verified on this account with mail.receiving true.
metadataNoOptional caller data stored on the inbox. At most 256 keys, each key at most 256 characters, values string number or boolean, serialized at most 16 KB. Otherwise 400 invalid_metadata.
usernameNoOptional local part. Omit it and Cooper picks box plus 8 hex characters. When set, the address is username@cooperemail.com unless domain is set and custom-domain mail is on
client_idNoOptional idempotency key, at most 128 characters. The same client_id on this account returns the original inbox.
notify_urlNoOptional public http(s) URL. Registers a message.received webhook for the new inbox. Localhost and private addresses are rejected.
display_nameNoOptional From display name
check_usernameNoWhen true, do not create an inbox. Return whether username is available and up to 5 free suggestions. The same 30 per minute per IP limit applies. Over the limit the result is rate_limited. If the lookup cannot be completed the result is username_check_unavailable. If the limit cannot be checked the result is rate_limit_unavailable. Auth is still required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / check_username / description
      Previous value: -"When true, do not create an inbox. Return whether username is available and up to 5 free suggestions. Auth is still required."New value: +"When true, do not create an inbox. Return whether username is available and up to 5 free suggestions. The same 30 per minute per IP limit applies. Over the limit the result is rate_limited. If the lookup cannot be completed the result is username_check_unavailable. If the limit cannot be checked the result is rate_limit_unavailable. Auth is still required."
  2. Changed1 schema field changed
    • addedInput schema / properties / notify_url
      Added value: +{
      +  "description": "Optional public http(s) URL. Registers a message.received webhook for the new inbox. Localhost and private addresses are rejected.",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / check_username
      Added value: +{
      +  "description": "When true, do not create an inbox. Return whether username is available and up to 5 free suggestions. Auth is still required.",
      +  "type": "boolean"
      +}
  4. Changed4 schema fields changed
    • addedInput schema / properties / client_id
      Added value: +{
      +  "description": "Optional idempotency key, at most 128 characters. The same client_id on this account returns the original inbox.",
      +  "type": "string"
      +}
    • addedInput schema / properties / metadata
      Added value: +{
      +  "description": "Optional caller data stored on the inbox. At most 256 keys, each key at most 256 characters, values string number or boolean, serialized at most 16 KB. Otherwise 400 invalid_metadata.",
      +  "type": "object"
      +}
    • changedInput schema / properties / username / description
      Previous value: -"Local part of the new address, becoming username@cooperemail.com unless domain is set and custom-domain mail is on"New value: +"Optional local part. Omit it and Cooper picks box plus 8 hex characters. When set, the address is username@cooperemail.com unless domain is set and custom-domain mail is on"
    • removedInput schema / required
      Removed value: -[
      -  "username"
      -]
  5. Changed2 schema fields changed
    • addedInput schema / properties / domain
      Added value: +{
      +  "description": "Optional customer hostname. Ignored while custom-domain mail is off. When on, the domain must be verified on this account with mail.receiving true.",
      +  "type": "string"
      +}
    • changedInput schema / properties / username / description
      Previous value: -"Local part of the new address, becoming username@cooperemail.com"New value: +"Local part of the new address, becoming username@cooperemail.com unless domain is set and custom-domain mail is on"
  6. Changed2 schema fields changed
    • addedInput schema / properties / display_name / description
      Added value: +"Optional From display name"
    • addedInput schema / properties / username / description
      Added value: +"Local part of the new address, becoming username@cooperemail.com"
  7. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Goes well past the annotations: it documents the returned object shape, idempotency-key behavior (same client_id returns the original inbox with idempotent true/HTTP 200), the full error surface (409 inbox_exists, 400 invalid_metadata, 404 domain_not_found, 409 domain_not_verified, 409 domain_receiving_not_ready, 402 with upgrade_url), rate limits (30/min per IP with rate_limited / username_check_unavailable / rate_limit_unavailable outcomes), plan-limit notices, and optional webhook registration semantics. This is exceptional disclosure for a mutation tool.

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?

Front-loaded with the triggering condition, but the body is a single dense block that restates many schema-level constraints (metadata limits, notify_url rules, check_username details) rather than keeping them in the schema. Each fact is useful, yet the structure could be tightened considerably.

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 zero-required-parameter creation tool with no output schema, the description supplies everything needed: required auth, input semantics, return shape, idempotency, error codes, rate limits, and webhook side effects. Nothing material is missing.

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 the baseline is 3, but the description adds cross-parameter meaning: the address form depends jointly on username and whether custom-domain mail is on, the username generator ('box' plus 8 hex characters when omitted), and the domain verification/receiving preconditions. It largely mirrors the schema but integrates the parameters into address-formation rules.

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 (create an additional inbox/email address) with concrete use cases (per agent, project, or customer). It never names the closely related batch sibling cooper_create_inboxes, though the singular/plural split makes the distinction inferable.

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 triggering condition ('when the signed-in account needs an additional email address') and explains the alternate check_username mode where no inbox is created. It does not point the agent to cooper_create_inboxes or cooper_onboard as alternatives for adjacent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.