What can you do with this server?

This MCP server provides email marketing automation tools for managing contacts, lists, campaigns, newsletters, analytics, and email sending. * Manage contact lists: create, list, and retrieve paginated contact lists. * Manage contacts: create single or batch contacts, get contacts with filters, retrieve individual contacts, and unsubscribe contacts. * Import contacts from inline CSV with explicit column mappings, with preview/commit modes. * Export contacts as CSV pages with metadata and formula escaping. * Create and manage email campaigns: create safe drafts, list campaigns, and retrieve campaign status. * Create and manage reusable newsletters, schedule future editions, pause future deliveries, and view newsletter metrics. * Send individual emails with HTML content, templates, scheduling, CC/BCC, and provider options. * Retrieve analytics: campaign metrics (opens, clicks, bounces, unsubscribes) and audience metrics. * Access marketing options: audiences, templates, starter designs, and sender IDs (without passwords). * All operations respect resource permissions and support read-only and delivery-affecting annotations. * Supports both hosted HTTPS (Streamable HTTP) and local stdio via npm, with API key or JWT authentication.

How do I use XEM Email MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@XEM Email MCP Server Send an email to hello@example.com with the subject 'Meeting Invitation'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

XEM Email MCP Server

by mailxem

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Xem MCP server

Connect an MCP client to Xem for newsletter drafts and schedules, campaigns, analytics, contact lists, and CSV imports/exports. Supports hosted HTTPS (Streamable HTTP) and npm-based local stdio.

Connect over HTTPS (hosted)

Use a client that supports Streamable HTTP and custom Authorization headers:

{
  "mcpServers": {
    "xem": {
      "url": "https://mcp.xem.email/mcp",
      "headers": { "Authorization": "Bearer your-workspace-api-key" }
    }
  }
}

This is API-key authentication, not an OAuth login flow. Clients that only support OAuth must use local stdio instead. Use your client's secret store where available. Each request validates the supplied Xem API key and creates an isolated protocol server and API client. No shared service key, sessions, or cross-client state. Revoked and expired keys are rejected on the next request. Tool endpoints enforce resource permissions independently. The hosted URL becomes available after the Compose deployment below.

Related MCP server: SMTP MCP Server

Local stdio through npm

Requires Node.js 20 or newer. After publishing this 2.x release, configure:

{
  "mcpServers": {
    "xem": {
      "command": "npx",
      "args": ["-y", "@xem.email/mcp@2", "--stdio"],
      "env": { "XEM_API_KEY": "your-workspace-api-key" }
    }
  }
}

Alternatively install npm install -g @xem.email/mcp@2 and use xem-email-mcp --stdio. To work from source, run npm ci && npm run build and launch node /absolute/path/to/mcp/build/index.js --stdio.

XEM_API_KEY uses the upstream X-API-Key header. In stdio mode only, XEM_API_TOKEN can supply a JWT bearer token; the API key wins if both exist. XEM_API_BASE_URL defaults to https://api.xem.email/api/v1. HTTPS is required except on loopback for development. Redirects are rejected. Credentials and workspace IDs cannot be supplied as tool arguments.

Host with Docker Compose

Deploy the accompanying Xem API changes first, including /api/v1/mcp/authorize, the batch-contact endpoint and campaign-draft endpoint.
Point mcp.xem.email (or your own hostname) at the Docker host. Allow incoming TCP ports 80 and 443 for Caddy's certificates and HTTPS. These ports must be available.
Set MCP_DOMAIN and XEM_API_BASE_URL in .env if overriding defaults. Do not set a shared XEM_API_KEY or XEM_API_TOKEN for the hosted service.
After the first successful container workflow, run:

docker compose pull
docker compose up -d
docker compose ps
curl --fail https://mcp.xem.email/health

Caddy provisions and renews TLS certificates; keep the caddy_data volume across upgrades. Only Caddy publishes ports. The MCP container runs as an unprivileged user with a read-only filesystem and resource limits. It uses a 2 MiB request limit, per-key rate limits (120 requests/minute per process), and a 128-request concurrency cap. Add an edge rate limiter for large public deployments. Native clients may omit Origin; browser clients must match the public origin or an explicit comma-separated XEM_MCP_ALLOWED_ORIGINS allowlist. Cookies and forwarded host headers are not used for authentication.

