Skip to main content
Glama

Cooper Email

Add a custom domain

cooper_add_domain
DestructiveIdempotent

Use this when the user wants mail on their own hostname and the account is on Starter or Pro. Requires auth. One call returns the SPF, DKIM, DMARC, and MX records to publish, plus a verify TXT. Inputs: domain (required hostname, such as agents.example.com), client_id (optional idempotency key). Returns {id, domain, status, status_detail, mail, records, warnings, dns}. Each record includes status (valid, missing, or invalid), found from the last check, and hint. hint is null when the record is valid or no specific mistake was found. Otherwise hint is {code, message, found_at} and says what to change. warnings is an empty array when none. existing_mail_provider means this hostname already has MX at another provider. mail.receiving, mail.sending, and mail.inboxes stay false until the matching records for that domain verify. Inboxes on your own domain are included on Starter (15 custom domains) and Pro (200 custom domains). Free includes 0 custom domains and returns HTTP 402 plan_limit_exceeded. When the hostname is already a zone on the operator Cloudflare account, Cooper writes the DNS records and dns.mode is automatic. Cooper does not register a domain or create a zone. Any other zone stays manual. Publish the routing MX hosts, TXT SPF v=spf1 include:_spf.mx.cloudflare.net ~all, the routing DKIM TXT, the cf-bounce MX, SPF, and DKIM records, a DMARC TXT (an existing DMARC record is left as it is), and the _cooper-verify TXT. mail.receiving stays false until the receiving records check out and the catch-all is live. Receiving goes live within a few minutes. status_detail says so while you wait. POST /api/v1/inboxes with domain then creates username@domain. DELETE /api/v1/domains/:id puts back the catch-all that was there before, deletes only the DNS records Cooper created, turns Email Routing off only if Cooper turned it on, and removes the sending domain only if Cooper created it. A cleanup that does not finish keeps the row with status cleanup_failed and deleted false so a later delete can finish it. status is pending until DNS matches; calling again with the same domain returns the current status and does not create a second domain. dns.mode is automatic only when Cooper already controls that Cloudflare zone and wrote the records there; otherwise publish the records yourself. Cooper does not register a domain or create a zone. HTTP 402 plan_limit_exceeded with upgrade_url means this plan does not include another custom domain. HTTP 409 domain_exists means another account already registered it. HTTP 400 invalid_domain means the hostname is not usable. Subscribe to domain.verified on POST /api/v1/webhooks; the daily cron sends it when the records check out. List domains with cooper_list_domains. Check now with cooper_verify_domain. 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
domainYesHostname to attach, such as agents.example.com
client_idNoOptional idempotency key. The same key returns the original domain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Far beyond the annotations: it discloses idempotent re-call behavior, the exact returned record set, status transitions (pending until DNS matches), per-record status/hint semantics, automatic vs manual dns.mode, the webhook event to subscribe to, and cleanup semantics with cleanup_failed/deleted. This is the kind of behavioral detail that would otherwise be invisible.

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

Conciseness2/5

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

The description is a dense wall of text with real redundancy: 'Cooper does not register a domain or create a zone' and the dns.mode automatic-only condition each appear twice, and the DNS record enumeration is repeated. The critical routing facts are buried mid-paragraph rather than front-loaded, hurting scanability.

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 mutation with no output schema and non-trivial side effects, the description is unusually complete: it documents the return shape, error codes, plan limits, DNS record publication, verification gating, and teardown behavior. An agent has everything needed to call it and interpret the result.

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 description coverage is 100%, so the schema already documents both parameters. The description restates domain (required hostname) and client_id (optional idempotency key) but adds no syntax or constraint detail beyond the schema. Baseline 3 is correct when the schema carries the parameter burden.

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 opening states a specific trigger (user wants mail on their own hostname) and names the plan gating (Starter or Pro), which pins down the resource precisely. It also names siblings cooper_list_domains and cooper_verify_domain, so the agent can separate this create/attach operation from listing and verification.

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?

Explicit when-to-use ('user wants mail on their own hostname and the account is on Starter or Pro'), plus explicit exclusions and error routing (Free returns HTTP 402 plan_limit_exceeded, 409 domain_exists, 400 invalid_domain). It also names the alternatives to reach for (cooper_list_domains, cooper_verify_domain) and the follow-up flow (POST /api/v1/inboxes).

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.