GetCourier

Add your own domain

add_domain

Send (and optionally receive) from your own domain instead of @getcourier.dev, so your sending reputation is your own. Needs an account with credits. Returns the DNS records to publish: 3 DKIM CNAMEs, a MAIL FROM MX + SPF, a DMARC suggestion, and an inbound MX if you also want to receive. Use a dedicated subdomain such as agents.yourcompany.com. Next: publish the DNS records it returns, then call domain_status until status is verified.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "add_domain"
  }
}

Input Schema

Name	Required	Description	Default
`domain`	Yes	The domain or subdomain you control, e.g. agents.example.com.
`account_key`	No	The account_key returned by create_account (or send it as Authorization: Bearer).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden well: it discloses the credit prerequisite, the exact return payload (3 DKIM CNAMEs, MAIL FROM MX + SPF, DMARC suggestion, optional inbound MX), and the multi-step verification flow. It stops short of stating idempotency (what happens if the domain is already added) or whether the call itself consumes credits, which matters 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.

Conciseness5/5

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

Four sentences, each carrying distinct load: value proposition, prerequisite, return payload, and next step. The prerequisite and the DNS return details are front-loaded before the workflow instruction, so an agent gets the gating conditions first.

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?

No output schema exists, and the description compensates by enumerating the returned DNS record types and pointing to domain_status for verification. What's missing is failure behavior (invalid domain, insufficient credits) and whether re-adding an existing domain errors or is a no-op.

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 both parameters are already documented, making 3 the baseline. The description adds modest value by steering toward a dedicated subdomain (agents.yourcompany.com), reinforcing the domain parameter's intended shape, but says nothing extra about account_key beyond what the schema states.

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 resource ('Send (and optionally receive) from your own domain') and clearly delineates it from the sibling domain_status, which it names as the follow-up step. An agent can distinguish it from create_inbox or send_message without opening a 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?

Gives explicit preconditions ('Needs an account with credits'), a configuration recommendation ('Use a dedicated subdomain such as agents.yourcompany.com'), and the exact post-call workflow: publish the returned DNS records, then poll domain_status until verified. This is a full when/how/next sequence with no inference required.

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

All GetCourier 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.

Resources

Need Help?