The HTTP service is stateless: POST /mcp; GET/DELETE return 405. /health checks process health, not API availability. For an end-to-end check, connect with a restricted test key and call get_contact_lists. Read/write behavior and key revocation are covered by integration tests. No real contacts or mail are used in tests.

For an existing TLS proxy, run xem-email-mcp --http, set HOST, PORT, XEM_MCP_PUBLIC_URL, and proxy /mcp while preserving Host and Authorization. Keep the backend on a private network. All incoming API keys go only to the fixed, operator-configured Xem API base URL; never use a user-selected upstream.

Container builds in GitHub Actions

.github/workflows/container.yml runs package tests, validates Compose, builds the image, and smoke-tests its health and authentication checks on pull requests. It publishes only from this repository's main branch or version tags, after validation succeeds. Manual runs can publish from main or a version tag too.

Images are pushed to ghcr.io/mailxem/mcp for both linux/amd64 and linux/arm64, with an SBOM and build provenance:

main: the current successful main-branch build (Compose default).
v2.0.0: a release tag; the tag must match the package version.
sha-<full-commit-sha>: a build identified by its source commit.

The workflow summary provides a digest for reproducible deployments. Set MCP_IMAGE=ghcr.io/mailxem/mcp@sha256:... in .env, then run docker compose pull && docker compose up -d. Keep the previous digest to roll back by changing MCP_IMAGE and running those commands again. Publishing an image does not automatically restart your production service.

Publishing uses the repository's GITHUB_TOKEN with job-scoped packages:write; no Docker Hub secret is needed. After the first publish, make the GHCR package public in its package settings for unauthenticated pulls, or authenticate the deployment host with a read-only package credential. Organization package policies may require an administrator to grant publishing access. This workflow does not publish the npm package.

For local development, build directly with docker build -t xem-mcp:local ., then use MCP_IMAGE=xem-mcp:local docker compose up -d without pulling. Actions are pinned to commit SHAs and Dependabot proposes updates weekly.

Tools

Tools	Behavior
`get_marketing_options`	Audiences, templates, starter designs and sender IDs without sender passwords
`get_contact_lists`, `create_contact_list`	Paginated lists and empty list creation
`get_contacts`, `get_contact`	Paginated contacts with optional list, email and status filters; individual lookup
`create_contact`, `add_contacts`	Create one contact or an atomic batch; batch defaults to preview
`import_contacts`	Inline CSV, explicit column mapping, preview by default
`export_contacts_csv`	One page of CSV with page/total/hasMore metadata and formula escaping
`unsubscribe_contact`	Suppress an active contact, preserving existing bounce/complaint suppression
`create_campaign`, `get_campaigns`, `get_campaign`	Safe campaign drafts and status lookup
`get_campaign_metrics`, `get_audience_metrics`	Opens, clicks, accepted messages, bounces, unsubscribes and rates
`create_newsletter`, `get_newsletters`	Reusable draft newsletters; listing capped at 200
`schedule_newsletter`, `pause_newsletter`	Activate delivery on an explicit future schedule, or pause future editions
`get_newsletter_metrics`	Delivery counts for the latest 50 editions; use edition IDs for campaign engagement metrics
`send_email`	Queue an authorized individual email

Campaign drafts require templateId, listId, and smtpConfigId from your workspace. Creating a draft never sends. Newsletter scheduling replaces its configuration: supply all required fields, including cadence, timezone, future nextSendAt and sender postal address. Pausing does not cancel editions already materialized. Analytics default to the last 30 calendar days; to is exclusive and ranges are limited to 366 days. SMTP acceptance does not guarantee inbox placement; opens and clicks may include automated activity.

CSV import

{
  "listId": "11111111-1111-4111-8111-111111111111",
  "csv": "Email Address,Given Name,Company\nada@example.com,Ada,Acme\n",
  "mappings": { "email": "Email Address", "firstName": "Given Name", "company": "Company" },
  "dryRun": true
}

