mailchimp-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mailchimp-mcp MCP server](https://glama.ai/mcp/servers/dazanza/mailchimp-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dazanza/mailchimp-mcp)

Score Badge

Copy to your README.md:

[![mailchimp-mcp MCP server](https://glama.ai/mcp/servers/dazanza/mailchimp-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dazanza/mailchimp-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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