Manage UniSender email marketing: subscriber lists, contacts, campaigns, templates, and statistics.
View and create mailing lists
Fetch contacts from a list and subscribe contacts to one or more lists
Create email messages and send campaigns to lists
Check campaign status and detailed delivery statistics
List and retrieve email templates
Supports full campaign flow and campaign stats via skills
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., "@@theyahia/unisender-mcp Show all mailing lists"
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.
🗄 Репозиторий заархивирован
Разработка переехала в theYahia/WWmcp — монорепозиторий MCP-серверов для незападных API: СНГ, MENA, Африка, LATAM, Юго-Восточная Азия. Общее ядро
@theyahia/mcp-core, единый CI, единый релизный конвейер.Актуальная версия того, что лежало здесь:
servers/unisender/Пакет в npm прежний —
@theyahia/unisender-mcp, ставится и работает как раньше. Здесь больше ничего не обновляется. Задачи и pull request'ы — в WWmcp.Archived — development moved to theYahia/WWmcp, a monorepo of MCP servers for non-Western APIs. The current version of this package now lives at
servers/unisender/. The npm package@theyahia/unisender-mcpis unchanged. Please open issues and pull requests there.
Если вы искали, как запустить email-рассылку прямо из диалога с ИИ, добавить контакты в список, подставить шаблон или снять статистику по кампании без ручной работы в кабинете — это оно. 10 инструментов поверх API UniSender: списки, контакты, кампании, шаблоны и статистика.
Регистрация в UniSender по реферальной ссылке — 50% с первого платежа + 25% на регулярной основе.
Related MCP server: mailchimp-mcp
{
"mcpServers": {
"unisender": {
"command": "npx",
"args": ["-y", "@theyahia/unisender-mcp"],
"env": {
"UNISENDER_API_KEY": "your_key"
}
}
}
}claude mcp add unisender -e UNISENDER_API_KEY=your_key -- npx -y @theyahia/unisender-mcpnpx @smithery/cli install @theyahia/unisender-mcpUNISENDER_API_KEY=your_key npx @theyahia/unisender-mcp --http
# Сервер на http://localhost:3000/mcp
# Health check: GET http://localhost:3000/healthUNISENDER_API_KEY — ключ API из UniSender. Где взять: настройки API.
Базовый URL: https://api.unisender.com/ru/api/
Инструмент | Описание |
| Все списки рассылки: ID, название, число подписчиков |
| Создать новый список рассылки |
Инструмент | Описание |
| Контакты из списка: e-mail, статус подписки |
| Подписать контакт на один или несколько списков |
Инструмент | Описание |
| Создать письмо для кампании |
| Отправить кампанию с созданным письмом |
| Статус кампании |
| Подробная статистика доставки |
Инструмент | Описание |
| Список шаблонов писем |
| Конкретный шаблон по ID |
Навык | Триггер | Описание |
| «Отправь рассылку» | Полный цикл: список → письмо → отправка |
| «Статистика кампании» | Статус + подробная аналитика |
Покажи все списки рассылки
Создай список «VIP-клиенты»
Подпиши user@example.com на список 123
Создай письмо с темой «Распродажа» и отправь на список 123
Статистика кампании 456
Покажи шаблоны писемnpm install
npm run build
npm testUniSender — сервис email- и SMS-маркетинга. 50% с первого платежа + 25% на регулярной основе по реферальной ссылке.
MIT
Telegram: @vhodvai
Создать email-сообщение для рассылки: тема, тело, отправитель.
| Name | Required | Description | Default |
|---|---|---|---|
| sender_name | Yes | Имя отправителя | |
| sender_email | Yes | Email отправителя | |
| subject | Yes | Тема письма | |
| body | Yes | HTML-тело письма | |
| list_id | Yes | ID списка рассылки |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as idempotency, side effects, authentication needs, or whether it creates a draft or triggers a send. The description is too minimal to inform an agent about important behavioral aspects beyond the basic action.
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 in Russian that conveys the core purpose without extraneous words. It is front-loaded with the verb and resource. However, the non-English text may reduce clarity for some agents, and the extreme brevity sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (5 required parameters, no output schema), the description is incomplete. It does not explain return values, error conditions, the effect of invoking it, or any constraints (e.g., uniqueness of sender_email). The description leaves many unanswered questions for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are described in the schema with 100% coverage. The description adds a summary of fields (subject, body, sender) but does not provide additional details beyond what the schema already contains, such as constraints, formatting, or relationships between 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 verb 'create' and the resource 'email message for mailing', and it lists key fields (subject, body, sender). It distinguishes from sibling tools like send_email (which sends) and create_list (which creates lists), but could be more explicit about creating a draft entity for a campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like send_email or create_list. It does not specify prerequisites, such as requiring an existing list_id, or when not to use it. The description solely states what it does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создать новый список рассылки.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Название списка рассылки | |
| before_subscribe_url | No | URL страницы до подписки | |
| after_subscribe_url | No | URL страницы после подписки |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions creation without disclosing side effects, auth requirements, or what happens on duplicate titles. Minimal behavioral disclosure.
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 short sentence with no fluff. It is appropriately sized and 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?
Given no output schema, no annotations, and sibling tools, the description lacks context about return values, integration, and constraints. It is minimal for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; parameters are only listed in schema.
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 creates a new mailing list, with a specific verb and resource. It distinguishes from sibling tools like create_email and get_lists.
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 vs alternatives. Sibling tools exist (e.g., create_email, get_lists) but no usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Детальная статистика доставки кампании.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | ID кампании | |
| changed_since | No | Дата изменений YYYY-MM-DD HH:MM:SS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'detailed statistics' but does not disclose whether the operation is read-only, any side effects, rate limits, or pagination behavior. The name implies a read operation, but this is not explicitly 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?
The description is a single sentence, concise but lacking structure. It does not separate purpose from usage or provide headings. Additionally, it is written in Russian, which may hinder understanding for an English-language AI agent.
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 simple tool (2 parameters, no output schema), the description is minimal. It does not explain the output format, how 'changed_since' filters results, or the scope of 'detailed statistics'. More context is needed for effective use, especially among several similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('campaign_id' and 'changed_since'), so the schema already explains them adequately. The description adds no extra meaning beyond the schema, meriting a baseline score 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 'Detailed campaign delivery statistics' clearly indicates the tool retrieves delivery stats for a campaign. However, it does not distinguish from sibling tools like 'get_campaign_status' or 'get_contacts', which could also provide campaign-related data.
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 such as 'get_campaign_status' or other get-statistics tools. The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Статус кампании: отправлено, доставлено, открыто, клики.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | ID кампании (из send_email) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It implies a read-only query returning status fields, but does not state side effects, real-time guarantees, or authorization requirements. This is insufficient for a tool with no other behavioral metadata.
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 conveys the core purpose and returned fields. It is front-loaded but could benefit from slight expansion for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks completeness. It does not explain interpretation of status fields, prerequisites (e.g., campaign must be sent), or potential delays. The tool is simple but the description is too minimal.
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 schema's description already explains the parameter (campaign_id from send_email). The tool description does not add any additional parameter meaning, so 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?
The description clearly states the tool returns campaign status with specific fields (sent, delivered, opened, clicks). It uses a clear verb implied by 'статус' but does not differentiate from sibling tool get_campaign_delivery_stats, which likely overlaps.
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 siblings like get_campaign_delivery_stats. The parameter description hints it is used after send_email, but no explicit context or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Контакты из списка рассылки: email, статус подписки.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | ID списка рассылки | |
| limit | No | Количество контактов (по умолчанию 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as read-only nature, pagination, or data freshness. For a simple retrieval tool, basic behavioral context is missing.
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 conveys the core function without unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain the output format, error scenarios, or how to interpret the data, leaving the agent with incomplete contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters. 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 clearly states it retrieves contacts from a mailing list, specifying the fields (email, subscription status). It is distinct from siblings like get_lists which return lists, though no explicit verb is used.
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 such as create_email or get_lists. The description only states what it does, not when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Списки рассылки UniSender: ID, название, количество подписчиков.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description does not disclose behavioral traits such as pagination, authentication requirements, or data freshness. The tool is simple but lacks transparency.
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 covering the essential information. Every word adds 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?
The description lists return fields but does not specify ordering, filtering, or potential limitations. It is adequate for a simple retrieval tool but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter documentation, but none is needed.
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 that the tool returns mailing lists with ID, name, and subscriber count. The verb 'get' implies retrieval, and it is distinct from sibling tools like 'create_list' which creates lists.
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 like 'create_list' or 'get_contacts'. Usage is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Получить конкретный шаблон по ID.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | ID шаблона |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the basic retrieval action. It does not disclose behavior such as whether results are cached, error conditions, or access restrictions.
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, minimal and directly to the point. No unnecessary words.
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?
Adequate for a simple get-by-ID tool, but no output schema or return value description provided. Could be more complete by mentioning what is returned.
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 'ID шаблона' for template_id. Description adds no new meaning beyond the schema, so baseline 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 clearly states it retrieves a specific template by ID, distinguishing it from sibling 'get_templates' which likely lists multiple templates.
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 'get_templates'. The description solely states the action without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Список шаблонов писем.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Тип шаблонов: user или system | |
| limit | No | Количество (по умолчанию 50) | |
| offset | No | Смещение для пагинации |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description does not disclose behavioral traits such as read-only status, authentication needs, or pagination behavior beyond parameter hints.
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?
Extremely concise single phrase, front-loaded and efficient, though borderline under-specified for a list 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?
Missing details on return format, pagination limits, or any other context; incomplete for a 3-parameter list tool with no 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% with descriptions for all parameters, so baseline 3 applies; description adds no additional meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a list of email templates, distinguishing it from sibling 'get_template' which retrieves a single template.
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 versus alternatives; lacks context about filtering or pagination usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Отправить рассылку по созданному письму.
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | ID письма из create_email |
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 only states the action (sending) but does not disclose any behavioral traits such as required permissions, whether the operation is destructive, rate limits, or side effects (e.g., whether it alters campaign state). This lack of detail for a mutation tool 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, efficient sentence that front-loads the core action. It avoids unnecessary words and is appropriate for the simple tool. However, it could be slightly more informative without losing conciseness, hence a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should disclose more context, such as prerequisites (e.g., that a list must be created and associated), return format, or side effects. It fails to explain what happens after sending (e.g., campaign status changes). The simplicity of the tool does not excuse these gaps.
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 schema already describes the parameter message_id well as 'ID письма из create_email' (ID of the letter from create_email). The description does not add any additional meaning or constraints beyond the schema, so it meets the baseline expectation.
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 'рассылку по созданному письму' (a mailing based on a created letter). This distinguishes from sibling tools like create_email, which creates the letter, and get_campaign_status, which checks status. The purpose is specific and unambiguous.
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 does not explicitly provide guidance on when to use this tool versus alternatives. However, from the context it is implied that send_email should be used after create_email, as the required message_id comes from create_email. No exclusions or when-not-to-use are mentioned, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Подписать контакт на список(и) рассылки.
| Name | Required | Description | Default |
|---|---|---|---|
| list_ids | Yes | ID списков через запятую, например 1,2,3 | |
| fields | Yes | Поля контакта: { email: '...', Name: '...' } | |
| double_optin | No | Тип подтверждения | |
| overwrite | No | Перезапись: 0=нет, 1=да, 2=добавить |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only states the basic action. It does not explain side effects, such as whether existing subscriptions are overwritten, if contacts are created automatically, or the meaning of parameters like double_optin and overwrite.
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 with a single sentence. However, it could be slightly more informative without losing brevity, such as mentioning the required parameters or the effect of the 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?
Given the complexity (4 parameters, nested object, no output schema), the description is too sparse. It does not explain the required fields format, the meaning of double_optin/overwrite enums, or what the tool returns, leaving gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not clarify parameter usage or provide examples. No extra value is added.
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 (subscribe) and the resource (contact to mailing list(s)). It is specific and distinct from sibling tools like get_contacts or create_email, making it easy for an agent to understand the tool's purpose.
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. The description does not mention prerequisites, when not to use it, or differentiate it from other subscription or contact management tools.
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.
v1.1.0create_emailcreate_listget_campaign_delivery_statsget_campaign_statusget_contactsget_listsget_templateget_templatessend_emailsubscribeScored across 10 tools
Each tool targets a distinct operation: creating emails, lists, subscribing contacts, sending campaigns, and retrieving statistics, templates, or contacts. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern in English (e.g., create_list, get_campaign_status, send_email), with no mixing of conventions or ambiguous verbs.
With 10 tools, the server covers the core functionalities of an email campaign system without being overly large or too minimal. Each tool serves a clear and necessary role.
The surface lacks essential update/delete operations for lists, emails, campaigns, and contacts (e.g., no unsubscribe or delete campaign). Also missing a tool to list campaigns, which limits workflow completion.
The first MCP server for physical mail: send postcards and letters, manage lists and campaigns.
An MCP server to send personalised direct mail.
Sequenzy MCP server for AI-powered email marketing automation.
