Skip to main content
Glama
Achlesha

sendhustle-mcp

by Achlesha
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

create_campaign

Create a campaign targeting a sending domain's contact pool, configuring subject, content, segments, A/B tests, follow-ups, and recurrence for later sending.

Instructions

Create a campaign targeting a sending domain's contact pool (POST /campaigns, domain-first). Send it later with send_campaign.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromNoSender, e.g. "Acme <hi@yourdomain.com>". Defaults to the configured sender.
htmlNo
nameNoInternal name for the campaign.
textNo
domainYesThe sending domain whose contacts this campaign targets, e.g. 'yourdomain.com'. Orthogonal to `from` — the from address may be a different verified domain.
ab_testNoA/B test config, e.g. { enabled: true, subject_b, test_pct, metric: 'open'|'click'|'reply', eval_hours: 1-168 }. eval_hours sets how long to run the test before evaluating and sending the winner.
list_toNoShow a generated mailing-list address (recipient-<hex>@your-domain) as the visible To; delivery stays individual.
subjectYesSubject line.
reply_toNo
topic_idNoGate recipients by a topic subscription.
followupsNoEngagement follow-ups (max 5): [{ condition: opened|clicked|not_opened|not_clicked|replied|not_replied, delay: '5 hours', subject?, html }] — sent after the campaign finishes, threaded as replies.
recurrenceNoMake this a recurring campaign.
segment_idNoTarget a segment (subset of the audience).
preview_textNo
recurrence_everyNoPeriods between recurring sends (1-365). Defaults to 1.
unsubscribe_policyNoHow the unsubscribe list applies: 'account' (default), 'domain' (only this sending domain's opt-outs block), 'ignore' (opt-outs skipped; bounces/complaints always excluded).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals that creation is separate from sending and that campaigns target a domain's contact pool, but it omits other significant behaviors such as whether the domain must be verified, whether the campaign is created as a draft, what side effects occur, and what the response contains.

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?

Two sentences with no filler; the core action is front-loaded, and the pointer to send_campaign earns its place. Every word adds value.

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?

The tool is complex (16 parameters, nested objects, no output schema, no annotations), yet the description is only two sentences. It does not tell the agent what the API returns (e.g., campaign ID), mention any prerequisites (e.g., verified domain), or outline the broader campaign lifecycle beyond a single pointer to send_campaign. This is inadequate for the tool's complexity.

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 75%, so the schema already documents most parameters in detail. The description adds little beyond the 'domain-first' hint, which is largely redundant with the domain parameter's schema description. It does not compensate for the roughly 25% of undocumented parameters (e.g., html, text, reply_to, preview_text).

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 ('Create') and resource ('campaign'), and scopes it to 'a sending domain's contact pool,' which clearly differentiates it from related tools like send_campaign. The endpoint hint (POST /campaigns) and 'domain-first' add further precision.

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 routes the follow-up action to send_campaign ('Send it later with send_campaign'), giving the agent a clear division of labor between creating and sending. It does not mention alternatives like update_campaign, but the lifecycle clue is sufficient for the most important distinction.

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

Deploy Server

Other Tools