Skip to main content
Glama

Cooper Email

by com.cooperemail
OverviewDiscussionsAdmin

Create Cooper inbox

cooper_onboard
Destructive

Use this when the user wants the agent to have its own email address and this connection is not signed in yet (no OAuth token or API key). No auth needed. Creates a Cooper account, one inbox @cooperemail.com, and an API key. Inputs: username (required; 1–32 characters: letters, digits, . _ -), display_name (optional From name), owner_email (optional; starts the existing owner confirmation and stays pending until the human confirms), check_username (optional boolean). Returns {account_id, api_key, api_key_id, inbox:{id, username, email, display_name, created_at, require_sender_auth, status, paused_at}, next_steps}. next_steps is a short instruction, a recommended owner line, and links to /docs/stay-in-sync. recommended is a suggestion to add the human owner's email, not a requirement. When owner_email is set, the response also includes owner {id, email, status}. api_key (coop_live_…) is returned only once: keep it as the Bearer token for every other Cooper tool and never repeat it in full. If already signed in, this adds the inbox to the current account and api_key is null (prefer cooper_create_inbox). Fails with 409 inbox_exists if the address is taken. When check_username is true, do not create an account or inbox. Return {name, normalized, available, reason, suggestions} for username. suggestions lists up to 5 names that pass the same username rules, are not reserved, and are not already an inbox. GET /api/v1/usernames/check is the same public check (30 requests per minute per IP, then HTTP 429 rate_limited). That HTTP response includes RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset. A lookup that cannot be completed is HTTP 503 username_check_unavailable. If the limit cannot be checked, the result is HTTP 503 rate_limit_unavailable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
usernameYesLocal part of the address, becoming username@cooperemail.com
owner_emailNoRecommended human address. Cooper emails a confirmation. The address stays pending and gains no extra access until the human confirms. Omit it and the inbox is still created.
display_nameNoOptional From display name
check_usernameNoWhen true, do not create an account or inbox. Return whether username is available and up to 5 free suggestions. The same 30 per minute per IP limit as GET /api/v1/usernames/check 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.

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 account or inbox. Return whether username is available and up to 5 free suggestions."New value: +"When true, do not create an account or inbox. Return whether username is available and up to 5 free suggestions. The same 30 per minute per IP limit as GET /api/v1/usernames/check 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."
  2. Changed1 schema field changed
    • changedInput schema / properties / owner_email / description
      Previous value: -"Optional human address. Cooper emails a confirmation. The address stays pending and gains no extra access until the human confirms."New value: +"Recommended human address. Cooper emails a confirmation. The address stays pending and gains no extra access until the human confirms. Omit it and the inbox is still created."
  3. Changed1 schema field changed
    • addedInput schema / properties / owner_email
      Added value: +{
+  "description": "Optional human address. Cooper emails a confirmation. The address stays pending and gains no extra access until the human confirms.",
+  "type": "string"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / check_username
      Added value: +{
+  "description": "When true, do not create an account or inbox. Return whether username is available and up to 5 free suggestions.",
+  "type": "boolean"
+}
  5. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With annotations limited to readOnly/destructive/idempotent/openWorld flags, the description carries substantial extra context: no auth required, the api_key is returned only once and must be reused as the Bearer token for every other Cooper tool, failure codes (409 inbox_exists), and precise rate-limit behavior (30 req/min per IP, HTTP 429 rate_limited, 503 username_check_unavailable, 503 rate_limit_unavailable). This is well beyond what the annotations disclose.

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-loading is good — the trigger condition leads — but the body is a dense block that repeats the rate-limit and error-code text already present in the check_username schema description, and the raw '{account_id, api_key, ...}' return dump is unstructured. Much of it earns its place given there is no output schema, but the duplication costs it.

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?

There is no output schema, so the description must document returns, and it does: the full create response shape, next_steps/recommended semantics, the conditional owner object, and the check_username response shape. For a tool with two modes, auth nuances, and rate limits, nothing an agent needs to call it correctly 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 value the schema lacks — the username character rules (1–32 chars: letters, digits, . _ -) and the fact that check_username suppresses account creation entirely. It reinforces owner_email's 'recommended, not required' framing rather than just restating it.

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?

States a specific verb and multi-part resource: 'Creates a Cooper account, one inbox <username>@cooperemail.com, and an API key.' It also distinguishes itself from the closest sibling by name — 'If already signed in, this adds the inbox to the current account ... (prefer cooper_create_inbox)' — so an agent can route between the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit trigger condition ('when the user wants the agent to have its own email address and this connection is not signed in yet (no OAuth token or API key)') and names the alternative to use when that condition fails. It also defines the alternate check-only mode via check_username, so both use cases are covered.

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

All Cooper Email toolsInspect
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.

Resources