Mapping direction is contact field → CSV header. Supported fields: email (required), firstName, lastName, phone, company, country, city. Unmapped columns are ignored. Each request accepts at most 500 rows / 1 MiB. All rows must validate before anything is written. Preview returns wouldCreate, skipped and total; repeat the input with dryRun:false to commit. Counts are recalculated on commit. Each batch is atomic; split larger datasets into batches. Existing addresses in the list, including deleted or suppressed contacts, are skipped and never reactivated. No remote URLs, local file paths, or uploaded file IDs are accepted. Export returns one page at a time to the MCP client; increment page while hasMore is true. Data may change between pages.

Permissions and security

Grant only needed resources: lists:read/create, contacts:read/create, campaigns:read/create, analytics:read, and emails:create. The options tool additionally requires templates:read and smtp_configs:read. A resource's create grant also permits reads; admin grants are supported. Scheduling requires campaign write access and validates the template, audience, sender, TLS support and postal address server-side.

The MCP host controls user approval. Tool annotations identify read-only and delivery-affecting operations, but they are hints, not authorization. Contact data returned by tools is visible to the client; configure that client's data policies appropriately. Upstream API requests time out after 30 seconds, responses are capped at 2 MiB, upstream error bodies are redacted, and writes are never retried automatically. After a timeout, inspect server state before retrying. Batch contact inserts skip existing addresses.

Migration from 1.x

This is a breaking 2.0 release. Remove token/teamId tool arguments and --token/--team-id CLI flags; use environment configuration. Pagination starts at 1. create_campaign uses htmlBody and requires template/audience/sender IDs; it creates drafts only. create_contact takes {listId, contact}; add_contacts takes {listId, contacts, dryRun}. CSV import now accepts inline CSV and field-to-header mappings instead of fileId. Contact name becomes firstName/lastName. Email data is a key/value object. Deploy the accompanying server changes before using this MCP release.

Development

npm test
npm audit

Tests use a mock HTTP transport and do not send email or change real contacts.

Release order

Deploy the matching Xem API, launch and verify the Compose service, then publish this package with npm publish --access public and deploy the website. Version 2.0 is breaking; do not direct users to the old 1.x package for these tools. Run npm pack --dry-run before publishing.

Dashboard assistant tools

The catalog now includes 42 tools: existing campaign/audience/newsletter operations plus templates and starter import, draft signup forms, contact notes/stages/tags, automation inspection/pause, outbox history, and managed-sending readiness/domain checks/pause. All inputs reject workspace overrides. New writes are annotated for client review; the dashboard stages every write before approval.

Managed-sending tools require a current admin-bound Xem assistant credential. Ordinary API keys remain denied by those backend routes. The catalog deliberately does not expose credential issuance, billing, team administration or operator approval. Upgrade the backend with its assistant credential support before using these tools. This change does not deploy the hosted MCP or publish an npm release.

Available Tools

7 tools

add_contactsC

Add contacts to a mailing list.

ParametersJSON Schema

Name	Required	Description
`token`	No	XEM Email API authentication token (optional if set via environment variable)
`listId`	Yes	ID of the mailing list to add contacts to
`contacts`	Yes	Array of contact objects to add
`teamId`	No	Team ID (optional if set via environment variable)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool adds contacts but doesn't mention important behavioral aspects like whether this is a write operation (implied but not explicit), what happens on duplicate contacts, permission requirements, rate limits, or error handling. The description is too minimal 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?

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for the tool's complexity and gets straight to the point without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after adding contacts, what the return value might be, or important behavioral constraints. The agent would need to guess about success/failure responses and operational details.

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 the schema fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate schema coverage.

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?

