Skip to main content
Glama
Sign In
mx-route-mcp

mx-route-mcp

by MauiGrowth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create email account

create_email_account

Create an MXroute email mailbox for a domain, setting its password, storage quota, and daily send limit. The password is sent to MXroute and never returned.

Instructions

Creates a mailbox such as username@domain. The password is sent to MXroute and never shown in the result. Defaults when omitted: 1024 MB quota, 9600 emails/day send limit.

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>",
      "username": "<username>",
      "password": "<password>"
    },
    "name": "create_email_account"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoDaily send limit, maximum 9600 (API default 9600)
quotaNoStorage quota in MB; 0 means unlimited (API default 1024)
domainYesDomain name on the MXroute account, e.g. example.com
passwordYes8-72 characters; must also satisfy the mail server's character and strength rules
usernameYesMailbox name to create (the part before the @, without the domain)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare the write/non-destructive/openWorld/idempotent profile, but the description adds genuinely useful context beyond them: the password is transmitted to MXroute and never surfaced in the result, plus concrete defaults for quota and daily send limit when fields are omitted. It stops short of noting that the password is unrecoverable afterward or what the result contains.

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 short sentences, front-loaded with the action, then the critical password behavior, then the defaults. No filler and nothing important buried at the end.

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?

For a mutation tool whose annotations cover the safety profile and whose schema is fully described, the description is nearly complete, and it even clarifies output behavior (password withheld). It leaves out prerequisites such as an existing domain and any authentication context, which openWorldHint implies but does not spell out.

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 all five parameters are already documented, including the 1024 MB and 9600 defaults. The description's defaults sentence largely repeats what the schema descriptions already state, so it adds little beyond the baseline.

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?

States a specific verb+resource ('Creates a mailbox') and clarifies the resulting identifier format with `username@domain`. It's clearly distinguishable from delete/get/list email account siblings, though it never explicitly names an alternative like update_email_account or create_forwarder.

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?

Usage is only implied by the verb: use this when you want a new mailbox. There is no explicit when-to-use/when-not guidance, no prerequisite note (e.g., domain must already exist), and no pointer to a sibling for related operations.

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

Deploy Server

Other Tools