Brevo MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools cover distinct functional areas like contacts, campaigns, and email, but there is notable overlap between 'contacts' and 'bulk_contact_import' or 'contact_with_list', which could confuse agents about the best tool for contact-related tasks. Descriptions help clarify, but boundaries are not always sharp.
Naming Consistency4/5
Most tools use a consistent noun-based naming convention (e.g., 'contacts', 'campaigns', 'email'), with a few exceptions like 'bulk_contact_import' and 'contact_with_list' that include verbs. The pattern is generally predictable and readable, with only minor deviations.
Tool Count5/5
With 16 tools, the count is well-suited for a comprehensive marketing and CRM platform like Brevo. Each tool appears to serve a specific purpose within the domain, avoiding bloat while covering a wide range of functionalities from account management to messaging.
Completeness5/5
The tool set provides extensive coverage of Brevo's domain, including core areas like contacts, campaigns, email, SMS, CRM, and webhooks. There are no obvious gaps; it supports full lifecycle operations from creation to management and tracking across multiple channels.
Average 2.8/5 across 16 of 16 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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. The description mentions 'handle customer conversations' which implies read and write operations, but doesn't specify authentication requirements, rate limits, side effects, or what happens when operations fail. For a tool with 5 parameters including operations like 'send_message' and 'update_conversation', this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point with just two phrases separated by a dash. It efficiently communicates the tool's domain without unnecessary words. However, it could be more front-loaded with specific capabilities rather than just general categories.
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 multi-operation tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how operations differ, or provide any context about the conversation system. For a tool that can perform 5 different operations ranging from reading conversations to sending messages, more comprehensive guidance is needed.
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 5 parameters with descriptions and enums. The description adds no parameter-specific information beyond what's in the schema. It doesn't explain relationships between parameters (e.g., that 'conversationId' is required for certain operations) or provide usage examples. The baseline of 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Chat and conversation management - handle customer conversations' which provides a general purpose (managing conversations) but lacks specificity. It mentions 'handle customer conversations' which suggests a customer service context, but doesn't specify what operations are available or distinguish this tool from potential sibling tools like 'sms' or 'whatsapp' which might also handle conversations. The purpose is clear at a high level but vague about the specific capabilities.
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 any prerequisites, constraints, or relationships with sibling tools like 'sms', 'whatsapp', or 'inbound' which might also handle communication. There's no indication of when to choose this conversation tool over other messaging or contact management tools available on the server.
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 mentions 'manage' operations but doesn't specify permissions required, rate limits, side effects (e.g., deletions are irreversible), or response formats. For a tool with 26 possible operations including destructive ones like delete_company, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Complete CRM functionality'). However, it could be more structured by explicitly listing the operation types or grouping them, but given the complexity, it's appropriately concise without wasted words.
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 high complexity (14 parameters, 26 operations including mutations, no annotations, no output schema), the description is inadequate. It doesn't explain the tool's scope relative to siblings, behavioral traits, or how to choose operations. For such a multifaceted tool, more context is needed to guide the agent effectively.
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 14 parameters thoroughly. The description adds no parameter-specific information beyond implying the tool handles companies, deals, tasks, and notes, which aligns with the operation enum but doesn't provide additional syntax, format, or usage details. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides 'complete CRM functionality' and lists the resource types managed (companies, deals, tasks, notes), which gives a general purpose. However, it's vague about the specific operations available and doesn't distinguish this from sibling tools like 'contacts' or 'account' that might overlap with CRM functionality. The description lacks a clear verb-action pairing beyond 'manage'.
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 'contacts' or 'account' that might handle related CRM functions, nor does it specify prerequisites, contexts, or exclusions for usage. The agent must infer usage solely from the operation parameter enum.
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 offers minimal behavioral insight. It mentions 'integration' but doesn't disclose whether operations are read-only, destructive, require authentication, have rate limits, or what the response format might be. For a tool with 23 possible operations including deletions and updates, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists key domains without unnecessary words. It's appropriately sized for a high-level overview, though it could be more front-loaded with a clearer verb. Every word earns its place by outlining scope.
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 tool's complexity (12 parameters, 23 operations, no output schema, no annotations), the description is incomplete. It doesn't address behavioral traits, usage context, or output expectations. For a multi-operation tool handling sensitive e-commerce data, more guidance is needed to help the agent use it correctly.
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 documents all 12 parameters thoroughly. The description adds no parameter-specific information beyond the high-level domains mentioned. It doesn't explain how parameters like 'operation' interact with others or provide examples. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool manages orders, products, coupons, and payments, which gives a general purpose but is vague about the specific actions. It doesn't distinguish from sibling tools like 'account' or 'crm' that might overlap in business domains. The description lacks a specific verb beyond 'manage' and doesn't clarify if this is for integration, API calls, or internal operations.
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. The description lists domains (orders, products, etc.) but doesn't specify context, prerequisites, or exclusions. Given sibling tools like 'campaigns' or 'crm' that might handle related e-commerce functions, the agent has no help in choosing between them.
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 it mentions three categories of operations, it doesn't disclose important behavioral traits: whether operations are read-only or mutative, what permissions are required, rate limits, whether email sending is immediate or queued, or what happens on failure. For a tool with 15 parameters and no annotations, this represents a significant gap in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase with three bullet-like components. It's front-loaded and wastes no words. However, given the complexity of the tool (15 parameters, 9 distinct operations), this level of conciseness may be too sparse. Every word earns its place, but more information might be warranted for such a multifaceted tool.
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 complex tool with 15 parameters, 9 distinct operations, no annotations, and no output schema, the description is inadequate. It doesn't explain the relationship between operations and parameters, doesn't provide examples, doesn't mention error conditions or response formats, and doesn't differentiate from sibling tools. The description fails to provide the contextual information needed to effectively use this multifaceted tool.
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%, meaning all parameters are documented in the schema itself. The description adds no parameter-specific information beyond what's already in the schema. It doesn't explain how parameters relate to different operations, which parameters are required for which operations, or provide usage examples. With complete schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Transactional email operations - send emails, manage templates, track events' which provides a general purpose but lacks specificity. It mentions three broad categories of operations but doesn't distinguish this tool from sibling tools like 'email_with_tracking' or 'campaigns' which may have overlapping functionality. The purpose is clear at a high level but not specific enough for precise tool selection.
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. With multiple sibling tools that likely handle email-related operations (email_with_tracking, campaigns, conversations), there's no indication of what makes this tool distinct or when it should be preferred over those alternatives. The description offers only a functional summary without contextual usage information.
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 mentions 'tracking and management' but doesn't specify whether this is a read-only or write operation, what permissions are required, if it's rate-limited, or what happens after event creation (e.g., storage, notifications). For a tool with no annotations and potential data mutation, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase: 'Custom event tracking and behavioral data management'. It's appropriately sized and front-loaded, with no wasted words. However, it could be slightly more structured by explicitly stating the primary action (e.g., 'Create and manage custom events').
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 (4 parameters including nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what the tool returns, how events are stored or used, or any prerequisites. For a tool that likely involves data creation and management, more context is needed to guide effective use by 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?
The input schema has 100% description coverage, with clear documentation for all 4 parameters (operation, email, eventName, eventData). The description adds no additional meaning beyond the schema, such as explaining the purpose of 'eventData' or constraints on 'eventName'. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Custom event tracking and behavioral data management' states what the tool does at a high level but lacks specificity about the exact operation. It mentions tracking and management but doesn't specify the verb (e.g., 'create' or 'log') or distinguish this from sibling tools like 'campaigns' or 'email_with_tracking' that might also involve event-related operations. The purpose is clear but vague about implementation details.
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. With many sibling tools (e.g., 'campaigns', 'email_with_tracking', 'webhooks'), there's no indication of whether this is for user behavior tracking, system events, or other purposes. It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
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. 'Process' implies some action but doesn't specify whether this is read-only, mutative, or has side effects. It doesn't mention authentication needs, rate limits, error conditions, or what the tool returns. The description is too generic to provide meaningful behavioral context for a tool with 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words with no wasted language. However, this brevity comes at the cost of being under-specified for a tool with significant complexity (8 parameters, multiple operations). While front-loaded, it lacks the necessary detail to be truly helpful.
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 tool with 8 parameters, multiple distinct operations via an enum, no annotations, and no output schema, the description is inadequate. It doesn't explain the different operation types, when to use each, what the tool returns, or how it differs from sibling tools. The minimal description fails to provide the context needed for effective tool selection and use.
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 8 parameters thoroughly with descriptions, enums, defaults, and requirements. The description adds no parameter-specific information beyond the generic 'process inbound emails and attachments' statement. With complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Process inbound emails and attachments' states a general purpose but is vague about what 'process' entails. It mentions the resource (inbound emails and attachments) but lacks specificity about the actual operations available (listing, retrieving, downloading). The description doesn't distinguish this tool from potential email-related siblings like 'email' or 'conversations'.
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. With siblings like 'email' and 'conversations' that might handle email-related functions, there's no indication of when this inbound processing tool is appropriate versus those other tools. No context, exclusions, or prerequisites are mentioned.
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 but provides minimal information. It mentions 'send transactional SMS' and 'manage SMS contacts' but doesn't describe what 'manage' means operationally, what permissions are required, whether there are rate limits, cost implications, or what happens when operations fail. For a tool with 16 parameters and no annotation coverage, this is inadequate behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 8 words, which is efficient for such a brief statement. However, it's arguably too brief given the tool's complexity with 16 parameters. While there's no wasted language, the description may be under-specified rather than appropriately concise for a multi-operation tool.
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 tool's complexity (16 parameters, multiple operations via the 'operation' enum), lack of annotations, and absence of an output schema, the description is insufficiently complete. It doesn't explain the relationship between different operations, what each operation returns, error conditions, or how this tool fits within the broader context of sibling communication tools. For a multi-function tool with significant parameter complexity, more contextual information is needed.
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 all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema - it doesn't explain parameter relationships, dependencies, or provide usage examples. With complete schema coverage, the baseline score of 3 is appropriate since the description doesn't add value beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'SMS operations - send transactional SMS, manage SMS contacts' which provides a general purpose but lacks specificity. It mentions 'send transactional SMS' and 'manage SMS contacts' but doesn't clarify what 'manage' entails or how this differs from sibling tools like 'contacts' or 'conversations'. The purpose is somewhat vague without clear differentiation from related tools.
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. With sibling tools like 'contacts', 'conversations', and 'whatsapp' available, there's no indication of when SMS operations are appropriate versus other communication channels or contact management approaches. The description offers no usage context, 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 of behavioral disclosure. It mentions operations like 'send messages, manage campaigns and templates' but does not disclose critical traits such as authentication requirements, rate limits, whether operations are read-only or destructive, or what happens on success/failure. For a multi-operation tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'WhatsApp messaging - send messages, manage campaigns and templates'. It is front-loaded with the main purpose and lists key functions without unnecessary detail. However, it could be slightly more structured by explicitly separating operations or adding brief context, but it earns high marks for brevity.
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 tool's complexity (9 parameters, multiple operations including mutations like create/delete, no output schema, and no annotations), the description is incomplete. It fails to address behavioral aspects, output expectations, error handling, or how operations interact. For a tool with such scope and no structured support, the description should provide more context to be adequately 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?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema—it does not explain parameter relationships, usage examples, or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for 'WhatsApp messaging - send messages, manage campaigns and templates', which gives a general purpose but lacks specificity. It mentions multiple operations (send, manage) without distinguishing which specific operations are available or how they differ from sibling tools like 'sms' or 'campaigns'. The purpose is clear at a high level but vague about scope and differentiation.
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 does not mention when to choose WhatsApp messaging over sibling tools like 'sms' or 'email', nor does it specify prerequisites, contexts, or exclusions for its operations. Usage is implied through the listed functions but without explicit direction.
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 it implies both read ('get') and write ('manage') operations, it doesn't specify permissions needed, rate limits, side effects, or response formats. For a tool with multiple mutation operations (create/update/delete), this is a significant gap in transparency about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a single sentence that efficiently communicates the tool's scope. It's front-loaded with the main purpose and follows with specific operation types. There's no wasted verbiage, though it could be slightly more structured by grouping operations more clearly.
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 tool's complexity (12 operations across 4 resource types), no annotations, and no output schema, the description is insufficiently complete. It doesn't explain return values, error conditions, or the relationships between operations. For a multi-function tool with mutation capabilities, more context is needed for effective agent use.
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 has 100% description coverage, so parameters are well-documented in the structured schema. The description adds minimal value beyond the schema by listing operation categories but doesn't provide additional semantic context about parameter usage or relationships. This meets 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 tool's purpose as 'Account management' with specific functions listed (get account info, manage senders, domains, folders). It provides a verb+resource structure that distinguishes it from siblings like 'contacts' or 'campaigns', though it doesn't explicitly contrast with them. The purpose is specific enough to understand the scope without being tautological.
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 lists operations but doesn't indicate prerequisites, appropriate contexts, or when other tools might be more suitable. With siblings like 'contacts' and 'crm' that might overlap, this lack of differentiation leaves the agent without clear usage direction.
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 mentions 'analyzes text, maps attributes, checks duplicates, and imports efficiently', which hints at mutation and processing behavior, but fails to specify critical details like required permissions, rate limits, error handling, or what 'efficiently' entails. 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 core purpose ('Intelligent bulk contact import from pasted text') and lists key actions without waste. Every phrase adds value, making it appropriately 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 tool's complexity (bulk import with mutation), lack of annotations, and no output schema, the description is incomplete. It omits essential context such as return values, error conditions, performance expectations, and how it integrates with sibling tools. This leaves significant gaps for an AI agent to understand and invoke the tool correctly.
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 all parameters thoroughly. The description adds no specific parameter semantics beyond implying 'pasted text' for the 'text' parameter. It doesn't compensate for any gaps, but with high schema coverage, the baseline is 3.
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 tool's purpose: 'Intelligent bulk contact import from pasted text' with specific actions like analyzing, mapping, checking duplicates, and importing. It distinguishes from simpler contact tools by emphasizing bulk processing and intelligence, though it doesn't explicitly differentiate from all sibling tools like 'contact_with_list'.
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 'contacts' or 'contact_with_list', nor does it mention prerequisites or exclusions. It implies usage for bulk imports from text but lacks explicit context for tool selection.
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 lists operations but doesn't explain permissions needed, whether operations are destructive (like delete), rate limits, response formats, or error conditions. For a multi-operation tool with potential destructive actions, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists key operations. It's appropriately sized for a multi-function tool, though it could be more front-loaded with the core purpose before listing operations. No wasted words, but could benefit from better structural separation of concepts.
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 complex tool with 7 parameters, multiple operation types (including destructive ones like delete), and no output schema or annotations, the description is insufficient. It doesn't explain what the tool returns, error handling, authentication requirements, or how different operations interact. The agent would struggle to use this tool effectively without trial and error.
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 7 parameters thoroughly with descriptions and enums. The description mentions 'create, update, send, schedule campaigns' which aligns with operation enum values but adds no additional semantic context beyond what the schema provides. 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 tool's purpose as 'Email and SMS campaign management' with specific verbs (create, update, send, schedule) and resources (campaigns). It distinguishes between email and SMS types, though it doesn't explicitly differentiate from sibling tools like 'email' or 'sms' which might handle individual messages rather than campaigns.
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 'email' or 'sms', nor does it specify prerequisites, appropriate contexts, or exclusions for campaign operations versus other messaging approaches.
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. While it mentions operations like 'create', 'update', and 'delete' which imply mutations, it doesn't describe authentication requirements, rate limits, error handling, or what happens during bulk operations. For a multi-operation tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information. It's appropriately sized for a multi-operation tool, though it could be slightly more structured by grouping related operations or indicating which are most common.
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 complex tool with 8 parameters, multiple operation types (including destructive ones like 'delete'), no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or how different operations behave. The agent would struggle to use this tool correctly without significant trial and error.
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 8 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it just lists operation types without explaining how parameters interact with them. The 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 tool's purpose as 'comprehensive contact management' and lists specific operations (create, update, get, bulk import, manage lists and attributes), providing a good overview of what the tool does. However, it doesn't explicitly differentiate this from sibling tools like 'contact_with_list' or 'bulk_contact_import', which appear to offer overlapping functionality.
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. With sibling tools like 'contact_with_list' and 'bulk_contact_import' available, there's no indication of when this comprehensive tool is preferred over more specialized ones, or any context about prerequisites or limitations.
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 mentions the combined action but doesn't explain critical behaviors: whether this is a mutation (implied by 'create'), what happens on failure, if there are rate limits, authentication requirements, or how errors are handled. For a tool that likely modifies data, this is a significant gap.
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—just one sentence with two clauses. It's front-loaded with the core purpose ('Create contact and add to list in one call') and adds a brief utility note. There's no wasted text, making it efficient for quick understanding.
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 (6 parameters, mutation likely, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits, error handling, return values, and comparison to siblings. For a tool that creates and modifies data, this minimal description leaves too many unknowns for effective agent use.
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 6 parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't clarify 'listIds' format or 'attributes' structure). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 tool's purpose: 'Create contact and add to list in one call'. It specifies the verb ('create') and resource ('contact'), and mentions the combined action ('add to list'). However, it doesn't explicitly differentiate this from sibling tools like 'contacts' or 'bulk_contact_import', which might offer similar functionality.
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 minimal guidance: 'universally useful combination' implies broad applicability but offers no specific context for when to use this tool versus alternatives. It doesn't mention when to choose this over separate create and add operations, or how it compares to sibling tools like 'contacts' or 'bulk_contact_import' for contact management.
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 mentions 'return tracking info immediately', which hints at real-time feedback, but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what 'tracking info' entails (e.g., delivery status, open rates). For a tool with no annotations and 7 parameters, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core functionality in a single sentence. The phrase 'universally useful combination' adds minimal fluff but doesn't significantly detract from clarity. It efficiently communicates the main purpose without unnecessary elaboration.
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 (7 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits, output format (what 'tracking info' includes), and how it differs from the sibling 'email' tool. For a tool that sends emails and returns tracking data, more context is needed to guide effective use.
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 all parameters well-documented in the schema (e.g., 'to' as 'Recipients list', 'htmlContent' as 'Email HTML content'). The description doesn't add any parameter-specific details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating 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 tool's purpose: 'Send email and return tracking info immediately'. It specifies the verb ('send'), resource ('email'), and key feature ('return tracking info'). However, it doesn't distinguish this from the sibling 'email' tool, which appears to be a more general email tool, so it doesn't fully differentiate from alternatives.
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 minimal usage guidance with 'universally useful combination', which is vague and doesn't specify when to use this tool versus the sibling 'email' tool or other communication tools like 'sms' or 'whatsapp'. No explicit when/when-not scenarios or alternative recommendations are provided.
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 reveals little about behavioral traits. It mentions 'management' which implies mutations, but doesn't specify authentication requirements, rate limits, side effects, or what happens during operations like delete_sub_account. This is inadequate for a tool with 7 parameters and multiple mutation operations.
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?
Given the tool's complexity (7 parameters, multiple operations including mutations), lack of annotations, and no output schema, the description is insufficient. It doesn't explain return values, error conditions, or provide enough context for the agent to understand the full scope of enterprise operations beyond the basic domain statement.
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 fully documents all parameters. The description adds no parameter-specific information beyond the high-level domain context. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with additional semantic context.
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 tool's purpose as 'Multi-tenant account and user management for enterprise features', which specifies the domain (enterprise features) and resources (accounts, users). It distinguishes from siblings like 'account' by emphasizing multi-tenancy and enterprise scope. However, it doesn't explicitly mention the specific operations listed in the schema.
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 prerequisites, permissions needed, or differentiate from sibling tools like 'account' or 'crm'. The agent must infer usage from the operation parameter 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 mentions operations (create, update, delete) but doesn't specify permissions required, rate limits, whether operations are idempotent, or what happens on failure. For a multi-operation tool with potential side effects, this is a significant gap in transparency.
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 - a single phrase that efficiently communicates the core functionality. Every word earns its place, and it's front-loaded with the essential information. There's no wasted verbiage or unnecessary elaboration.
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 complex tool with 7 parameters, multiple operations including destructive ones (delete), no annotations, and no output schema, the description is insufficient. It doesn't address the tool's scope, error handling, or what results to expect from different operations. The agent would need to guess about important behavioral aspects.
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 all 7 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between parameters or provide examples). This meets 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 tool's purpose as 'Webhook management - create, update, delete webhooks for event notifications', which includes specific verbs (create, update, delete) and the resource (webhooks). However, it doesn't explicitly differentiate this from sibling tools like 'events' or 'email_with_tracking' that might also handle notifications, so it doesn't reach the highest 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 any prerequisites, context for webhook management, or how it relates to sibling tools like 'events' or 'email' that might handle similar notification functions. This leaves the agent with insufficient context for optimal tool selection.
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:

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

Score Badge

Copy to your README.md:

[![brevo-mcp MCP server](https://glama.ai/mcp/servers/samihalawa/brevo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/samihalawa/brevo-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/samihalawa/brevo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server