DirectIQ

directiq_send_email

Send one transactional email (a receipt, confirmation, or one-to-one message) immediately. It is delivered to real recipients and cannot be recalled, and it counts toward the account’s sending plan. The from address must be a confirmed sender on the account (see directiq_account_overview). Not for bulk marketing: campaigns are sent from the DirectIQ dashboard.

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": {
      "from": "<from>",
      "to": "<to>",
      "subject": "<subject>",
      "content": "<content>"
    },
    "name": "directiq_send_email"
  }
}

Input Schema

Name	Required	Description
`cc`	No	CC recipient addresses
`to`	Yes	Recipient email address
`bcc`	No	BCC recipient addresses
`from`	Yes	Sender address; must be a confirmed sender on the account
`content`	Yes	Message body as HTML or plain text, at least 2 characters
`subject`	Yes	Subject line, at least 2 characters
`fromName`	No	Sender display name, e.g. "Acme Support"

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 29, 2026

changedInput schema / properties / bcc / description

Previous value: -"BCC recipients"New value: +"BCC recipient addresses"

addedInput schema / properties / bcc / items / pattern

Added value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

changedInput schema / properties / cc / description

Previous value: -"CC recipients"New value: +"CC recipient addresses"

addedInput schema / properties / cc / items / pattern

Added value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

changedInput schema / properties / content / description

Previous value: -"Email body (HTML or text, min 2 characters)"New value: +"Message body as HTML or plain text, at least 2 characters"

changedInput schema / properties / from / description

Previous value: -"Sender email address (must be a confirmed sender)"New value: +"Sender address; must be a confirmed sender on the account"

addedInput schema / properties / from / pattern

Added value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

changedInput schema / properties / fromName / description

Previous value: -"Sender display name"New value: +"Sender display name, e.g. \"Acme Support\""

changedInput schema / properties / subject / description

Previous value: -"Email subject (min 2 characters)"New value: +"Subject line, at least 2 characters"

addedInput schema / properties / to / pattern

Added value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: annotations only say non-read-only and non-idempotent, while the description discloses that messages go to real recipients in the open world, cannot be recalled, and consume the account's sending quota. It also flags the confirmed-sender authorization requirement, which is exactly the kind of operational constraint an agent cannot infer from schema alone.

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?

Four short sentences, front-loaded with the action and its irreversibility, followed by the prerequisite and the exclusion. Each sentence carries a distinct decision-relevant fact, with no restatement of the name or schema.

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?

High-risk side effects, quota impact, and the authorization prerequisite are all covered, and the exclusion correctly routes bulk senders away. The one gap is that with no output schema, the description does not indicate what a successful call returns (e.g., a message ID or status) that an agent might want to log or verify.

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 (from, to, cc, bcc, subject, content, fromName) are already documented with format patterns and minLengths. The description only restates the confirmed-sender constraint on 'from', which the schema literally repeats, so it adds no syntax or selection meaning beyond structured data. Baseline 3 applies.

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 transactional email') and immediately scopes it with concrete examples (receipt, confirmation, one-to-one message). It also draws a hard boundary against bulk marketing campaigns, which none of the sibling tools cover, so an agent can identify this unambiguously.

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?

Provides positive conditions (transactional/bulk-free messaging), an explicit exclusion ('Not for bulk marketing: campaigns are sent from the DirectIQ dashboard'), and a prerequisite pointing to the sibling tool directiq_account_overview to verify the sender. Nothing about when-to-use is left to inference.

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

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