Provides tools for interacting with the Mailchimp Marketing API, enabling management of audiences, subscribers, email templates, and the creation, scheduling, and sending of email campaigns.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mailchimp-mcp list my recent email campaigns"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Mailchimp Marketing API. Create campaigns, manage audiences, send emails, and handle subscribers.
Tool | Description |
| List all audiences/lists |
| List email templates |
| List recent campaigns |
| Get campaign details |
| Create a new email campaign |
| Set HTML/template content for a campaign |
| Get current campaign content |
| Send a test email before full send |
| Send a campaign to its audience |
| Schedule a campaign for future send |
| List subscribers in an audience |
| Add or update a subscriber (upsert) |
| Bulk add up to 500 subscribers |
Related MCP server: Mailchimp MCP Server
Install dependencies:
npm installCopy .env.example to .env and fill in your API key:
cp .env.example .envRequired environment variables:
MAILCHIMP_API_KEY - Your Mailchimp API key (format: key-dc, e.g. abc123-us21)
Add to your Claude Code MCP config (~/.claude.json):
{
"mcpServers": {
"mailchimp": {
"command": "node",
"args": ["/path/to/mailchimp-mcp/server.js"],
"env": {
"MAILCHIMP_API_KEY": "your-api-key-us21"
}
}
}
}MIT
Add a new subscriber or update an existing one in a Mailchimp audience. Uses email as the unique key (upsert). Will not change subscription status of existing members.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Audience/list ID | |
| Yes | Email address of the contact | ||
| first_name | No | First name | |
| last_name | No | Last name | |
| tags | No | Tags to apply (e.g. ['Lead', 'Strategy']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains the upsert behavior ('Uses email as the unique key'), clarifies what changes are made (adding/updating subscriber data), and specifies an important limitation ('Will not change subscription status of existing members'). This provides good transparency about how the tool operates, though it could mention potential side effects like email notifications or rate limits.
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 extremely concise and front-loaded, consisting of just two sentences that efficiently convey the core purpose, key mechanism, and critical limitation. Every word earns its place with no redundant information or unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description does well by explaining the upsert behavior and subscription status limitation. It provides enough context for basic usage, though it could benefit from mentioning what happens on success/failure or typical response structure. Given the 100% schema coverage for parameters, the description focuses appropriately on behavioral aspects rather than repeating parameter documentation.
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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter-specific information beyond implying that 'email' is used as the unique key for upsert operations. This meets the baseline expectation when schema coverage is high, but doesn't provide additional semantic context about parameter interactions or usage examples.
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 specific action ('Add a new subscriber or update an existing one'), the resource ('in a Mailchimp audience'), and the unique key mechanism ('Uses email as the unique key (upsert)'). It distinguishes itself from sibling tools like 'batch_add_members' by focusing on individual member operations rather than batch processing.
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 description provides clear context for when to use this tool ('Add a new subscriber or update an existing one') and includes an important behavioral constraint ('Will not change subscription status of existing members'), which helps differentiate it from potential alternatives. However, it does not explicitly mention when not to use it or name specific sibling alternatives beyond the implied distinction with 'batch_add_members'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add multiple subscribers to a Mailchimp audience in one call. Handles up to 500 members per batch. Will not overwrite existing members' subscription status.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Audience/list ID | |
| members | Yes | Array of contacts to add (max 500) | |
| update_existing | No | Update merge fields for existing members (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: the 500-member limit, non-destructive behavior regarding existing subscription status, and the fact that it's a batch operation. However, it doesn't mention authentication requirements, rate limits, or error handling.
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 perfectly concise with two sentences that each earn their place: the first establishes purpose and scope, the second provides important behavioral constraints. No wasted words, well front-loaded with essential information.
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 mutation tool with no annotations and no output schema, the description does well by covering purpose, constraints, and key behavior. However, it doesn't mention what the tool returns (success/failure indicators, error responses) or provide complete parameter guidance beyond what the schema offers, leaving some gaps for an AI agent.
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?
With 100% schema description coverage, the baseline is 3. The description adds some context about the 'members' parameter ('up to 500 members per batch') and implies behavior for 'update_existing' ('Will not overwrite existing members' subscription status'), but doesn't provide significant additional meaning beyond what the schema already documents.
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 specific action ('Add multiple subscribers'), resource ('to a Mailchimp audience'), and scope ('in one call'), distinguishing it from the sibling 'add_or_update_member' which handles individual members rather than batches.
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 description provides clear context for when to use this tool (batch operations up to 500 members) and implicitly suggests an alternative (the sibling 'add_or_update_member' for individual operations), but doesn't explicitly state when NOT to use it or compare directly with other batch alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Mailchimp email campaign. Returns the campaign ID for use with set_campaign_content and send_campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Audience/list ID (get from list_audiences) | |
| subject_line | Yes | Email subject line | |
| from_name | Yes | Sender name shown to recipients | |
| reply_to | Yes | Reply-to email address | |
| type | No | Campaign type (default: regular) | |
| preview_text | No | Preview text shown in inbox | |
| title | No | Internal campaign title (for your reference) | |
| segment_id | No | Segment ID to send to a subset of the audience |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool 'Returns the campaign ID for use with set_campaign_content and send_campaign,' which adds some behavioral context about the output and workflow. However, it lacks details on permissions, rate limits, or other behavioral traits like whether creation is reversible or has side effects, which is a significant gap for a mutation tool.
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 two sentences, front-loaded with the core action and followed by a concise note on the return value and usage. Every sentence earns its place by providing essential information without waste, making it highly efficient.
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?
Given the complexity of a campaign creation tool with 8 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the purpose and hints at the output but lacks details on behavioral aspects like permissions or error handling, leaving gaps that could hinder an AI agent's understanding.
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?
Schema description coverage is 100%, meaning all parameters are documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining the significance of 'type' or 'segment_id.' Thus, it meets the baseline of 3 but doesn't compensate with extra semantic value.
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 action ('Create a new Mailchimp email campaign') and resource ('Mailchimp email campaign'), making the purpose explicit. However, it doesn't differentiate from sibling tools like 'schedule_campaign' or 'send_campaign' beyond mentioning that the returned ID is used with them, which is helpful but not a full distinction.
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 description implies usage by stating that the returned campaign ID is for use with 'set_campaign_content' and 'send_campaign', suggesting a workflow. However, it doesn't explicitly say when to use this tool versus alternatives like 'schedule_campaign' or provide exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific campaign by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | The campaign ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get details' implies a read-only operation, it doesn't specify permissions required, rate limits, error handling, or response format. This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence with zero wasted words. It's front-loaded with the core purpose ('Get details of a specific campaign by ID'), making it immediately clear and appropriately sized for its function.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned, error conditions, or behavioral traits like authentication needs. For a tool with no structured data beyond the input schema, more context is needed to be fully helpful.
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 description adds minimal value beyond the input schema, which has 100% coverage and clearly documents the 'campaign_id' parameter. It implies the tool retrieves details for a single campaign but doesn't provide additional context like ID format or examples, meeting the baseline for high schema coverage.
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 action ('Get details') and resource ('specific campaign by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_campaigns' or 'get_campaign_content', which would require explicit comparison to achieve a perfect score.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_campaigns' for multiple campaigns or 'get_campaign_content' for content-specific details, nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current HTML and plain-text content of a campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't cover other traits like authentication needs, rate limits, error conditions, or what the response format looks like (e.g., structure of returned content). This leaves significant gaps for a tool that retrieves data.
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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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?
Given the tool's moderate complexity (retrieving content for a campaign), lack of annotations, and no output schema, the description is minimally adequate. It specifies what content is retrieved (HTML and plain-text) but omits details like response structure, error handling, or dependencies, which could hinder effective use by an agent.
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 has 100% description coverage, with the single parameter 'campaign_id' documented as 'Campaign ID'. The description doesn't add any meaning beyond this (e.g., explaining what a campaign ID is or where to find it), so it meets the baseline score of 3 where the schema does the heavy lifting.
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 verb ('Get') and resource ('current HTML and plain-text content of a campaign'), making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'get_campaign' or 'set_campaign_content', which could cause confusion about when to use each.
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 description provides no guidance on when to use this tool versus alternatives like 'get_campaign' (which might return metadata) or 'set_campaign_content' (for updating content). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Mailchimp audiences/lists. Returns list IDs needed for campaign creation.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results to return (default 10, max 1000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists audiences and returns list IDs, but lacks details on permissions required, pagination behavior, error handling, or rate limits. For a read operation without annotations, this leaves significant gaps in understanding how the tool behaves in practice.
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 extremely concise—two short sentences that directly state the tool's function and a key use case. Every word earns its place, with no redundant or vague phrasing, making it easy to parse quickly.
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?
Given the tool's low complexity (one optional parameter) and high schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it fails to explain the structure of returned data (e.g., what fields besides IDs are included) or behavioral aspects like error conditions, leaving room for improvement in completeness.
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 has 100% description coverage, with the 'count' parameter clearly documented in the schema itself. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 where the schema does the heavy lifting.
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 action ('List all Mailchimp audiences/lists') and resource ('audiences/lists'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other list operations like 'list_campaigns' or 'list_members' beyond mentioning the specific resource type.
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 description mentions that returned list IDs are 'needed for campaign creation,' which provides some context about downstream use. However, it offers no explicit guidance on when to use this tool versus alternatives like 'list_members' or 'list_campaigns,' nor does it specify prerequisites or constraints beyond the implicit listing function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent Mailchimp campaigns.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (default 10) | |
| status | No | Filter by status: save, paused, schedule, sending, sent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, it doesn't explicitly state whether this is safe, whether it requires authentication, what rate limits apply, or what happens with errors. The description mentions 'recent' campaigns but doesn't define what 'recent' means or if there are time-based limitations.
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 extremely concise at just 4 words, with zero wasted language. It's front-loaded with the core purpose and includes the scope modifier 'recent' as the only additional detail. Every word earns its place, making this highly efficient communication.
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 read operation with 2 parameters and no output schema, the description is insufficiently complete. It doesn't explain what information is returned about campaigns, whether results are paginated, what 'recent' means operationally, or any error conditions. Without annotations or output schema, the description should provide more context about the tool's behavior and results.
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 has 100% description coverage, with clear documentation for both 'count' (default 10) and 'status' (filter options). The description adds no additional parameter information beyond what's already in the schema. This meets the baseline expectation when schema coverage is high, but doesn't provide extra value like explaining parameter interactions or edge cases.
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 action ('List') and resource ('Mailchimp campaigns'), making the purpose immediately understandable. It specifies 'recent' campaigns, which adds useful scope information. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_campaign' or 'list_audiences' beyond the resource type.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'list_campaigns' over 'get_campaign' (for individual details) or 'list_audiences' (for different resources). There's also no information about prerequisites, dependencies, or typical use cases for listing campaigns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List members/subscribers in a Mailchimp audience. Use for syncing or auditing contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Audience/list ID | |
| count | No | Number of results (default 100, max 1000) | |
| offset | No | Offset for pagination (default 0) | |
| status | No | Filter by status: subscribed, unsubscribed, cleaned, pending, transactional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('List') and hints at use cases, but doesn't detail permissions, rate limits, pagination behavior beyond schema hints, or what the output looks like. It adds some context but lacks comprehensive behavioral traits needed for a tool with no annotation support.
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 extremely concise—two short sentences with zero waste. It front-loads the core purpose and follows with usage context, making it easy to parse quickly without unnecessary elaboration.
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?
Given no annotations and no output schema, the description is somewhat incomplete for a tool with 4 parameters. It covers purpose and usage but lacks details on behavioral aspects like error handling, output format, or advanced filtering. It's minimally viable but has clear gaps in contextual information.
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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain 'list_id' further or provide examples). Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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 verb ('List') and resource ('members/subscribers in a Mailchimp audience'), making the purpose specific and understandable. It distinguishes from siblings like 'list_audiences' by focusing on members within an audience, though it doesn't explicitly contrast with other member-related tools like 'add_or_update_member' or 'batch_add_members'.
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 description provides clear context for when to use this tool ('for syncing or auditing contacts'), which helps differentiate it from write operations. However, it doesn't explicitly state when NOT to use it (e.g., vs. 'list_audiences' for audience metadata) or name specific alternatives among siblings, leaving some ambiguity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Mailchimp email templates.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (default 10) | |
| type | No | Filter by type: user, base, gallery |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation but doesn't describe what 'available' means (e.g., accessible templates vs all templates), whether there are permission requirements, pagination behavior, rate limits, or what the return format looks like. The description provides minimal behavioral context beyond the basic operation.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and gets straight to the point without unnecessary elaboration.
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 read-only list operation with 2 documented parameters and no output schema, the description is minimally adequate. It identifies the resource but doesn't provide enough context about what 'available' means, return format, or behavioral constraints. Without annotations or output schema, the agent lacks important operational details.
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 schema description coverage is 100%, so the schema already documents both parameters with their types and descriptions. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
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 verb ('List') and resource ('Mailchimp email templates'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other list_* siblings like list_audiences or list_campaigns beyond specifying the resource type.
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 description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus other list_* tools, or any exclusions. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a campaign to send at a specific time in the future.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign ID | |
| schedule_time | Yes | UTC send time in ISO 8601 format (e.g. 2026-03-01T14:00:00Z) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool schedules for future sending but lacks critical behavioral details: whether scheduling is reversible, permission requirements, rate limits, error conditions (e.g., invalid time), or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste. It is front-loaded with the core action and resource, making it easy to parse quickly.
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?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., idempotency, side effects), usage prerequisites, and expected outcomes, which are essential for safe and effective tool invocation.
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?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional parameter semantics beyond implying temporal scheduling, which is already covered by the schema's 'schedule_time' description. Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('Schedule') and resource ('a campaign'), specifying the temporal aspect ('to send at a specific time in the future'). It distinguishes from immediate sending tools like 'send_campaign' but doesn't explicitly differentiate from other scheduling-related siblings (none listed).
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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., campaign must exist, be in draft state), exclusions (e.g., cannot schedule past campaigns), or comparisons with siblings like 'send_campaign' for immediate sending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a campaign to its audience. This action is irreversible — the campaign will be sent immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign ID to send |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses that the action is irreversible and executes immediately. This goes beyond the basic 'send' action, informing the agent about critical consequences, though it could mention permissions or rate limits for a higher score.
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 two sentences with zero waste: the first states the action, and the second adds crucial behavioral context. It's front-loaded and appropriately sized, earning its place efficiently.
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 mutation tool with no annotations and no output schema, the description is adequate but has gaps: it covers the irreversible nature but doesn't mention response format, error conditions, or prerequisites. Given the complexity, it's minimally viable but not 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?
Schema description coverage is 100%, so the schema already documents the 'campaign_id' parameter fully. The description doesn't add any parameter-specific details beyond what the schema provides, meeting the baseline of 3 for high schema coverage without extra value.
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 action ('send') and resource ('campaign to its audience'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'schedule_campaign' or 'send_test_email', which would require a 5.
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 description implies usage by stating the action is irreversible and immediate, suggesting it should be used when ready to send. However, it doesn't explicitly mention when to use alternatives like 'schedule_campaign' for delayed sending or 'send_test_email' for testing, leaving some guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a test email for a campaign before sending to the full audience.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign ID | |
| test_emails | Yes | Array of email addresses to send the test to | |
| send_type | No | Send as HTML or plaintext (default: html) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether this requires specific permissions, if it's idempotent, what happens on failure, or any rate limits. The description only states the basic action without operational context.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 mutation tool (sending emails) with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, side effects, or how it interacts with campaign state. More context is needed given the tool's complexity.
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?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying 'campaign_id' and 'test_emails' are needed for the test send, which is already clear from the schema. Baseline 3 is appropriate.
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 action ('send a test email') and resource ('for a campaign'), specifying it's for testing before full audience sending. It distinguishes from siblings like 'send_campaign' by focusing on test functionality, though it doesn't explicitly name alternatives.
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 description implies usage context ('before sending to the full audience'), suggesting this tool is for pre-launch validation. However, it doesn't explicitly state when to use this versus 'send_campaign' or other campaign-related tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the HTML/plain-text content for a campaign. Provide either html for custom content or template_id to use a Mailchimp template.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign ID | |
| html | No | Full HTML content for the email | |
| plain_text | No | Plain text version of the email | |
| template_id | No | Mailchimp template ID to use instead of raw HTML |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('Set') but doesn't disclose behavioral traits such as required permissions, whether changes are reversible, rate limits, or what happens to existing content. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that front-loads the purpose and key usage note. Every word earns its place, with no waste or redundancy, making it highly concise and well-structured.
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?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like permissions, side effects, and response format, which are crucial for safe and effective use. The description should do more to compensate for the missing structured data.
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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds marginal value by clarifying the choice between 'html' and 'template_id', but it doesn't provide additional syntax or format details beyond what the schema offers. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Set') and resource ('HTML/plain-text content for a campaign'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_campaign' or 'get_campaign_content', which would require more context about when to use each.
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 description implies usage by mentioning alternatives ('either html for custom content or template_id to use a Mailchimp template'), but it doesn't explicitly state when to use this tool versus others like 'create_campaign' or 'schedule_campaign'. No exclusions or prerequisites are provided, leaving gaps in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_or_update_memberbatch_add_memberscreate_campaignget_campaignget_campaign_contentlist_audienceslist_campaignslist_memberslist_templatesschedule_campaignsend_campaignsend_test_emailset_campaign_contentEach tool has a clearly distinct purpose with no overlap: member management, campaign operations, audience listing, and template handling are all well-separated. For example, add_or_update_member and batch_add_members serve different use cases (single vs. bulk), and campaign tools like create_campaign, send_campaign, and schedule_campaign cover distinct lifecycle stages.
Tool names follow a highly consistent verb_noun pattern throughout, such as list_audiences, create_campaign, get_campaign, and send_campaign. All tools use snake_case with clear, descriptive verbs that align with their actions, making the set predictable and easy to navigate.
With 13 tools, the count is well-scoped for a Mailchimp integration, covering core operations like audience management, campaign creation, sending, and content handling. Each tool earns its place by addressing specific needs without redundancy, fitting typical MCP server ranges for this domain.
The tool surface provides comprehensive coverage for Mailchimp's key workflows, including CRUD-like operations for campaigns and members, listing resources, and campaign lifecycle management. A minor gap exists in missing update/delete operations for campaigns or members, but agents can work around this with existing tools like add_or_update_member for updates.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Mailchimp MCP Pack — manage audiences, campaigns, and members via Mailchimp Marketing API.
The first MCP server for physical mail: send postcards and letters, manage lists and campaigns.
An MCP server to send personalised direct mail.
Send transactional email and manage domains, audiences, and broadcasts from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dazanza/mailchimp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
