Provides comprehensive management of Brevo email marketing platform, including campaign creation and sending, test emails, analytics, contact segmentation, transactional emails, template management, and automation features.
Click on "Deploy 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., "@Brevo MCP Server Create an email campaign for our weekly newsletter"
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 (Model Context Protocol) server for Brevo email marketing platform with comprehensive campaign management, analytics, and automation capabilities.
Create sophisticated email campaigns with A/B testing and segmentation
Update campaign content, recipients, and scheduling
Send campaigns immediately or schedule for optimal times
Test campaigns using pre-configured test lists before full send
Control campaign status (pause, resume, archive, replicate)
Share campaign templates via unique URLs
Campaign Performance - Open rates, click rates, bounce analysis
Contact Engagement - Track subscriber behaviour and preferences
Comparative Analysis - Benchmark campaigns against industry averages
Real-time Insights - AI-powered recommendations for improvement
Recipient-level Data - Granular tracking of individual interactions
Transactional Emails - Send personalised emails via API
Template Management - Use and share email templates
Contact Segmentation - Target specific audience groups
Smart Send Times - Optimise delivery for maximum engagement
UTM Tracking - Integrate with analytics platforms
Test List Integration - Safe testing workflow with pre-configured test lists
IP Warmup - Gradually increase sending volume
A/B Testing - Test subject lines and content variations (Business/Enterprise plans only)
Best Time Sending - AI-optimised send times per recipient
List Management - Include/exclude lists dynamically
Bulk Operations - Handle thousands of contacts efficiently
Related MCP server: ActiveCampaign MCP Server
Setup Test List in Brevo
Configure your test list in Brevo Settings
Add test email addresses to the list
This is a one-time setup
Create Campaign
Use: create_email_campaign
- Set name, subject
- Add HTML content or template
- Configure recipient lists
- Sender auto-detected (or specify custom)Test Campaign
Use: send_test_email
- Provide only campaignId
- Automatically sends to your test list
- Review the test emailUpdate if Needed
Use: update_email_campaign
- Modify content, subject, etc.
- Re-test as neededSend Campaign
Use: send_campaign_now
- Sends to all configured recipients
- Or schedule with scheduledAt parameterTest List: The MCP assumes you have a pre-configured test list in Brevo
send_test_email: By default sends to your test list (omit emailTo parameter)
Safety: Always test before sending to actual recipients
No Duplicate: The duplicate campaign feature is not available in Brevo API
Install via npm:
npm install -g @houtini/brevo-mcpConfigure Claude Desktop:
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"brevo": {
"command": "npx",
"args": ["-y", "@houtini/brevo-mcp"],
"env": {
"BREVO_API_KEY": "your-brevo-api-key-here"
}
}
}
}Restart Claude Desktop
Clone this repository:
git clone https://github.com/houtini-ai/brevo-mcp.git
cd brevo-mcp
npm install
npm run buildAdd to Claude Desktop config:
{
"mcpServers": {
"brevo": {
"command": "node",
"args": ["C:/path/to/brevo-mcp/dist/index.js"],
"env": {
"BREVO_API_KEY": "your-brevo-api-key-here"
}
}
}
}BREVO_API_KEY - Your standard Brevo v3 API key (required)
Must be the standard API key that starts with xkeysib-
Found in Brevo Dashboard → Settings → API Keys
Note: MCP-specific API keys will be supported in a future release
BREVO_BASE_URL - Custom API base URL (optional, defaults to https://api.brevo.com/v3)
Log in to your Brevo account
Go to Settings → API Keys
Use the Standard API Key (not the MCP API key)
The standard v3 API key starts with xkeysib-
MCP API key support coming in a future release
Create a new API key or copy an existing one
Important: You may need to whitelist your IP address in Brevo's security settings
The MCP automatically detects and uses your verified sender, making campaign creation simpler and safer:
Auto-detection: If no sender is specified, the MCP automatically uses your verified sender from existing campaigns
Smart fallback: Checks sent campaigns first, then draft campaigns if needed
Safety first: All test emails use the verified sender to prevent delivery issues
// Option 1: Auto-detect sender (RECOMMENDED)
create_email_campaign({
name: "My Campaign",
subject: "Hello World",
htmlContent: "<h1>Content</h1>"
// No sender needed - uses verified sender automatically
})
// Option 2: Specify sender by ID (for specific IP pools)
create_email_campaign({
name: "My Campaign",
subject: "Hello World",
htmlContent: "<h1>Content</h1>",
sender: {
name: "Custom Name",
id: 2 // Your sender ID from Brevo
}
})
// Option 3: Specify sender by email (must be verified)
create_email_campaign({
name: "My Campaign",
subject: "Hello World",
htmlContent: "<h1>Content</h1>",
sender: {
name: "Custom Name",
email: "verified@yourdomain.com"
}
})To find your sender ID, check any existing campaign:
get_email_campaigns({ limit: 1 })
// Response includes: sender: { id: 2, email: "...", name: "..." }Verified senders only: Email addresses must be verified in Brevo before use
Test emails: Always sent from the verified sender for reliability
IP Pools: Use sender ID (not email) if you have dedicated IP pools
First-time setup: Create at least one campaign in Brevo dashboard to establish a verified sender
Once configured, try these commands to get started:
Check your setup: "Show my Brevo account info"
View campaigns: "List my email campaigns"
Create a campaign: "Create a new email campaign called 'Newsletter'"
Send a test: "Send a test email for campaign ID 123"
Check performance: "Show analytics for my campaigns this week"
Manage campaigns: "Pause campaign ID 456"
The MCP server understands natural language, so you can phrase requests conversationally!
get_account_info - View account details, plan, credits, and features
get_contacts - List, search, and filter contacts with pagination
get_contact_analytics - Analyse contact engagement and activity history
create_email_campaign - Create campaigns with rich configuration options
HTML content, templates, or external URLs
List targeting with inclusion/exclusion rules
A/B testing and send time optimisation
Scheduling and automation triggers
update_email_campaign - Modify any aspect of existing campaigns
send_campaign_now - Send campaigns immediately to recipients
send_test_email - Test campaigns with specific email addresses
update_campaign_status - Control campaign state:
suspended - Pause sending
archive/darchive - Archive or restore
queued - Queue for sending
replicate - Create working copy
get_email_campaigns - List campaigns with filtering by status/type
get_campaign_analytics - Detailed metrics for specific campaigns:
Delivery, open, and click rates
Bounce and unsubscribe analysis
Geographic and device breakdowns
get_campaigns_performance - Compare multiple campaigns:
Performance scoring and ranking
Trend analysis over time
Top performer identification
get_analytics_summary - Comprehensive dashboard view:
Account-wide statistics
Period comparisons
AI-powered insights and recommendations
get_campaign_recipients - Recipient-level engagement data
send_email - Send individual transactional emails:
Template-based or custom HTML
Dynamic personalisation
Attachment support
Reply tracking
get_shared_template_url - Generate shareable template links
User: "Create a new email campaign for our Black Friday sale"
Assistant: "I'll create the Black Friday campaign. What's your sender email and target list?"
User: "Use marketing@company.com and send to list ID 5"
Assistant: [Creates campaign with professional template and scheduling options]User: "Update our newsletter campaign with new content"
Assistant: [Updates campaign content and configuration]
User: "Schedule it for next Tuesday at 10am"
Assistant: [Updates campaign with optimal send time]
User: "Send a test to team@company.com first"
Assistant: [Sends test email for review]User: "How are our email campaigns performing this quarter?"
Assistant: [Displays comprehensive metrics with trends and recommendations]
User: "Which campaigns had the best engagement?"
Assistant: [Shows top performers with detailed breakdowns]User: "Pause all active campaigns"
Assistant: [Updates status of all running campaigns]
User: "Create an A/B test for our welcome email"
Assistant: [Sets up split test with subject line variations - requires Business/Enterprise plan]When creating campaigns, you can specify:
Content Options
htmlContent - Direct HTML content
htmlUrl - URL to fetch HTML from
templateId - Use existing Brevo template
Recipient Configuration
listIds - Target specific lists
exclusionListIds - Exclude certain lists
segmentIds - Use dynamic segments
Advanced Features
scheduledAt - Schedule for specific time
sendAtBestTime - AI-optimised delivery
abTesting - Enable split testing (requires Business/Enterprise plan)
ipWarmupEnable - Gradual volume increase
utmCampaign - Analytics tracking
Control your campaigns with these status options:
suspended - Temporarily pause sending
archive - Move to archive (hidden from main view)
darchive - Restore from archive
queued - Add to send queue
sent - Mark as sent
replicate - Create editable copy
Available time ranges for analytics:
today - Current day statistics
yesterday - Previous day metrics
last7days - Week-to-date performance
last30days - Month-to-date analysis
custom - Specify exact date range
Track these key performance indicators:
Delivery Metrics: Sent, delivered, bounced
Engagement Metrics: Opens, clicks, forwards
List Health: Unsubscribes, complaints, list growth
Comparative Analysis: Industry benchmarks, trend analysis
Ensure Node.js 18+ is installed
Check the logs at: %APPDATA%\Claude\logs\mcp-server-brevo.log
The server starts without an API key but will prompt you when needed
Add the key to your Claude config and restart Claude Desktop
Ensure your IP is whitelisted in Brevo if you get authentication errors
401 Unauthorized: Check API key and IP whitelist in Brevo
429 Rate Limited: You've exceeded Brevo's API rate limits
404 Not Found: The resource doesn't exist or endpoint is incorrect
npm install
npm run build
npm test# Test without API key
npm test
# Test with API key
BREVO_API_KEY=your-key npm testMIT © Houtini Ltd
Issues: GitHub Issues
Email: brevo@houtini.ai
Documentation: Brevo API Docs
Create a new email campaign in Brevo
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Internal campaign name | |
| subject | Yes | Email subject line | |
| sender | No | Sender information (optional - defaults to verified sender from account) | |
| htmlContent | No | HTML content of the email | |
| htmlUrl | No | URL to fetch HTML content from | |
| templateId | No | ID of existing Brevo template to use | |
| listIds | No | List IDs to send campaign to | |
| exclusionListIds | No | List IDs to exclude from campaign | |
| segmentIds | No | Segment IDs to target | |
| type | No | Campaign type | classic |
| tag | No | Campaign tag for organization | |
| replyTo | No | Reply-to email address | |
| scheduledAt | No | ISO 8601 datetime to schedule campaign | |
| abTesting | No | Enable A/B testing | |
| sendAtBestTime | No | Enable send time optimization | |
| utmCampaign | No | UTM campaign parameter for tracking | |
| params | No | Template parameters if using templateId |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details such as required permissions, rate limits, or side effects. With no annotations, the description carries full burden but reveals nothing beyond the basic create 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 concise sentence with no fluff. However, for a complex tool with many parameters, a slightly more structured breakdown could be beneficial.
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 (17 parameters, nested objects, no output schema, no annotations), the description is insufficient. It does not explain return values, parameter dependencies, or default behaviors.
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?
All 17 parameters have descriptions in the schema (100% coverage), so the description adds no extra meaning beyond what is already in the schema. Baseline score of 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 (create) and resource (email campaign) within Brevo. It is unambiguous but does not differentiate from sibling tools like 'update_email_campaign' or 'send_campaign_now'.
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, nor any prerequisites or exclusions. The user must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Brevo account information including plan and credits
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it retrieves information, implying a read operation. No disclosure of side effects, rate limits, authentication needs, or other behavioral traits beyond the basic function.
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 sentence that is concise and front-loaded with the verb. Every word is necessary, and there is no waste.
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 simplicity (no parameters, no output schema), the description provides sufficient context by stating what information is retrieved (plan and credits). It is complete enough for an AI agent to understand the tool's function without needing additional 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?
No parameters exist in the input schema, so the baseline is 4. The description does not need to add parameter information as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Brevo account information, specifically mentioning plan and credits. The verb 'Get' and resource 'Brevo account information' are precise, and the tool is distinct from sibling tools that focus on campaigns, analytics, and contacts.
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 explicit guidance on when to use versus alternatives, but the purpose is straightforward and the siblings are unrelated domains. The description implies usage for retrieving account details without excluding any cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive analytics summary with insights
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time period for analytics | last7days |
| startDate | No | Custom start date (required if period is "custom") | |
| endDate | No | Custom end date (required if period is "custom") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only says 'Get comprehensive analytics summary with insights', which does not reveal whether it is read-only, what data is fetched, or any side effects. Transparency is minimal.
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 concise sentence with no wasted words, though the phrase 'with insights' is somewhat redundant. It is appropriately front-loaded.
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 tool with 3 parameters and no output schema, the description does not explain what the summary contains, the output format, or how it differs from other analytics tools. This is insufficient for an agent to correctly select and invoke the tool.
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 coverage is 100%, with all parameters having descriptions. The description adds no additional meaning beyond the schema, so a baseline score of 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 uses a specific verb 'get' and resource 'analytics summary', but it does not specify what type of analytics (campaign, contact, account) and does not distinguish from sibling tools like get_campaign_analytics or get_contact_analytics. The purpose is vague.
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 the many sibling analytics tools, nor any conditional or contextual advice. The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed analytics for a specific campaign including recipient-level data
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | ID of the campaign | |
| startDate | No | Start date for analytics (YYYY-MM-DD) | |
| endDate | No | End date for analytics (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the operation and data scope; it does not disclose behavioral traits like pagination, rate limits, error behavior, or data freshness. As a read operation, safety is implied but not stated.
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?
Single sentence, no unnecessary words, meaning is front-loaded. Could include additional structured info like usage context, but remains concise.
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?
With 3 parameters fully described in schema and no output schema, the description provides basic purpose but lacks return format, pagination, or error handling details. Adequate for a simple tool but not comprehensive.
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% (all parameters have descriptions in schema). Description adds 'recipient-level data' which hints at output granularity but does not significantly enhance parameter understanding. Baseline 3 applies.
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?
Description clearly states 'Get detailed analytics for a specific campaign' with 'recipient-level data', providing a specific verb and resource. However, it does not explicitly differentiate from sibling analytics tools like get_analytics_summary or get_campaigns_performance.
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 explicit guidance on when to use this tool versus alternatives. The description implies it is for detailed per-campaign analytics, but lacks when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recipient list for a specific campaign
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | ID of the campaign | |
| status | No | Filter by recipient status | |
| limit | No | Number of recipients to return | |
| offset | No | Number of recipients to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. 'Get' implies a read-only operation, which is correct, but there is no mention of error handling (e.g., invalid campaign ID), rate limits, or any side effects. The behavior is basic and transparent enough for a simple query, but lacks depth.
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 sentence of 6 words, conveying the essential purpose without any filler. Every word earns its place, achieving maximum conciseness.
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?
Despite having 4 parameters including pagination (limit, offset), the description does not explain that the results are paginated, what the output format looks like, or that status filtering is available. The tool has moderate complexity and no output schema, so the description should provide more context about the return structure and usage patterns.
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 covers 100% of parameters with descriptions. The description adds no new meaning beyond 'for a specific campaign', which reinforces the required campaignId but is already implicit in the schema. Baseline is 3 due to 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') and the resource ('recipient list for a specific campaign'). It distinguishes itself from sibling tools like 'get_email_campaigns' (which retrieves campaign metadata) and 'get_campaign_analytics' (which returns statistics).
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 gives no guidance on when to use this tool versus alternatives (e.g., when to use this over 'get_contacts' or 'get_email_campaigns'). There is no mention of prerequisites, such as requiring a valid campaign ID, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get performance metrics for multiple campaigns
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by campaign status | |
| startDate | No | Filter campaigns modified after this date | |
| endDate | No | Filter campaigns modified before this date | |
| limit | No | Maximum number of campaigns to analyze |
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 only states 'Get performance metrics' without disclosing read-only status, authentication requirements, rate limits, or what specific metrics are returned. This is insufficient for a data retrieval 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 a single concise sentence, front-loaded with key information. It efficiently communicates the tool's essence without unnecessary words, but could include more details without being verbose.
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?
With 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return format, pagination, or behavior for edge cases like missing dates or empty results, which is crucial for an agent to understand the tool's full capabilities.
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 baseline is 3. The description does not add any additional meaning beyond the schema; it merely repeats the resource name without clarifying parameter semantics.
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 the resource 'performance metrics for multiple campaigns', making the purpose obvious. However, it does not differentiate from the sibling tool 'get_campaign_analytics', which could be interpreted as similar.
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, no prerequisites, and no scenarios where it should not be used. This leaves the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analytics for contacts including engagement metrics
| Name | Required | Description | Default |
|---|---|---|---|
| No | Filter by specific email address | ||
| listId | No | Filter by list ID | |
| startDate | No | Start date for engagement data | |
| endDate | No | End date for engagement data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose key behaviors. It only states the tool 'gets analytics' but does not confirm it's read-only, mention rate limits, response size, or performance implications. Essential transparency is lacking.
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 concise sentence that front-loads the purpose. It is not verbose, but could be expanded slightly to improve completeness without sacrificing conciseness.
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 absence of an output schema and annotations, the description should provide richer context about return values, aggregation, and usage patterns. It falls short, lacking details on what engagement metrics are included or how filtering works.
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 coverage is 100% with descriptions on all four parameters. The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate. It does not elaborate on how parameters like startDate/endDate affect engagement metrics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves analytics for contacts, highlighting 'engagement metrics'. It distinguishes from sibling tools like get_campaign_analytics by specifying 'contacts' as the resource, though it could further differentiate from get_analytics_summary.
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 vs siblings such as get_analytics_summary. There is no mention of prerequisites, alternatives, or scenarios where other tools are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List contacts with optional filtering and pagination
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of contacts to return (default: 50, max: 1000) | |
| offset | No | Number of contacts to skip | |
| No | Filter by email address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It implies a read-only listing but does not mention side effects, authentication requirements, rate limits, or response structure.
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?
Single sentence, front-loaded with the main action, contains no superfluous 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?
Despite high schema coverage, the description lacks context on return format, pagination behavior beyond limit/offset, and typical use cases. Inadequate for a tool with no annotations or output schema.
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 coverage is 100%, so the schema already documents all parameters. The description adds no new meaning beyond 'optional filtering and pagination', which is present in the schema descriptions.
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'), resource ('contacts'), and includes key features ('optional filtering and pagination'), distinguishing it from sibling tools like 'get_contact_analytics'.
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 on when to use this tool versus alternatives. Sibling tools include contact-related options, but no explicit rationale for choosing 'get_contacts' over 'get_contact_analytics' or others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List email campaigns with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Campaign type filter | |
| status | No | Campaign status filter | |
| limit | No | Number of campaigns to return | |
| offset | No | Number of campaigns to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states the purpose and filtering, but does not disclose if it is read-only, if authentication is required, or how pagination works. The description adds minimal behavioral 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 very short at one sentence, which is concise. However, it could be expanded slightly to include more context without becoming verbose.
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 absence of annotations and output schema, the description should provide more context, such as pagination behavior, ordering, or that it returns a list. The current description is insufficient for a tool with 4 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all 4 parameters. The description does not add extra meaning beyond what is in the schema, so 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 verb 'list' and the resource 'email campaigns', and mentions filtering options. However, it does not differentiate from sibling tools like get_campaigns_performance or provide additional scope context.
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 given on when to use this tool versus alternatives like get_campaigns_performance or update_email_campaign. The description lacks any when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an email campaign immediately
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | ID of the campaign to send |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states immediacy, but no details on irreversible actions, permissions, or rate limits. For a sending action, more transparency is needed.
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?
Single sentence, front-loaded with key info. Could include more detail without being verbose, but acceptable for simple tool.
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?
Simple tool with one parameter. Minimal description is functional but lacks behavioral context (e.g., confirmation, retry behavior) that would aid agent safety.
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 coverage is 100% with clear description for campaignId. Description adds no extra meaning beyond schema, baseline score 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?
Clear action and resource: 'Send an email campaign immediately'. Distinguishes from siblings like send_email (individual) and update_campaign_status (scheduling), but does not explicitly state scope.
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 on when to use this tool versus alternatives like update_campaign_status or send_test_email. Lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a transactional email using Brevo
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Array of recipient objects with email and optional name | |
| subject | No | Email subject line | |
| htmlContent | No | HTML content of the email | |
| textContent | No | Plain text content of the email | |
| templateId | No | ID of Brevo template to use | |
| params | No | Template parameters | |
| from | No | Sender information | |
| replyTo | No | Reply-to address | |
| tags | No | Tags for the email |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as idempotency, rate limits, error handling, or side effects beyond stating the tool sends an email. For a tool with zero annotations, this is insufficient.
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 sentence, which is concise and front-loaded. However, it could be slightly more informative. Still, it avoids verbosity.
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 (9 parameters, nested objects, oneOf constraints) and no output schema, the description is too brief. It does not explain the required oneOf groups, return behavior, or how to structure the request. Schema is rich but description lacks context.
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 baseline is 3. The description adds no extra meaning to parameters; it only restates the tool's purpose. No parameter-specific context is provided.
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 'Send' and the resource 'transactional email using Brevo', distinguishing it from sibling tools like 'send_test_email' and 'send_campaign_now'. 'Transactional' signals it's not for campaigns or tests.
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 on when to use this tool versus alternatives (e.g., send_test_email, send_campaign_now). Lacks context on prerequisites or typical use cases for transactional emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a test version of a campaign to your pre-configured Brevo test list for review before sending to actual recipients
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | ID of the campaign to test | |
| emailTo | No | Optional: Override test list with specific emails. Normally omit this to use your pre-configured test list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool sends a test version to a pre-configured list, which is a non-destructive action. It does not mention side effects or permissions, but the behavior is straightforward.
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 no wasted words. It front-loads the action and purpose.
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?
The description is adequate for a simple tool with no output schema. It covers purpose, parameters, and usage context. However, it does not mention what the response indicates (e.g., success/failure), but this is minor given the tool's simplicity.
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 coverage is 100% and the description adds value beyond the schema by explaining that 'emailTo' is optional to override the test list, and advising normally to omit it. This provides clear usage guidance for both parameters.
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 version of a campaign'), the target ('to your pre-configured Brevo test list'), and the purpose ('for review before sending to actual recipients'). It distinguishes from siblings like 'send_campaign_now' which sends to actual recipients.
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 when to use (before actual sending) by stating 'for review before sending to actual recipients'. However, it does not explicitly list when not to use or compare to alternatives like 'send_email' or 'send_campaign_now', though the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update campaign status (pause, resume, archive)
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | ID of the campaign | |
| status | Yes | New campaign status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'update campaign status' without detailing side effects, validation rules, required permissions, or what happens during status transitions. The agent lacks critical behavioral 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 extremely concise with only 6 words plus parenthetical examples. No filler, but it lacks structure like bullet points or clear separation of details. It is efficient but slightly under-specified.
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 output schema and no annotations, the description should explain return values, error scenarios, and effects. It does not mention any of these. The low complexity (2 params) partially mitigates, but overall the description is incomplete.
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 covers 100% of parameters, so the description adds minimal extra value. It lists example statuses (pause, resume, archive) but these do not exactly match the enum ('suspended', 'archive', 'darchive', etc.), which could mislead. Brevity limits further semantic enrichment.
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 'update' on resource 'campaign status' with examples like pause, resume, archive. However, the actual enum values in the schema differ slightly (e.g., 'suspended' instead of 'pause', 'archive' present), which may cause confusion. Still, the core purpose is well communicated.
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 siblings such as 'update_email_campaign' or 'send_campaign_now'. The description does not specify prerequisites, alternatives, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing email campaign
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | ID of the campaign to update | |
| name | No | Internal campaign name | |
| subject | No | Email subject line | |
| sender | No | Sender information | |
| htmlContent | No | HTML content of the email | |
| htmlUrl | No | URL to fetch HTML content from | |
| templateId | No | ID of existing Brevo template | |
| recipients | No | Recipients configuration | |
| scheduledAt | No | ISO 8601 datetime to reschedule campaign | |
| sendAtBestTime | No | Enable send time optimization | |
| utmCampaign | No | UTM campaign parameter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits like idempotency, side effects, required permissions, or behavior when the campaign is already sent. The single statement 'Update an existing email campaign' is insufficient for safe invocation.
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 concise at one sentence, but it lacks essential information, making it under-specified rather than efficiently compact. Every sentence should earn its place; here, the single sentence adds minimal value.
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 with 11 parameters, nested objects, and no output schema, the description is incomplete. It does not explain return values, error conditions, or update semantics (e.g., partial vs. full update), leaving significant gaps for the 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?
All 11 parameters have full descriptions in the schema, achieving 100% coverage. The tool description adds no additional semantics beyond what the schema already provides, meeting the baseline of 3.
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 states the verb 'Update' and the resource 'existing email campaign', clearly indicating the tool's purpose. However, it does not differentiate from sibling tools like 'update_campaign_status' which also updates a campaign, lacking specificity on what aspects are updated.
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 such as 'create_email_campaign' or 'update_campaign_status'. No context on prerequisites or typical scenarios is given.
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.
v3.0.7create_email_campaignget_account_infoget_analytics_summaryget_campaign_analyticsget_campaign_recipientsget_campaigns_performanceget_contact_analyticsget_contactsget_email_campaignsget_shared_template_urlsend_campaign_nowsend_emailsend_test_emailupdate_campaign_statusupdate_email_campaignScored across 15 tools
Each tool targets a distinct resource and action; even analytics tools are clearly scoped to summary, specific campaign, multiple campaigns, or contacts. No ambiguity.
All tool names follow a verb_noun pattern in snake_case, e.g., create_email_campaign, get_account_info, send_test_email. No deviations.
15 tools is well-scoped for a Brevo email marketing server, covering campaign management, analytics, contacts, and transactional emails without being excessive.
Covers campaign lifecycle (create, update, send, test, status) and analytics, but lacks contact CRUD (only get_contacts) and campaign deletion, leaving notable gaps.
Marketing intelligence MCP server providing campaign performance data and analytics tools.
Sequenzy MCP server for AI-powered email marketing automation.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
