SenderKit

Claim Inbound Domain

senderkit_inbound_domains_create

Destructive

Claim a custom domain for receiving mail (e.g. "inbound.acme.com"). Returns the DNS records (MX, DKIM) to publish at the domain's DNS host. If the domain already has live MX records pointing elsewhere, the call fails with an existing_mx error naming the current host(s); with acknowledgeExistingMx: true it claims the domain anyway, which redirects all of that domain's mail to SenderKit. Nothing is received until the records are live and verification completes.

Input Schema

Name	Required	Description
`domain`	Yes	Custom domain to claim for receiving, e.g. "inbound.acme.com". Must not already be claimed (by this or another workspace) and must not be a senderkit.com/senderkit.email suffix.
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
`acknowledgeExistingMx`	No	Claim the domain even though it already has live MX records pointing elsewhere; this redirects all of the domain's mail to SenderKit. Without it, such a domain fails with an existing_mx error naming the current host(s).

Output Schema

Name	Required	Description
`id`	Yes	Inbound domain id (UUID) — the id senderkit_inbound_domains_delete takes.
`kind`	Yes	shared = the managed {slug}.in.senderkit.email domain; custom = a claimed domain.
`domain`	Yes	The domain, e.g. inbound.acme.com.
`status`	Yes	Verification state; only verified domains receive mail.
`records`	Yes	DNS records the user must publish (custom domains only; empty for the shared domain). Surface them verbatim.
`createdAt`	Yes	When the domain was claimed.
`verifiedAt`	Yes	When verification completed, or null.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description adds crucial context beyond them: the existing_mx failure with the current host(s), that acknowledging redirects ALL domain mail, and that nothing is received until records are live and verification completes. This level of consequence disclosure is exemplary.

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?

Three tight sentences, front-loaded with the core action and immediately followed by return semantics and the failure/override path. Every clause earns its place with no filler.

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 an output schema present (DNS records) and annotations covering the mutation/open-world profile, the description supplies the missing behavioral detail: failure mode, override consequence, and the prerequisite that verification must complete. Nothing an agent needs to invoke this correctly is absent.

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 coverage is 100%, so the schema already documents all three parameters including the acknowledgeExistingMx behavior. The description reinforces the MX-redirect consequence but adds no syntactic or format detail beyond the schema; baseline 3 is appropriate.

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?

Specific verb+resource ('Claim a custom domain for receiving mail') with a concrete example ('inbound.acme.com'), and it is clearly distinguishable from domain siblings like list/delete. The purpose is unmistakable from the opening clause.

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?

Explains the operational condition for the acknowledgeExistingMx path and describes the existing_mx failure mode, effectively guiding when the flagged flag is needed. It does not explicitly reference alternatives or prerequisites like plan requirements, but context for the primary decision point is clear.

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

All SenderKit tools Inspect

Try in Browser