Skip to main content
Glama

Cooper Email

Verify a custom domain now

cooper_verify_domain

Use this when DNS for a custom domain may have been published and you should check it now instead of waiting for the daily cron. Requires auth. Inputs: domain_id (required; the dom_… id from cooper_add_domain or cooper_list_domains). Runs the same DNS check as the cron, stores per-record status (valid, missing, or invalid), found, and hint, plus warnings, and returns the domain. hint is null when the record is valid or no specific mistake was found. warnings is an empty array when none. Which records are valid, missing, or invalid is unchanged. Fires domain.verified once when status moves from pending to verified. At most once per 60 seconds; the next call returns HTTP 429 rate_limited with Retry-After. 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. Failure codes: unauthorized, domain_not_found, rate_limited.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domain_idYesDomain id (dom_…) from cooper_add_domain or cooper_list_domains

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: a 60-second rate limit with HTTP 429/Retry-After, plan limits (Starter 15, Pro 200, Free 0 -> 402 plan_limit_exceeded), stored per-record status/found/hint/warnings, and the domain.verified event fired on pending->verified. Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) are consistent with a non-read status-writing check, so no contradiction.

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 heavily bloated with content that does not belong to this tool: routing MX/SPF/DKIM/DMARC record setup, mail.receiving timing, POST /api/v1/inboxes behavior, and the full DELETE /api/v1/domains/:id cleanup semantics. These paragraphs do not help an agent invoke cooper_verify_domain and dilute the genuinely useful first sentences.

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?

With no output schema, the description fully explains the return shape (per-record status as valid/missing/invalid, found, hint, warnings, the domain) and edge cases (hint null, warnings empty array). Nothing needed to call it or interpret the result is missing.

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% and there is only one parameter, so the schema already carries the semantics. The description repeats the same origin hint ('dom_… id from cooper_add_domain or cooper_list_domains') without adding format or constraint detail beyond the schema. Baseline 3 applies.

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 opening sentence names a specific verb and resource ('check DNS for a custom domain now') and frames it against the daily cron, so the agent knows this is an on-demand verification trigger. It doesn't fully differentiate from the sibling domain tools (cooper_list_domains, cooper_add_domain are mentioned only as id sources, not as alternatives), which keeps it below a 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?

Explicit when-to-use is given: 'when DNS for a custom domain may have been published and you should check it now instead of waiting for the daily cron.' The alternative (wait for cron) is named with its selection condition. No explicit when-not to call it, so it falls short of a 5.

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.