Argorant

Send a test email

argorant_send_test_email

Destructive

Send one test of a campaign email to the user's own inbox, so they can see how it reads. Use it before a launch to check the text, variables and signature; nobody is added, nothing is scheduled and the campaign does not start, while argorant_launch_campaign sends to the campaign's people. It goes only to the user's own address (the default) or to a member of their workspace, never to anyone else, and at most 10 an hour. Pick the email with step, or test your own subject and body. It is sent from one of the campaign's mailboxes that can send, or from sender, and the variables are filled from a contact of the campaign or from sample. The answer says which mailbox sent it and who got it. More in the docs at https://docs.argorant.com/docs/agents/tools#campaigns

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": {
      "campaign_id": "<campaign_id>"
    },
    "name": "argorant_send_test_email"
  }
}

Input Schema

Name	Required	Description
`to`	No	Leave it out to send it to the user. Otherwise a member of their workspace.
`body`	No	Test this text instead of a campaign email.
`step`	No	Which email of the campaign, 1 for the first.
`sample`	No	Fields of a made-up contact, such as first_name and company, to fill the email with.
`sender`	No	A mailbox of the workspace that can send. Leave it out to use one of the campaign's.
`subject`	No	Test this subject instead of the campaign email's own.
`campaign_id`	Yes	The campaign's id, from argorant_list_campaigns.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnly=false, destructive=true, openWorld=true; the description adds the substance: no leads are added, nothing is scheduled, the campaign does not start, recipients are restricted, and there is a rate limit of at most 10 per hour. It also states the response content ('which mailbox sent it and who got it'), which annotations cannot convey.

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?

Purpose and the launch_campaign contrast are front-loaded, and each subsequent sentence carries a distinct constraint (recipients, rate limit, selection mode, sender, variables, response). It is a single dense paragraph with a docs link at the end, so scanning is slightly harder than a bulleted equivalent, but no sentence is filler.

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?

For a mutation tool with seven parameters, an output schema and annotations, everything an agent needs to call it safely is present: recipient scope, rate limit, sender resolution, variable sourcing, and confirmation that no campaign state changes. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns one more by explaining the mutual alternatives the schema lists separately ('Pick the email with step, or test your own subject and body') and the defaults for sender ('one of the campaign's mailboxes that can send') and variables ('from a contact of the campaign or from sample'). It does not address what happens if step and body are both supplied, which keeps it below 5.

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 test of a campaign email to the user's own inbox') and immediately scopes what it is not: 'the campaign does not start, while argorant_launch_campaign sends to the campaign's people.' An agent can distinguish this from the launch and send-path siblings without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('Use it before a launch to check the text, variables and signature') and names the alternative it should be preferred over, argorant_launch_campaign. The recipient restriction ('only the user's own address ... or a member of their workspace, never anyone else') further bounds correct usage.

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

All Argorant 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.