The description clearly states the action ('Add contacts') and the target resource ('to a mailing list'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'import_contacts' or 'create_contact_list', which appear to have related functionality for contact management.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'import_contacts' or 'create_contact_list'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with minimal context for tool selection.

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

create_campaignC

Create an email campaign that can be sent to a contact list.

ParametersJSON Schema

Name	Required	Description
`token`	No	XEM Email API authentication token (optional if set via environment variable)
`name`	Yes	Campaign name
`subject`	Yes	Email subject line
`html`	No	HTML content of the campaign email
`templateId`	No	Template ID to use for the campaign
`listId`	Yes	Mailing list ID to send the campaign to
`scheduleAt`	No	ISO 8601 timestamp to schedule the campaign
`teamId`	No	Team ID (optional if set via environment variable)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether creation is immediate or draft-based, if it requires specific permissions, rate limits, or what happens after creation (e.g., campaign status). This leaves significant gaps 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?

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the resource and target.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral context, return values, error conditions, or integration with sibling tools, leaving the agent with incomplete operational understanding.

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 the schema fully documents all 8 parameters. The description adds no parameter-specific information beyond implying 'listId' is for targeting, which is already clear in the schema. Baseline 3 is appropriate as the schema handles parameter semantics adequately.

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?

The description clearly states the verb 'create' and resource 'email campaign', specifying it can be sent to a contact list. It distinguishes from siblings like 'send_email' by focusing on campaign creation rather than immediate sending, though it doesn't explicitly contrast with all siblings.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites, when not to use it, or how it differs from similar tools like 'send_email' or campaign-related operations that might exist elsewhere.

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

create_contact_listC

Create a new contact list for organizing email recipients.

ParametersJSON Schema

Name	Required	Description
`token`	No	XEM Email API authentication token (optional if set via environment variable)
`name`	Yes	Name of the contact list
`description`	No	Description of the contact list
`teamId`	No	Team ID (optional if set via environment variable)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creation but doesn't cover important aspects like required permissions, whether the operation is idempotent, error handling, or what happens on success (e.g., returns a list ID). This leaves significant gaps for an agent to understand the tool's behavior.

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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a creation operation with 4 parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances, leaving the agent with incomplete context for proper invocation.

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?

The input schema has 100% description coverage, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying 'name' and 'description' fields, which are already covered. This meets the baseline for high schema coverage.

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?

The description clearly states the action ('Create a new contact list') and purpose ('for organizing email recipients'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_contact_lists' or 'import_contacts', which would be needed for a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'import_contacts' or 'add_contacts', nor does it mention prerequisites such as authentication or team context. It simply states what the tool does without contextual usage instructions.

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

get_contact_listsC

Get all contact lists for a team.

ParametersJSON Schema

Name	Required	Description
`token`	No	XEM Email API authentication token (optional if set via environment variable)
`teamId`	No	Team ID (optional if set via environment variable)
`page`	No	Page number for pagination
`limit`	No	Number of items per page

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get all contact lists' but does not specify if this is a read-only operation, how pagination works with the 'page' and 'limit' parameters, or any rate limits or authentication requirements beyond what the schema implies. This leaves significant gaps in understanding the tool's behavior.

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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It does not address behavioral aspects like pagination behavior, authentication needs, or what the return values might be, leaving the agent with insufficient context for effective use.

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 the schema fully documents all four parameters. The description adds no additional meaning beyond the schema, such as explaining how 'teamId' relates to the contact lists or the implications of pagination. Baseline 3 is appropriate as the schema handles the heavy lifting.

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?

The description clearly states the verb 'Get' and the resource 'all contact lists for a team', which specifies what the tool does. However, it does not differentiate from sibling tools like 'get_contacts' or 'create_contact_list', which handle related but distinct operations, leaving room for improvement in distinguishing its specific scope.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'get_contacts' or 'create_contact_list'. It lacks context on prerequisites, exclusions, or specific scenarios, offering minimal help for an agent to choose between sibling tools.

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

get_contactsC

Get contacts from a specific mailing list.

ParametersJSON Schema

Name	Required	Description
`token`	No	XEM Email API authentication token (optional if set via environment variable)
`listId`	Yes	ID of the mailing list
`teamId`	No	Team ID (optional if set via environment variable)
`page`	No	Page number for pagination
`limit`	No	Number of items per page

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden but lacks behavioral details. It doesn't disclose that this is a read-only operation (implied by 'Get'), pagination behavior (though schema hints at it), authentication requirements (token/teamId optionality), rate limits, or error handling. For a tool with 5 parameters and no annotations, this is a significant gap in transparency.

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?

The description is a single, efficient sentence that front-loads the core action ('Get contacts') and resource ('from a specific mailing list'). There is no wasted verbiage, making it easy to parse quickly while conveying essential purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't address return values, error conditions, pagination details, or authentication context. For a data retrieval tool with multiple optional parameters, more guidance is needed to help the agent use it effectively.

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 the schema fully documents all parameters. The description adds no additional meaning beyond implying 'listId' is required and that contacts are retrieved from it. It doesn't explain parameter interactions or usage nuances, so it meets the baseline for high schema coverage without compensating value.

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?

The description clearly states the verb 'Get' and resource 'contacts from a specific mailing list', making the purpose understandable. It distinguishes from siblings like 'add_contacts' or 'get_contact_lists' by focusing on retrieving contacts from a particular list, though it doesn't explicitly contrast with 'import_contacts' or 'get_contact_lists' which handle different aspects of contact management.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing a mailing list ID, compare it to sibling tools like 'get_contact_lists' for listing lists instead of contacts, or specify use cases such as retrieving contacts for email campaigns. This leaves the agent without context for tool selection.

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

import_contactsC

Import contacts from a CSV file to a mailing list using file upload.

ParametersJSON Schema

Name	Required	Description
`token`	No	XEM Email API authentication token (optional if set via environment variable)
`listId`	Yes	ID of the mailing list to import contacts to
`fileId`	Yes	File ID from a previous file upload
`mappings`	Yes	Field mappings for CSV columns (e.g., {"name": "name", "email": "email"})
`teamId`	No	Team ID (optional if set via environment variable)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Import contacts') but lacks details on permissions required, whether it's idempotent, potential side effects (e.g., overwriting existing contacts), or error handling. This is a significant gap for a tool that performs data import operations.

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?

The description is a single, efficient sentence that front-loads the core action and resources. Every word contributes directly to understanding the tool's purpose without any redundancy or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of importing contacts (a mutation operation with 5 parameters, nested objects, and no output schema), the description is inadequate. It lacks details on behavioral traits, output expectations, and differentiation from siblings, making it incomplete for safe and effective use by an AI agent.

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?

The schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the CSV format or mapping nuances. This meets the baseline for high schema coverage.

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?

The description clearly states the action ('Import contacts') and resources involved ('from a CSV file to a mailing list using file upload'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'add_contacts' or 'create_contact_list', which might have overlapping functionality.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'add_contacts' or 'create_contact_list'. The description mentions the method ('using file upload') but doesn't specify prerequisites, such as needing a pre-uploaded file, or when not to use it, leaving the agent to infer usage from context alone.

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

send_emailC

Send an email using the XEM Email API. Supports HTML content, templates, scheduling, and multiple recipients.

ParametersJSON Schema

Name	Required	Description	Default
`token`	No	XEM Email API authentication token (optional if set via environment variable)
`to`	Yes	Recipient email address
`subject`	Yes	Email subject line
`html`	No	HTML content of the email (optional if using templateId)
`cc`	No	CC email addresses (comma-separated)
`bcc`	No	BCC email addresses (comma-separated)
`replyTo`	No	Reply-to email address
`templateId`	No	Template ID to use for the email
`scheduleAt`	No	ISO 8601 timestamp to schedule the email
`provider`	No	Email provider (default: CUSTOM)	CUSTOM
`test`	No	Whether this is a test email
`data`	No	Additional data array

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions capabilities like scheduling and multiple recipients but lacks critical details: whether this is a mutation (likely yes, but not stated), authentication requirements beyond the token parameter, rate limits, error handling, or what happens on success/failure. For a 12-parameter tool with potential side effects, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is a single, efficient sentence that lists key capabilities without redundancy. It's appropriately sized and front-loaded with the core purpose, though it could be slightly more structured (e.g., separating core function from features).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like mutation effects, authentication, error cases, or return values, leaving significant gaps for an agent to understand tool usage fully.

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 the schema fully documents all 12 parameters. The description adds minimal value beyond the schema by mentioning HTML content, templates, scheduling, and multiple recipients—which are already covered in parameter descriptions (e.g., html, templateId, scheduleAt, to/cc/bcc). Baseline 3 is appropriate as the schema does the heavy lifting.

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?

The description clearly states the action ('send an email') and resource ('using the XEM Email API'), with specific capabilities listed (HTML content, templates, scheduling, multiple recipients). However, it doesn't explicitly differentiate this email-sending tool from sibling tools like create_campaign, which might also involve email functionality.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like create_campaign or other email-related tools. It mentions capabilities but doesn't specify use cases, prerequisites, or exclusions, leaving the agent without contextual decision-making help.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.0.0Jan 31, 2026
- First observedadd_contacts
- First observedcreate_campaign
- First observedcreate_contact_list
- First observedget_contact_lists
- First observedget_contacts
- First observedimport_contacts
- First observedsend_email

Deploy Server

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

TDQS

A3.5/5.0

Scored 2026-04-18 06:21 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: add_contacts and import_contacts both add contacts but differ in method (manual vs. file upload), create_campaign and send_email handle campaign creation vs. direct sending, and contact list management tools are well-separated. An agent can easily distinguish between them based on their specific functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as add_contacts, create_campaign, and get_contact_lists. This uniformity makes the tool set predictable and easy for an agent to parse, with no deviations in naming conventions.

Tool Count5/5

With 7 tools, the server is well-scoped for email marketing and contact management, covering core operations like contact handling, list management, campaign creation, and sending. Each tool serves a distinct and necessary function, avoiding bloat while providing comprehensive coverage for the domain.

Completeness4/5

The tool set covers most essential email marketing workflows, including contact management, list operations, campaign creation, and sending. However, minor gaps exist, such as the lack of tools for updating or deleting contacts, campaigns, or lists, which agents might need to work around for full lifecycle management.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

sendgrid A
io.usefulapi
Send email and read templates, marketing contacts, lists, stats, bounces and unsubscribes.
Email Marketing
112
MisarMail MCP Server A
io.github.Misar-AI
Send transactional email, run campaigns, manage contacts and automations, audit deliverability.
Email Marketing
5421
postmark
com.mcparmory
Send, track, and manage transactional and bulk email delivery
Email Marketing App Automation
2
send16-mcp B
io.github.spruikco
Email for AI agents: send mail, manage contacts, automations & webhooks. Zero-DNS first send.
Email App Automation
792

Related MCP Servers

SendGrid MCP Server
Marketing Communication
Garoth
A
license
B
quality
F
maintenance
Provides an interface to manage email marketing, contact lists, dynamic templates, and email analytics via SendGrid's API.
Updated 2 years ago (2025-02-25 23:45 UTC)
21
286 npm
30
ISC
SMTP MCP Server
Communication Marketing
samihalawa
A
license
A
quality
A
maintenance
Enables sending emails via SMTP with template management, supporting multiple SMTP configurations, template creation with variable substitution, and bulk email sending with rate limiting.
Updated 18 days ago (2026-08-31 21:26 UTC)
6
215 npm
19
MIT
SendGrid MCP Server
Marketing Communication
deyikong
A
license
B
quality
A
maintenance
Enables comprehensive email marketing and transactional email operations through SendGrid's API v3. Supports contact management, campaign creation, email automation, list management, and email sending with built-in read-only safety mode.
Updated a day ago (2026-09-17 17:12 UTC)
58
286 npm
3
ISC
Email Send/Receive MCP Server
Communication App Automation Workplace & Productivity
bedro96
A
license
Not graded
quality
D
maintenance
Enables sending and receiving emails through SMTP, IMAP, and POP3 protocols with support for attachments, HTML content, and email validation.
Updated 3 months ago (2026-06-17 13:09 UTC)
MIT