remove_email_domainRemove a sending domain by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Domain ID (from list_email_domains) |
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Confirmation that the domain was removed. Senders on that domain can no longer send. | |
| success | Yes | True when the call succeeded. A failure comes back as an error result instead. |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "description": "Confirmation that the domain was removed. Senders on that domain can no longer send."
+ },
+ "success": {
+ "description": "True when the call succeeded. A failure comes back as an error result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the destructiveHint annotation and adds that the target is a sending domain identified by ID. It does not disclose whether the action is irreversible or whether it has side effects on related resources, but the destructiveHint annotation already communicates the core destructive nature. The description contributes modest context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundancy. It conveys the action, target, and identification method in the fewest possible words while remaining clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive operation with an output schema and destructiveHint annotation, the description is nearly complete: it names the action, target, and how to identify the domain. It could briefly note irreversibility or effects, but the low complexity and existing schema/annotation coverage make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter, id, with the description 'Domain ID (from list_email_domains),' achieving 100% coverage. The tool description does not add meaning beyond the schema beyond restating 'by ID.' Baseline 3 is appropriate because the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Remove a sending domain by ID.' It is specific enough to be understood as a deletion action and the 'sending domain' qualifier helps distinguish it from generic remove_domain. However, it does not explicitly contrast it with related domain tools like remove_domain or verify_email_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only names the action and the ID parameter, leaving the agent to infer that it should be used whenever a sending domain needs removal. No alternative tools or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.