MCP-сервер для API Instantly.ai v2 — управление кампаниями по электронной почте, учетными записями, лидами и аналитикой через Claude AI. Идеально подходит для автоматизации электронной почты и холодных кампаний по охвату.
Instantly MCP Server — это мощная интеграция, которая переносит возможности автоматизации электронной почты Instantly.ai непосредственно в Claude и других помощников AI через Model Context Protocol. Это позволяет управлять с помощью AI:
📧 Email-кампании и последовательности
👥 Управление аккаунтом и его разогрев
📊 Аналитика и отслеживание эффективности
🎯 Управление лидами и сегментация
✉️ Отправка и проверка электронной почты
🔑 Управление ключами API
Идеально подходит для отделов продаж, маркетологов и разработчиков, желающих автоматизировать свои рабочие процессы по холодному общению с клиентами с помощью ИИ.
Related MCP server: Freshdesk MCP Server
Добавьте в конфигурацию настроек MCP:
{
"mcpServers": {
"instantly": {
"command": "npx",
"args": ["instantly-mcp", "--api-key", "YOUR_INSTANTLY_API_KEY"]
}
}
}Клонировать и установить:
npm install
npm run buildДобавьте в настройки MCP:
{
"mcpServers": {
"instantly": {
"command": "node",
"args": ["/path/to/instantly-mcp/dist/index.js", "--api-key", "YOUR_INSTANTLY_API_KEY"]
}
}
}Войти в Instantly.ai
Перейдите в Настройки > Интеграции > API.
Сгенерируйте или скопируйте свой ключ API
list_campaigns — список всех кампаний с дополнительными фильтрами и разбиением на страницы.
get_campaign — Получить сведения о конкретной кампании
create_campaign — создать новую кампанию по электронной почте
update_campaign — обновить существующую кампанию
activate_campaign — Активировать кампанию
get_campaign_analytics - Получите аналитику для кампаний
get_campaign_analytics_overview — получить аналитический обзор для всех кампаний
list_accounts — список всех отправляющих аккаунтов с разбивкой на страницы
create_account — создать новую учетную запись отправителя
update_account — обновление отправляющей учетной записи
get_warmup_analytics — получить аналитику разогрева для аккаунта
list_leads - Список лидов с фильтрами и пагинацией
create_lead — Создать новый лид
update_lead — обновить лид
move_leads — перемещение лидов между кампаниями или списками
list_lead_lists — список всех списков лидов с разбивкой на страницы
create_lead_list — Создать новый список лидов
send_email — отправить одно электронное письмо
list_emails — список адресов электронной почты с фильтрами и пагинацией
verify_email — проверка действительности адреса электронной почты
list_api_keys — список всех ключей API
create_api_key — Создать новый ключ API
После настройки вы сможете использовать естественный язык для взаимодействия с Instantly:
«Список всех моих активных кампаний»
«Покажите мне аналитику для кампании XYZ»
«Создайте новую кампанию под названием «Летняя распродажа»»
«Список всех моих отправляющих аккаунтов»
# Install dependencies
npm install
# Run in development mode
npm run dev -- --api-key YOUR_API_KEY
# Build for production
npm run buildПротестируйте конечные точки API напрямую:
# Install dependencies
npm install
# Run the test script
tsx test-endpoints.ts --api-key YOUR_API_KEYТест с помощью MCP Inspector:
# Build the project
npm run build
# Test with MCP Inspector
npx @modelcontextprotocol/inspector dist/index.js -- --api-key YOUR_API_KEYТест с Claude Desktop: Добавьте в конфигурацию Claude Desktop:
{
"mcpServers": {
"instantly": {
"command": "node",
"args": ["/absolute/path/to/dist/index.js", "--api-key", "YOUR_API_KEY"]
}
}
}Сервер MCP включает в себя все основные конечные точки API Instantly v2:
Кампании : создание, перечисление, обновление, активация кампаний
Аналитика : получите аналитику и обзор кампании
Учетные записи : управление отправляющими учетными записями и разминка
Лиды : создание, составление списка, обновление, перемещение лидов
Списки лидов : создание и управление списками лидов
Электронная почта : отправка электронных писем и просмотр истории электронной почты
Проверка электронной почты : проверка адресов электронной почты
API-ключи : Управление API-ключами
Полную документацию по API можно найти на сайте: https://developer.instantly.ai/
Массачусетский технологический институт
🚀 Полное покрытие API Instantly v2
📄 Поддержка пагинации для всех конечных точек списка
⚡ Ограничение скорости с помощью информационных сообщений
🔧 Комплексная обработка ошибок
📝 Поддержка TypeScript
🔐 Безопасная обработка ключей API
📚 Примеры скриптов включены
Исправлено создание кампании с улучшенной структурой поля
Добавлена настройка часового пояса и дней для кампаний.
Расширенное ведение журнала отладки для устранения неполадок
Механизм отката для различных структур API
Полную историю версий смотрите на сайте CHANGELOG.md .
Создание кампании может потребовать особой настройки учетной записи.
Некоторые конечные точки возвращают пустые результаты, несмотря на то, что данные существуют (работаем над исправлениями)
Для отправки электронной почты требуются проверенные учетные записи отправителя
Pull requests приветствуются! Убедитесь, что все тесты пройдены, и следуйте существующему стилю кода.
Форк репозитория
Создайте ветку функций ( git checkout -b feature/amazing-feature )
Зафиксируйте свои изменения ( git commit -m 'Add some amazing feature' )
Отправить в ветку ( git push origin feature/amazing-feature )
Открыть запрос на извлечение
Проблемы : Проблемы GitHub
Документация : Документация по API Instantly
Протокол MCP : Модель контекстного протокола
Этот пакет автоматически публикуется в npm при добавлении нового тега версии:
npm version patch|minor|major
git push --tagsЕсли у вас возникли проблемы или вопросы, пожалуйста, создайте тему на GitHub
Документацию по API Instantly можно найти на сайте: https://developer.instantly.ai/
Список изменений см. на сайте CHANGELOG.md.
Создано bcharleson
Check which premium features are available with your current Instantly plan and API key permissions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes a read-only check operation, which is safe, but doesn't add context such as whether it requires specific permissions beyond the API key, potential rate limits, or what the return format looks like (e.g., list of features, status). This leaves gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks details on usage context, behavioral traits, and output format, making it minimally viable but not fully complete for informed agent use.
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 tool has 0 parameters, and the schema description coverage is 100% (though trivial with no properties). The description doesn't need to add parameter details, so it meets the baseline of 4 for tools with no parameters, as it doesn't have to compensate for any gaps.
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's purpose with a specific verb ('Check') and resource ('premium features'), and specifies the context ('with your current Instantly plan and API key permissions'). It doesn't explicitly differentiate from siblings like 'get_account_details', but the focus on feature availability is distinct enough for a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when it's appropriate (e.g., before using premium features) or when not to use it, and doesn't reference sibling tools like 'get_account_details' that might overlap in providing account information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new email campaign with bulletproof three-stage workflow ensuring 100% success rate. Handles both simple requests ("create a campaign") and complex detailed specifications seamlessly.
INTELLIGENT WORKFLOW:
Simple Usage: Just provide basic info (name, subject, body) - tool automatically handles prerequisites
Advanced Usage: Specify all parameters for immediate creation
Guided Mode: Use stage parameter for step-by-step control
THREE-STAGE PROCESS:
Prerequisite Check (stage: "prerequisite_check"): Validates accounts and collects missing required fields
Campaign Preview (stage: "preview"): Shows complete configuration for user confirmation
Validated Creation (stage: "create"): Creates campaign with fully validated parameters
AUTO-STAGE DETECTION: Tool automatically determines appropriate stage based on provided parameters for seamless user experience.
EXAMPLE USAGE:
// Simple: Tool handles everything
create_campaign {"name": "My Campaign", "subject": "Hello", "body": "Hi there"}
// Advanced: Full specification
create_campaign {
"name": "My Campaign",
"subject": "Hello {{firstName}}",
"body": "Hi {{firstName}},\n\nGreat to connect!",
"email_list": ["verified@domain.com"],
"daily_limit": 50
}| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Email body content. Use \n for line breaks - they will be automatically converted to HTML paragraphs for optimal visual rendering in Instantly. Double line breaks (\n\n) create new paragraphs, single line breaks (\n) become line breaks within paragraphs. Example: "Hi {{firstName}},\n\nI hope this email finds you well.\n\nBest regards,\nYour Name". Supports all Instantly personalization variables. Required for creation but can be collected during prerequisite check. | |
| confirm_creation | No | Explicit confirmation for campaign creation (optional). Required when stage is "create" or when tool shows preview. Set to true to confirm you want to proceed with campaign creation. | |
| continue_thread | No | Automatically blank follow-up email subjects for thread continuation (optional, default: false). When true, all follow-up emails (steps 2+) will have empty subjects to maintain email thread continuity. Only applies when sequence_subjects is not provided. If sequence_subjects is provided, this parameter is ignored. | |
| daily_limit | No | Maximum emails to send per day across all sending accounts (optional, default: 50). Higher limits may affect deliverability. Recommended: 20-100 for new accounts, up to 500 for warmed accounts. | |
| days | No | Days of the week to send emails (optional, default: Monday-Friday only). Specify which days the campaign should send emails. Weekend sending is disabled by default for better deliverability. | |
| email_gap_minutes | No | Minutes to wait between individual emails (optional, default: 10). Longer gaps improve deliverability. Minimum 1 minute, maximum 1440 minutes (24 hours). | |
| email_list | No | Array of verified sending account email addresses. Must be exact addresses from your Instantly workspace. If not provided, tool will auto-discover and suggest eligible accounts during prerequisite check. | |
| link_tracking | No | Track link clicks in emails (optional, default: false). When enabled, links are replaced with tracking URLs. | |
| message | No | Shortcut parameter: single string containing both subject and body. First sentence becomes subject, remainder becomes body. Alternative to separate subject/body parameters. | |
| name | No | Campaign name. Choose a descriptive name that identifies the campaign purpose. Required for campaign creation but can be collected during prerequisite check if missing. | |
| open_tracking | No | Track email opens (optional, default: false). When enabled, invisible tracking pixels are added to emails. | |
| schedule_name | No | Schedule name (optional, default: "Default Schedule"). Internal name for the sending schedule. | |
| sequence_bodies | No | Optional array of body content for each sequence step. If provided, must contain at least as many items as sequence_steps. Each string will be used as the body for the corresponding step (index 0 = first email, index 1 = first follow-up, etc.). If not provided, the main "body" parameter will be duplicated across all steps with automatic follow-up prefixes. Use \n for line breaks - they will be automatically converted to HTML paragraphs. | |
| sequence_steps | No | Number of steps in the email sequence (optional, default: 1 for just the initial email). Each step creates an email with the required API v2 structure: sequences[0].steps[i] containing type="email", delay (days before sending), and variants[] array with subject, body, and v_disabled fields. If set to 2 or more, additional follow-up emails are created automatically. Maximum 10 steps. | |
| sequence_subjects | No | Optional array of subject lines for each sequence step. If provided, must contain at least as many items as sequence_steps. Each string will be used as the subject for the corresponding step. Use empty strings ("") for follow-up emails to maintain thread continuity. If not provided, the main "subject" parameter will be used for the first email, and follow-ups will get "Follow-up X:" prefixes. | |
| stage | No | Workflow stage control (optional). "prerequisite_check": Validate accounts and collect missing fields. "preview": Show complete campaign configuration for confirmation. "create": Execute campaign creation. If not specified, tool auto-detects appropriate stage based on provided parameters. | |
| step_delay_days | No | Days to wait before sending each follow-up email (optional, default: 3 days). This sets the delay field in sequences[0].steps[i].delay as required by the API. Each follow-up step will have this delay value. Minimum 1 day, maximum 30 days. | |
| stop_on_auto_reply | No | Stop sending when auto-reply is detected (optional, default: true). Helps avoid sending to out-of-office or vacation responders. | |
| stop_on_reply | No | Stop sending follow-ups when lead replies (optional, default: true). Recommended to keep true to avoid annoying engaged prospects. | |
| subject | No | Email subject line. Supports personalization variables like {{firstName}}, {{lastName}}, {{companyName}}. Example: "Quick question about {{companyName}}". Required for creation but can be collected during prerequisite check. | |
| text_only | No | Send as text-only emails (optional, default: false for HTML). Text-only emails often have better deliverability but no formatting. | |
| timezone | No | Timezone for campaign schedule (optional, default: "America/Chicago"). All timing_from and timing_to values will be interpreted in this timezone. | |
| timing_from | No | Daily start time in HH:MM format (optional, default: "09:00"). Emails will only be sent after this time each day. Example: "09:00" for 9 AM. | |
| timing_to | No | Daily end time in HH:MM format (optional, default: "17:00"). Emails will stop being sent after this time each day. Example: "17:00" for 5 PM. |
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 does an excellent job explaining the three-stage workflow, auto-detection logic, and how the tool handles missing parameters. However, it doesn't mention potential side effects like rate limits, authentication requirements, or what happens on failure. The description doesn't contradict any annotations (none provided).
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 well-structured with clear sections (Intelligent Workflow, Three-Stage Process, Example Usage), but it's quite lengthy at over 500 words. While all content is relevant, it could be more front-loaded with the core purpose. The example usage section is particularly valuable but contributes to the length.
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 (24 parameters, no annotations, no output schema), the description does an excellent job explaining the tool's behavior and workflow. It covers the multi-stage nature, parameter handling logic, and usage patterns. The main gap is the lack of output information - since there's no output schema, the description should ideally mention what the tool returns upon successful creation or at different stages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 24 parameters thoroughly. The description adds some context about parameter usage in different stages and provides example usage patterns, but doesn't add significant semantic meaning beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Create a new email campaign with bulletproof three-stage workflow'. It clearly distinguishes from sibling tools like 'get_campaign', 'list_campaigns', or 'update_campaign' by focusing on creation with a specific workflow. The description goes beyond the name by detailing the three-stage process and intelligent workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. It details three usage modes (simple, advanced, guided) and explains auto-stage detection. It distinguishes from sibling tools by being the primary creation tool, while tools like 'validate_campaign_accounts' or 'update_campaign' serve different purposes. The example usage section further clarifies appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new lead
| Name | Required | Description | Default |
|---|---|---|---|
| companyName | No | Company name | |
| custom_fields | No | Custom fields as key-value pairs | |
| Yes | Lead email address | ||
| firstName | No | First name | |
| lastName | No | Last name | |
| personalization | No | Personalization field | |
| website | No | Company website |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Create a new lead' implies a write operation, but it doesn't disclose behavioral traits like required permissions, whether the operation is idempotent, rate limits, or what happens on success/failure. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for its purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what a 'lead' is, what happens after creation, or any error conditions, leaving the agent with insufficient context for reliable use.
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, so parameters like 'email' (required) and others are documented in the schema. The description adds no additional meaning beyond the schema, such as explaining relationships between fields or usage examples, which aligns with the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new lead' clearly states the verb ('Create') and resource ('lead'), which is better than a tautology. However, it doesn't distinguish this tool from its sibling 'update_lead' or specify what constitutes a 'lead' in this context, making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update_lead' or 'create_lead_list'. It doesn't mention prerequisites, such as needing an email address, or contextual factors like when leads should be created versus updated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new lead list
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | List description | |
| name | Yes | List name |
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. 'Create a new lead list' implies a write/mutation operation, but it doesn't disclose permissions needed, whether the operation is idempotent, what happens on failure, or what the response contains. For a creation tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with just four words that directly state the tool's purpose. There's zero wasted language, and it's perfectly front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what a 'lead list' is in this system's context, what happens after creation, or how this differs from similar creation tools. The description should provide more context given the tool's complexity and lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (name and description) with their types and requirements. The description doesn't add any parameter semantics beyond what's in the schema, such as format constraints or examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new lead list' clearly states the verb ('create') and resource ('lead list'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_campaign' or 'create_lead' by specifying what distinguishes a lead list from these other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for creating resources (create_campaign, create_lead), but the description doesn't explain what a 'lead list' is or when it should be created instead of other entities. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific account including warmup status, SMTP settings, and eligibility for campaigns.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address of the account to inspect |
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 what information is retrieved, it doesn't cover critical aspects like permissions required, error handling (e.g., for non-existent accounts), rate limits, or response format. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 purpose ('Get detailed information about a specific account') and adds specifics without redundancy. It could be slightly improved by structuring usage hints, but it avoids waste and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves detailed account data. It lists information types but doesn't explain the return format, error cases, or dependencies. For a read operation with potential complexity (e.g., warmup status, SMTP settings), more context is needed to ensure the agent can use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'email' clearly documented in the schema. The description adds no additional parameter semantics beyond implying the email is for account identification. Since the schema does the heavy lifting, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get detailed information') and resource ('about a specific account'), distinguishing it from sibling tools like 'list_accounts' (which lists multiple accounts) and 'update_account' (which modifies accounts). It also specifies the types of information included (warmup status, SMTP settings, campaign eligibility), making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the account must exist), exclusions (e.g., what happens for invalid emails), or comparisons to siblings like 'list_accounts' (for overviews) or 'verify_email' (for validation). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific campaign
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it 'gets details' without disclosing behavioral traits like read-only nature, error handling, authentication needs, or rate limits. It lacks context on what 'details' includes or how it behaves, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loaded with the core action. It's appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'details' are returned, error cases, or how it fits with sibling tools, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'campaign_id' parameter. The description adds no meaning beyond this, such as format examples or constraints, but meets the baseline since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific campaign' clearly states the verb ('Get') and resource ('campaign'), but it's vague about what 'details' entails and doesn't differentiate from siblings like 'get_campaign_analytics' or 'list_campaigns'. It avoids tautology but lacks specificity.
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 'list_campaigns' for multiple campaigns or 'get_campaign_analytics' for performance data. The description implies usage for a single campaign but doesn't specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analytics for campaigns
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | No | Specific campaign ID (optional) | |
| end_date | No | End date (YYYY-MM-DD) | |
| start_date | No | Start date (YYYY-MM-DD) |
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 only states the action without details on permissions, rate limits, output format, or side effects. It lacks critical context for a read operation with optional parameters, making it inadequate for informed use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and appropriately sized for the tool's complexity, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a read operation with optional parameters, the description is incomplete. It fails to explain what analytics are returned, how optional parameters affect results, or behavioral traits, leaving significant gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented in the schema. The description adds no additional meaning beyond implying analytics retrieval, which is already covered by the tool name and purpose. Baseline 3 is appropriate as the schema handles parameter documentation.
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 'Get analytics for campaigns' states a basic purpose (verb+resource) but is vague about what analytics are retrieved or how it differs from sibling tools like 'get_campaign_analytics_overview'. It doesn't specify scope (e.g., metrics, timeframes) or distinguish itself clearly from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_campaign_analytics_overview' or 'get_campaign'. There's no mention of prerequisites, context, or exclusions, leaving the agent with no usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analytics overview for all campaigns
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | End date (YYYY-MM-DD) | |
| start_date | No | Start date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't address important aspects like authentication requirements, rate limits, error conditions, or what format the 'analytics overview' returns. For a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about what this tool actually returns and how it differs from sibling analytics tools. The current description is too minimal for a tool that presumably returns analytics data - it doesn't indicate what metrics are included in the 'overview' or what format the results take.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('start_date' and 'end_date') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, but since the schema provides complete 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get analytics overview for all campaigns' clearly states the verb ('Get') and resource ('analytics overview for all campaigns'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_campaign_analytics' or 'get_warmup_analytics', which appear to offer related analytics functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_campaign_analytics' and 'get_warmup_analytics' available, there's no indication of what differentiates this 'overview' tool from other analytics tools, nor any mention of prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific email by ID
| Name | Required | Description | Default |
|---|---|---|---|
| email_id | Yes | Email ID/UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool fetches an email but lacks details on permissions required, rate limits, error handling (e.g., for invalid IDs), or response format. This is inadequate for a read operation that might have constraints, scoring low due to minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, clear sentence that front-loads the core purpose without unnecessary words. Every part of the sentence ('Get a specific email by ID') contributes directly to understanding the tool, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is minimal but incomplete. It doesn't cover behavioral aspects like what data is returned or error conditions, which are crucial for effective use. For a basic read tool, more context on output or constraints would enhance 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 description mentions 'by ID', which aligns with the single parameter 'email_id' in the schema. Since schema description coverage is 100%, the schema already documents this parameter fully. The description adds no additional semantic context (e.g., ID format or source), so it meets the baseline 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific email by ID'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'list_emails' by specifying retrieval of a single item rather than listing. However, it doesn't explicitly mention what 'get' entails (e.g., fetching metadata, content, or both), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_email' over 'list_emails' for bulk retrieval or 'reply_to_email' for interaction, nor does it specify prerequisites like needing an email ID from another operation. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get warmup analytics for one or more accounts. API REQUIREMENT: The Instantly API expects an array of email addresses, even for a single account.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Array of email addresses to get warmup analytics for (1-100 emails). Use email addresses from list_accounts. | |
| end_date | No | End date (YYYY-MM-DD) - optional | |
| start_date | No | Start date (YYYY-MM-DD) - optional |
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 mentions the API requirement about array format, which is useful, but fails to describe key behaviors: whether this is a read-only operation, what the return format looks like, if there are rate limits, or authentication requirements. For a tool with 3 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core purpose. The API requirement is relevant but could be integrated more smoothly. No wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks information about return values, error conditions, behavioral constraints, and how it differs from sibling tools. The API requirement note is helpful but doesn't compensate for 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 description coverage is 100%, so the schema already fully documents all parameters. The description adds the API requirement about using an array even for single emails, which provides some additional context beyond the schema, but doesn't explain parameter interactions or semantics like date range effects. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('warmup analytics for one or more accounts'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from sibling analytics tools like 'get_campaign_analytics' or 'get_account_details', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_campaign_analytics' or 'get_account_details', nor does it mention prerequisites (e.g., that accounts must be warmed up). The API requirement note is technical rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sending accounts in the workspace. PREREQUISITE FOR CAMPAIGN CREATION: You MUST call this tool first before creating any campaigns to obtain valid email addresses for the email_list parameter. The returned accounts are the only valid sending addresses that can be used in campaigns.
CRITICAL FOR SUCCESS: Campaign creation will fail if you use email addresses that are not returned by this endpoint. Always use the exact email addresses from this response.
COMPLETE PAGINATION: To get ALL accounts, use one of these approaches:
Set limit=100 or higher (automatically triggers complete pagination)
Set get_all=true (forces complete pagination)
Use limit="all" (string triggers complete pagination)
PAGINATION ALGORITHM: When requesting all accounts, the tool will automatically:
Start with limit=100 per page
Continue fetching until next_starting_after is null or empty results
Report progress: "Retrieved 100... 200... 304 total accounts"
Return complete dataset with validation
ACCOUNT STATUS: Look for accounts with status=1, setup_pending=false, warmup_status=1 for campaign eligibility.
| Name | Required | Description | Default |
|---|---|---|---|
| get_all | No | Set to true to force complete pagination and retrieve ALL accounts regardless of limit setting. | |
| limit | No | Number of accounts to return (1-100, default: 20). Use limit=100+ or limit="all" to trigger complete pagination that retrieves ALL accounts automatically. | |
| starting_after | No | ID of the last item from previous page for manual pagination. Not needed when using complete pagination (limit=100+). |
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 and does so comprehensively. It explains the pagination algorithm, progress reporting, validation behavior, and account status filtering for campaign eligibility. It also details the three different approaches to trigger complete pagination, which goes well beyond what the input schema provides.
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 well-structured with clear sections (prerequisite, critical note, pagination approaches, algorithm, account status) and uses bold headings effectively. While it contains multiple paragraphs, each sentence earns its place by providing essential information. The front-loaded purpose statement is clear, though some technical details could potentially be streamlined.
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 pagination behavior, campaign prerequisites, and account eligibility requirements, the description provides complete context despite having no annotations and no output schema. It explains the tool's role in the workflow, how to use it effectively, what to expect from its behavior, and how to interpret the results for downstream operations like campaign creation.
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, so the baseline is 3. However, the description adds significant value by explaining the interaction between parameters (e.g., how 'limit' interacts with 'get_all' and 'starting_after'), the practical implications of different limit values, and the three different approaches to trigger complete pagination. This provides context beyond the individual parameter descriptions in the 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 specific action ('List all sending accounts') and resource ('in the workspace'), distinguishing it from sibling tools like 'get_account_details' which retrieves details for a specific account. It explicitly identifies the resource as 'sending accounts' rather than generic accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'PREREQUISITE FOR CAMPAIGN CREATION: You MUST call this tool first before creating any campaigns.' It also explains the consequence of not using it: 'Campaign creation will fail if you use email addresses that are not returned by this endpoint.' This gives clear context for when this tool is necessary versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all API keys
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List all API keys' implies a read-only operation, but it doesn't disclose behavioral traits like authentication requirements, rate limits, pagination, or what 'all' entails (e.g., scope or filters). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimally adequate. However, with no annotations and no output schema, it lacks details on return values or behavioral context, making it incomplete for optimal agent use despite the low 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but that's acceptable given the schema completeness, warranting a baseline above 3 for this context.
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 'List all API keys' clearly states the verb ('List') and resource ('API keys'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_accounts' or 'list_campaigns' beyond the resource type, so it's not fully specific to sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or related tools, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List campaigns with optional filters and complete pagination support. COMPLETE PAGINATION: To get ALL campaigns, use one of these approaches:
Set limit=100 or higher (automatically triggers complete pagination)
Set get_all=true (forces complete pagination)
Use limit="all" (string triggers complete pagination)
PAGINATION ALGORITHM: When requesting all campaigns, the tool will automatically:
Start with limit=100 per page
Continue fetching until next_starting_after is null or empty results
Report progress: "Retrieved 100... 200... 304 total campaigns"
Return summarized data to prevent size limits
Use get_campaign for full details of specific campaigns
FILTERS: search and status filters work with both single-page and complete pagination modes.
| Name | Required | Description | Default |
|---|---|---|---|
| get_all | No | Set to true to force complete pagination and retrieve ALL campaigns regardless of limit setting. | |
| limit | No | Number of campaigns to return (1-100, default: 20). Use limit=100+ or limit="all" to trigger complete pagination that retrieves ALL campaigns automatically. | |
| search | No | Search term to filter campaigns by name (works with complete pagination) | |
| starting_after | No | ID of the last item from previous page for manual pagination. Not needed when using complete pagination (limit=100+). | |
| status | No | Filter by campaign status (works with complete pagination) |
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 and does so comprehensively. It details the pagination algorithm (starting limit, continuation logic, progress reporting), explains that summarized data is returned to prevent size limits, clarifies that filters work with both pagination modes, and specifies that full details require 'get_campaign'. This provides rich behavioral context beyond basic functionality.
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 well-structured with clear sections (COMPLETE PAGINATION, PAGINATION ALGORITHM, FILTERS) and uses bullet points effectively. It's appropriately sized for the complexity, though some sentences could be more concise (e.g., the pagination algorithm explanation is somewhat verbose). Overall, it's front-loaded with key information and most content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (pagination algorithms, multiple modes) and lack of annotations/output schema, the description does an excellent job explaining behavior and usage. It covers the key aspects an agent needs: purpose, pagination approaches, algorithm details, filter compatibility, and relationship to 'get_campaign'. The main gap is lack of explicit sibling tool differentiation, but otherwise it's quite complete for a list operation with advanced features.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds some context about how parameters interact (e.g., 'limit=100+ or limit="all" triggers complete pagination', 'starting_after not needed when using complete pagination'), but doesn't provide significant additional semantic meaning beyond what's in the schema descriptions. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List campaigns with optional filters and complete pagination support.' It specifies the verb ('list') and resource ('campaigns'), but doesn't explicitly differentiate from sibling tools like 'get_campaign' or 'get_campaign_analytics' beyond mentioning that 'get_campaign' provides full details. The purpose is clear but sibling differentiation is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use complete pagination (with three specific approaches) and mentions that 'get_campaign' should be used for full details of specific campaigns. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_campaign_analytics' or 'list_lead_lists', nor does it provide exclusion criteria for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List emails with filters and pagination
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | Filter by account | |
| campaign_id | No | Filter by campaign | |
| limit | No | Number of emails to return (1-100, default: 20) | |
| starting_after | No | ID of the last item from previous page for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'filters and pagination', hinting at querying behavior, but fails to disclose critical traits: whether this is a read-only operation, potential rate limits, authentication needs, what happens if filters yield no results, or the format of returned data. For a list tool with no annotation coverage, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('List emails') and includes key features without redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters and list functionality. It lacks details on behavioral traits (e.g., safety, limits), return values, or error handling, which are essential for an agent to use it correctly in context with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds minimal value by mentioning 'filters and pagination', which aligns with parameters like 'account_id' and 'starting_after', but doesn't provide additional context beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List emails') and mentions key capabilities ('with filters and pagination'), which distinguishes it from sibling tools like 'get_email' (singular) or 'reply_to_email'. However, it doesn't specify what type of emails (e.g., marketing, transactional) or fully differentiate from other list tools like 'list_campaigns' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an account), exclusions, or compare it to siblings like 'list_campaigns' or 'get_email', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all lead lists with pagination
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of lists to return (1-100, default: 20) | |
| starting_after | No | ID of the last item from previous page for pagination |
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 'pagination', which is a key behavioral trait not evident from the schema alone, adding value. However, it lacks details on permissions, rate limits, response format, or error conditions, leaving significant gaps for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all lead lists') and adds essential context ('with pagination') without waste. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation with 2 parameters) and no output schema, the description is minimally adequate. It covers the basic action and pagination but lacks details on return values, error handling, or integration with siblings. For a tool with no annotations, it should provide more behavioral context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('limit' and 'starting_after'). The description adds no additional parameter semantics beyond implying pagination, which is already covered in the schema's descriptions. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('list') and resource ('lead lists'), making the purpose immediately understandable. It distinguishes from siblings like 'create_lead_list' (creation vs listing) and 'list_leads' (lists vs leads), though it doesn't explicitly contrast with other list operations. The description is specific but lacks explicit sibling differentiation beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or comparisons with other list operations (like 'list_campaigns' or 'list_leads'). The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List leads with filters and pagination
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | No | Filter by campaign ID | |
| limit | No | Number of leads to return (1-100, default: 20) | |
| list_id | No | Filter by list ID | |
| starting_after | No | ID of the last item from previous page for pagination | |
| status | No | Filter by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'filters and pagination' which gives basic behavioral context, but doesn't disclose important traits like whether this is a read-only operation (implied but not stated), rate limits, authentication requirements, error conditions, or what the return format looks like. For a tool with 5 parameters and no output schema, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core purpose ('List leads') followed by key capabilities ('with filters and pagination'). Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is insufficiently complete. While concise, it doesn't compensate for the lack of structured metadata. For a filtering and pagination tool that likely returns complex lead data, the description should provide more context about return format, error handling, or usage examples to help an agent understand what to expect.
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 all parameters are documented in the schema. The description adds minimal value beyond the schema by mentioning 'filters and pagination' which aligns with parameters like 'campaign_id', 'list_id', 'status' (filters) and 'starting_after' (pagination). However, it doesn't provide additional context about parameter interactions or usage patterns beyond what's already in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('leads'), and mentions filtering and pagination capabilities. It distinguishes from other lead-related tools like 'create_lead' or 'update_lead' by focusing on retrieval. However, it doesn't explicitly differentiate from 'list_lead_lists' which might be a sibling tool for listing lead collections rather than individual leads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'list_lead_lists' (for listing lead collections) and 'get_campaign' (for retrieving specific campaigns), there's no indication of when this filtered lead listing is preferred over other listing or retrieval methods. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to an existing email. IMPORTANT: This can only be used to reply to existing emails, not to send new emails. You must provide the ID of an existing email to reply to. Use campaigns for sending new emails.
| Name | Required | Description | Default |
|---|---|---|---|
| bcc_address_email_list | No | Comma-separated list of BCC email addresses (optional) | |
| body | Yes | Email body content (REQUIRED). Provide either html or text, or both. | |
| cc_address_email_list | No | Comma-separated list of CC email addresses (optional) | |
| eaccount | Yes | The email account to send from (REQUIRED). Must be an email address from list_accounts that exists in your workspace. | |
| reply_to_uuid | Yes | The ID of the email to reply to (REQUIRED). Get this from list_emails or get_email endpoints. | |
| subject | Yes | Reply subject line (REQUIRED). Usually starts with "Re: " |
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 clearly indicates this is a mutation operation (reply action) and specifies constraints (requires existing email ID, cannot send new emails). However, it doesn't mention authentication needs, rate limits, error conditions, or what the response looks like, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: states the purpose, provides critical constraint, and gives alternative guidance. It's front-loaded with the core functionality and wastes no 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?
For a mutation tool with no annotations and no output schema, the description provides good purpose and usage guidance but lacks behavioral details about permissions, response format, or error handling. The 100% schema coverage helps, but more context about the operation's behavior would be beneficial given the 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 the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Reply to an existing email') and resource ('email'), distinguishing it from sibling tools like create_campaign for sending new emails. It explicitly differentiates from alternatives by stating 'This can only be used to reply to existing emails, not to send new emails.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('reply to existing emails') and when not to ('not to send new emails'), with a clear alternative named ('Use campaigns for sending new emails'). It also mentions prerequisites ('You must provide the ID of an existing email to reply to').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a sending account
| Name | Required | Description | Default |
|---|---|---|---|
| daily_limit | No | New daily sending limit | |
| Yes | Email address of the account to update | ||
| warmup_enabled | No | Enable/disable warmup |
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. While 'Update' implies a mutation operation, the description doesn't specify permission requirements, whether changes are reversible, rate limits, or what happens when updating fails. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words ('Update a sending account'), with zero wasted language. It's front-loaded with the core action and resource, making it immediately understandable despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'sending account' means in this context, what values are returned, error conditions, or how this tool relates to other account management tools like 'get_account_details' and 'list_accounts'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a sending account'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from sibling tools like 'update_campaign' or 'update_lead' - it simply describes what it does without comparative context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this should be used instead of other update tools, or what context would make this appropriate. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing campaign
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign ID | |
| name | No | New campaign name | |
| status | No | New status |
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. 'Update an existing campaign' implies a mutation operation but doesn't specify required permissions, whether changes are reversible, rate limits, or what happens if only some fields are provided. It lacks critical behavioral context for a write operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple update operation and front-loads the core action. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the update does beyond the basic action, what values 'status' can take, whether all fields are optional besides campaign_id, or what the tool returns. For a 3-parameter write operation with zero structured context, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (campaign_id, name, status) adequately. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter interactions, constraints, or provide examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing campaign' clearly states the verb ('update') and resource ('campaign'), but it's vague about what specifically gets updated. It doesn't differentiate from sibling tools like 'update_account' or 'update_lead' beyond the resource name, nor does it specify which campaign attributes can be modified beyond what the schema shows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing campaign ID), when not to use it, or how it relates to siblings like 'create_campaign' or 'get_campaign'. The description alone gives no context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a lead
| Name | Required | Description | Default |
|---|---|---|---|
| company | No | Company name | |
| custom_fields | No | Custom fields as key-value pairs | |
| first_name | No | First name | |
| last_name | No | Last name | |
| lead_id | Yes | Lead ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update a lead' implies a mutation operation, but it doesn't describe what happens during the update (e.g., whether it overwrites or merges fields, if custom_fields are additive or replace existing ones), what permissions are required, or what the response looks like (especially since there's no output schema). For a mutation tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words ('Update a lead'), with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. While it may be overly brief for a mutation tool, it earns full marks for conciseness as every word contributes directly to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 5 parameters including nested objects), lack of annotations, and no output schema, the description is incomplete. It doesn't address key contextual aspects like what the update does behaviorally, how to handle custom_fields, what happens on success/failure, or how it differs from sibling tools. For a tool that modifies data, this minimal description leaves too many gaps for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 5 parameters clearly documented in the schema (e.g., lead_id as required, company, custom_fields, first_name, last_name). The description adds no additional parameter information beyond what's in the schema, such as examples or constraints. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
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 'Update a lead' clearly states the verb (update) and resource (lead), making the basic purpose understandable. However, it doesn't specify what aspects of a lead can be updated or differentiate this tool from sibling tools like 'update_account' or 'update_campaign' that also perform updates on different resources. The purpose is clear but lacks specificity about scope and distinction from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing lead ID), when not to use it (e.g., for creating new leads, which is handled by 'create_lead'), or compare it to similar tools like 'update_account'. Without any usage context, agents must infer everything from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate which accounts are eligible for campaign creation. This tool helps debug campaign creation issues by showing the status of all accounts and which ones meet the requirements for sending campaigns.
| Name | Required | Description | Default |
|---|---|---|---|
| email_list | No | Optional: Specific email addresses to validate. If not provided, shows all account statuses. |
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 describes the tool's function (validation and debugging) and output scope ('shows the status of all accounts'), but lacks details on permissions, rate limits, or error handling, which are important for a tool that might involve account data access.
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 front-loaded with the main purpose in the first sentence and efficiently adds context in the second, with no wasted words. Every sentence contributes directly to understanding the tool's use and value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validation with optional filtering), no annotations, and no output schema, the description is adequate but incomplete. It explains the purpose and usage context but does not cover behavioral aspects like response format or error conditions, which are needed for full agent 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, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides (e.g., it does not explain the format or validation rules for email addresses), relying entirely on the schema's documentation.
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's purpose with specific verbs ('validate which accounts are eligible') and resources ('campaign creation'), distinguishing it from siblings like 'list_accounts' or 'get_account_details' by focusing on eligibility validation rather than general listing or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('helps debug campaign creation issues'), but does not explicitly state when not to use it or name specific alternatives among siblings, such as 'check_feature_availability' or 'list_accounts', which might overlap in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify if an email address is valid. IMPORTANT: This feature may require a premium Instantly plan or specific API permissions. If you receive a 403 Forbidden error, check: 1) Your Instantly plan includes email verification, 2) Your API key has the required scopes, 3) Contact Instantly support to confirm feature availability.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to verify (must be valid email format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a validation operation (implied read-only), discloses potential access restrictions (premium plan requirements, 403 errors), and provides troubleshooting guidance. It doesn't mention rate limits or response format details, but covers critical operational constraints.
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 appropriately sized and front-loaded with the core purpose first, followed by important operational details. The troubleshooting list is somewhat lengthy but necessary for the access constraints, making it reasonably efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter validation tool with no annotations and no output schema, the description provides good contextual completeness. It covers purpose, usage context, and critical behavioral constraints (access requirements, error handling). The main gap is lack of output format details, but otherwise it's quite comprehensive given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'email' parameter. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage through structured data alone.
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's purpose with a specific verb ('verify') and resource ('email address'), and it distinguishes this tool from all sibling tools which focus on campaigns, leads, accounts, or lists rather than email validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to verify email validity) and includes important prerequisites (premium plan, API permissions). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling 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. Dates show when Glama detected each change.
v1.0.0check_feature_availabilitycreate_campaigncreate_leadcreate_lead_listget_account_detailsget_campaignget_campaign_analyticsget_campaign_analytics_overviewget_emailget_warmup_analyticslist_accountslist_api_keyslist_campaignslist_emailslist_lead_listslist_leadsreply_to_emailupdate_accountupdate_campaignupdate_leadvalidate_campaign_accountsverify_emailMost tools have distinct purposes targeting specific resources like campaigns, leads, accounts, or emails, with clear boundaries. However, some potential confusion exists between get_campaign_analytics and get_campaign_analytics_overview, as both relate to campaign analytics but differ in scope, which could lead to misselection without careful reading of descriptions.
Tool names follow a highly consistent verb_noun pattern throughout, such as create_campaign, list_accounts, update_lead, and get_campaign_analytics. This predictability makes it easy for agents to understand and navigate the toolset without ambiguity in naming conventions.
With 22 tools, the count is borderline high for an email marketing server, potentially feeling heavy and overwhelming. While it covers a broad domain, some tools might be redundant or overly specialized, making the set less streamlined than ideal for typical agent workflows.
The toolset provides comprehensive CRUD and lifecycle coverage for campaigns, leads, accounts, and emails, including creation, listing, updating, and analytics. It also includes specialized tools like validate_campaign_accounts and reply_to_email, ensuring no obvious gaps for the email marketing domain and supporting robust agent operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage contacts, campaigns, senders, and deliverability via SuperSend API
Manage SiteGPT chatbots and account resources through the SiteGPT API v2.
Send email and read templates, marketing contacts, lists, stats, bounces and unsubscribes.
AI-powered email outreach platform — send campaigns with deliverability tracking.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bcharleson/Instantly-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
