Nevent MCP

nevent_send_test_template

Destructive

Send a test email of the template to one or more email addresses via SES. Use after nevent_preview_template validates rendering. Test emails carry test indicators in headers and are sent via AWS SES. This call may take up to 60 seconds due to SES delivery. Returns success status, list of recipients the email was sent to, and any error details. Pass campaign_id to send the test as that campaign will go out (its sender, sender name and reply-to); without it the test uses the organization's default sender.

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": {
      "template_id": "<template_id>",
      "emails": "<emails>"
    },
    "name": "nevent_send_test_template"
  }
}

Input Schema

Name	Required	Description
`emails`	Yes	List of email addresses to send the test email to. Each entry must be a valid email address. Minimum 1, maximum 10 recipients. Example: ["qa@example.com", "dev@company.com"].
`subject`	No	Optional subject line for the test email. Omit to use the default subject from the template.
`parameters`	No	Optional custom parameters for merge-tag substitution in the test email. Key-value pairs where keys match merge tag names. Example: {name: "Juan", city: "Madrid"}. When provided, overrides sample user profile data for the corresponding tags.
`campaign_id`	No	Optional campaign ID: send the test as that campaign will be sent (its sender, its own sender name and reply-to address). Omit to send it with the organization's default sender.
`template_id`	Yes	The ID of the email template to send as a test. Use nevent_list_templates to discover valid template IDs.
`sample_user_id`	No	Optional user ID for merge-tag personalization in the test email. When provided, {{name}}, {{email}} and custom fields are resolved from this user's profile. Takes priority over sample_user_email.
`sample_user_email`	No	Optional user email within the active tenant for merge-tag personalization. Ignored when sample_user_id is also provided.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / campaign_id

Added value: +{
+  "description": "Optional campaign ID: send the test as that campaign will be sent (its sender, its own sender name and reply-to address). Omit to send it with the organization's default sender.",
+  "maxLength": 64,
+  "minLength": 1,
+  "type": "string"
+}

First observedSep 1, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already mark this as a non-read-only, open-world operation, and the description adds real context beyond them: test indicators in headers, delivery via AWS SES, and a latency warning of up to 60 seconds. It also discloses the return payload (success status, recipient list, error details), though it does not explain why destructiveHint is set.

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?

Front-loaded with the purpose, then proceeds to preconditions, side effects, latency and return values in a logical order. Minor redundancy between 'via SES' and 'are sent via AWS SES' costs a little efficiency.

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?

Despite no output schema, the description covers what is returned, how long the call may take, how headers are modified, and how sender identity is resolved. For a seven-parameter tool with nested parameters, nothing essential is missing.

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 seven parameters are already well documented in the schema with examples and constraints. The description restates the campaign_id behavior (inherits sender, sender name, reply-to) rather than adding new meaning, so it does not exceed the baseline for a fully documented schema.

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 ('Send a test email of the template') plus the delivery channel and scope ('one or more email addresses via SES'). This clearly separates it from sibling tools like nevent_preview_template, nevent_create_template and nevent_schedule_campaign.

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?

Explicitly sequences the tool after nevent_preview_template ('Use after nevent_preview_template validates rendering') and explains the campaign_id versus default-sender choice. It stops short of stating when not to use it or naming alternatives such as scheduling an actual campaign.

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

All Nevent MCP tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.