SenderKit

Create Inbound Address

senderkit_inbound_addresses_create

Create a new inbound email address that receives mail for the workspace and, optionally, forwards it and/or fires a webhook on receipt. Enforces the workspace's plan limit and validates forwardTo/webhookEndpointId.

Input Schema

Name	Required	Description
`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."
`domainId`	No	Which verified inbound domain to mint on (from senderkit_inbound_domains_list). Omit for the workspace's shared {slug}.in.senderkit.email domain.
`livemode`	No	Live mode (default true). Test-mode addresses receive real mail but fan out only to test-mode webhook endpoints, and their forwards are recorded as test sends without real delivery. Every address, test or live, counts toward the plan's inbound-address limit.
`forwardTo`	No	Email address to forward received mail to. Must be a plausible address and cannot be another inbound address (would create a mail loop).
`localPart`	No	Local part before the @, e.g. "invoices" for invoices@{slug}.in.senderkit.email — 1-64 chars of a-z, 0-9, dot, underscore, dash, starting and ending alphanumeric (lowercased; some names are reserved). Pass "*" for a catch-all that receives mail for every local part no exact address claims. Omit to mint an unguessable random one.
`description`	No	Optional internal note describing what this address is for.
`webhookEndpointId`	No	This workspace's webhook endpoint id to fire message.received events to on receipt — a bound endpoint receives them even if not subscribed, but must be active and match this address's livemode (test-mode addresses bind test-mode endpoints). When unset, events fan out to every active endpoint subscribed to message.received in the address's mode.

Output Schema

Name	Required	Description
`id`	Yes	Inbound address id (e.g. "inb_…").
`active`	Yes	Whether the address currently receives mail.
`address`	Yes	The full receiving address, e.g. support@acme.in.senderkit.email.
`livemode`	Yes	Live-mode address (true) or test-mode (false).
`createdAt`	Yes	When the address was created.
`forwardTo`	Yes	Address received mail is also forwarded to, or null.
`description`	Yes	Internal note, or null.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutation/safety profile is covered. The description adds genuine behavioral context beyond that: it enforces the workspace's plan limit and validates forwardTo/webhookEndpointId, which tells the agent this call can fail on quota or bad input. It stops short of describing what an exceeded-limit failure looks like.

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?

Two sentences with zero filler, and the core action is front-loaded before the constraint/validation note. Every clause carries information an agent needs.

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?

An output schema exists so return values need not be explained, and all 7 parameters are fully documented in the schema. The description is adequate for the call, though a mutation tool that consumes a plan-limit quota could say what happens on limit exhaustion or whether the address is usable immediately.

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 every parameter (livemode semantics, catch-all '*', mail-loop constraint on forwardTo, endpoint binding) is already documented in the schema. The description adds essentially nothing new about parameters beyond flagging that forwardTo/webhookEndpointId are validated, so the baseline 3 applies.

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 ('Create a new inbound email address') plus the two core behaviors of the created object (receives mail, optionally forwards/webhooks). An agent can tell it apart from the list/delete inbound_addresses siblings without opening any schema.

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

Usage Guidelines3/5

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

The description implies when it applies (minting a receiving address for the workspace) and notes a prerequisite — the plan limit is enforced — but it never states when to prefer this over related tools such as senderkit_inbound_domains_create, nor any explicit when-not condition. Usage is inferable but not spelled out.

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