Skip to main content
Glama
Sign In

Nitrosend

by com.nitrosend
OverviewDiscussionsAdmin

nitro_send_test_message

DestructiveIdempotent

Send one real email/SMS test. Never approves or sends to an audience. Flows require an exact revision. Success confirms the mail provider accepted the send. Confirm receipt before approving; it does not prove inbox placement.

Input Schema

NameRequiredDescriptionDefault
toNoEmail addresses or SMS E.164 numbers.
dataNoSample email data.* values.
channelNoPrefer auto.auto
dry_runNoValidate without sending.
action_idNoSelect a flow message step.
target_idNo
contact_idNoRecipient and personalization.
event_dataNoSample email event.* data; no Event/Order writes.
revision_idNoExact revision; required for flows.
target_typeNoWith target_id, or use template_id/latest_campaign.
template_idNoTemplate id; may select a flow/campaign email.
idempotency_keyNoRequired to send; exact retries only.
latest_campaignNoLatest campaign in this brand.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • changedInput schema / properties / action_id / description
      Previous value: -"For a flow with multiple message steps."New value: +"Select a flow message step."
    • changedInput schema / properties / channel / description
      Previous value: -"Use auto unless a standalone template is ambiguous."New value: +"Prefer auto."
    • changedInput schema / properties / contact_id / description
      Previous value: -"Supplies the recipient and merge-tag personalization."New value: +"Recipient and personalization."
    • changedInput schema / properties / data / description
      Previous value: -"Sample values for required data.* merge fields in an email test."New value: +"Sample email data.* values."
    • changedInput schema / properties / dry_run / description
      Previous value: -"Validate target and recipients without sending."New value: +"Validate without sending."
    • addedInput schema / properties / event_data
      Added value: +{
+  "description": "Sample email event.* data; no Event/Order writes.",
+  "type": "object"
+}
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Required for live test sends; reuse only for an exact retry."New value: +"Required to send; exact retries only."
    • changedInput schema / properties / latest_campaign / description
      Previous value: -"Most recently created campaign in this brand."New value: +"Latest campaign in this brand."
    • changedInput schema / properties / revision_id / description
      Previous value: -"Required for flow targets: the exact flow revision."New value: +"Exact revision; required for flows."
    • changedInput schema / properties / target_type / description
      Previous value: -"Use with target_id unless latest_campaign or template_id is used."New value: +"With target_id, or use template_id/latest_campaign."
    • changedInput schema / properties / template_id / description
      Previous value: -"Template to test directly, or the specific flow/campaign template to choose."New value: +"Template id; may select a flow/campaign email."
    • changedInput schema / properties / to / description
      Previous value: -"Email addresses, or E.164 phone numbers for SMS."New value: +"Email addresses or SMS E.164 numbers."
  2. Changed9 schema fields changed
    • changedInput schema / properties / action_id / description
      Previous value: -"Flow action ID to test when a flow has multiple message steps."New value: +"For a flow with multiple message steps."
    • changedInput schema / properties / channel / description
      Previous value: -"Channel to test. Use auto unless a standalone template is ambiguous."New value: +"Use auto unless a standalone template is ambiguous."
    • changedInput schema / properties / contact_id / description
      Previous value: -"Contact ID for recipient and merge-tag personalization. If present, this contact supplies the recipient address/phone."New value: +"Supplies the recipient and merge-tag personalization."
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Required for live test sends. Reuse the same stable key on retry to prevent duplicate delivery."New value: +"Required for live test sends; reuse only for an exact retry."
    • changedInput schema / properties / latest_campaign / description
      Previous value: -"Use the most recently created campaign in this brand."New value: +"Most recently created campaign in this brand."
    • changedInput schema / properties / revision_id / description
      Previous value: -"Required for flow targets. Exact immutable flow revision to test."New value: +"Required for flow targets: the exact flow revision."
    • removedInput schema / properties / target_id / description
      Removed value: -"Target entity ID. Use with target_type."
    • changedInput schema / properties / target_type / description
      Previous value: -"Target entity type. Use with target_id unless latest_campaign or template_id is used."New value: +"Use with target_id unless latest_campaign or template_id is used."
    • changedInput schema / properties / to / description
      Previous value: -"Explicit test recipients. Use email addresses for email targets and E.164 phone numbers for SMS targets."New value: +"Email addresses, or E.164 phone numbers for SMS."
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true; the description goes further by defining what a success response actually means ('the mail provider accepted the send') and its limits ('does not prove inbox placement'). That is exactly the kind of caveat an agent needs before treating a test send as proof of deliverability.

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?

Four short sentences, front-loaded with the scope constraint and free of filler. It is telegraphic to the point that 'Confirm receipt before approving' depends on the reader already knowing the approval workflow context.

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 13-parameter, mutation-capable tool with no output schema, the description covers what success means and what it does not prove, which substitutes well for a missing return-value spec. It leaves ambiguous how to combine the multiple alternative recipient/target selectors, which is the main remaining gap.

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 coverage is 92%, so nearly every parameter is already documented, and the description's only parameter-adjacent statement ('Flows require an exact revision') restates the revision_id description. With the schema doing the heavy lifting across 13 parameters, the description adds no additional selection logic for the overlapping target_type/target_id/template_id/latest_campaign selectors.

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 one real email/SMS test') and immediately bounds the scope ('Never approves or sends to an audience'), which separates it cleanly from nitro_send_message. An agent can pick between the two without opening either schema.

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?

'Never approves or sends to an audience' plus 'Confirm receipt before approving' gives clear context that this is a pre-approval verification step, and 'Flows require an exact revision' states a prerequisite. It stops short of naming nitro_send_message as the alternative for real audience sends, so routing is implied rather than explicit.

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

All Nitrosend toolsInspect
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.

Resources