Side-by-side comparison of two or more campaigns. Shows performance metrics, scores, grades, identifies the winner for each metric, and provides recommendations based on what worked best.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | MailerCloud API key | |
| campaign_ids | Yes | Two or more campaign IDs to compare,required | |
| cost_per_email | No | Optional cost per email in dollars for cost-per-open and cost-per-click calculations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful context by enumerating the kinds of results returned, which matters because there is no output schema. It does not describe any side effects, but none are expected given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core purpose and then enumerates the key outputs. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a comparison tool with safety annotations and schema-documented parameters, this description is largely complete. It explains the output composition, which is valuable since there is no output schema. Adding explicit guidance about when to prefer this over analyze_campaign or analyze_latest_campaigns would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents campaign_ids and cost_per_email with 100% coverage, so the baseline of 3 applies. The description adds no parameter-specific meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does side-by-side comparison of two or more campaigns and specifies what it produces: performance metrics, scores, grades, per-metric winners, and recommendations. This distinctively separates it from sibling tools like analyze_campaign or get_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is clear: comparing multiple campaigns and identifying which performed best per metric. However, it does not explicitly mention when not to use it or name alternative tools, such as analyze_campaign for a single-campaign deep dive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tool purposes are largely distinct, with clear separation between CRUD operations, analytics, and deliverability tools. Some overlap exists between get_campaign, analyze_campaign, and campaign_health_dashboard, but descriptions clarify scope sufficiently.
Most tools follow a consistent verb_noun pattern (list_, get_, create_, update_, delete_, send_). Minor exceptions like campaign_health_dashboard and engagement_funnel are descriptive but break the pattern.
With 47 tools, this is a very large surface area. While the variety reflects the breadth of email marketing operations, the count exceeds what is typically manageable and suggests potential redundancy or over-scoping.
The tool set covers most core workflows: contact/list management, campaign lifecycle, templates, webhooks, analytics, and transactional email. Minor gaps like no delete for templates or tags are acceptable but not fatal.
