Skip to main content
Glama
jonathan-politzki

Smartlead Simplified MCP Server

smartlead_create_automated_placement_test

Create automated email placement tests on a schedule to evaluate deliverability across spam filters, check link domains, and monitor inbox placement using Smart Delivery.

Instructions

Create an automated placement test that runs on a schedule using Smart Delivery.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
all_email_sent_without_time_gapYesSet true to send all emails simultaneously
campaign_idYesCampaign ID for which you want to select the sequence to test
daysYesDays of the week to run the test (1-7, where 1 is Monday)
descriptionNoDescription for your test to reference later
every_daysYesFrequency of how often to run a new test
folder_idNoFolder ID to assign the test to
is_warmupYesSet true to receive positive intent responses and move emails from spam to inbox
link_checkerYesEnable to check if domains for links in email body are blacklisted
min_time_btwn_emailsYesTime gap between each email from each mailbox (if time gap enabled)
min_time_unitYesTime unit for the time gap (minutes, hours, days)
provider_idsYesArray of provider IDs to send test emails to
schedule_start_timeYesStart date and time to schedule or run the test (ISO format)
sender_accountsYesArray of email addresses to use as senders
sequence_mapping_idYesThe ID of the sequence or variant you would like to test
spam_filtersYesArray of spam filters to test across, e.g. ["spam_assassin"]
starHourNoTest start time
test_end_dateYesEnd date to stop running your test (YYYY-MM-DD format)
test_nameYesName of your test
tzYesTimezone for scheduling

Implementation Reference

  • The core handler function that validates input parameters using isCreateAutomatedPlacementTestParams, creates a Smart Delivery API client, performs a POST request to '/spam-test/schedule' endpoint with the provided arguments, and returns the formatted response or error.
    async function handleCreateAutomatedPlacementTest(
      args: unknown, 
      apiClient: AxiosInstance,
      withRetry: <T>(operation: () => Promise<T>, context: string) => Promise<T>
    ) {
      if (!isCreateAutomatedPlacementTestParams(args)) {
        throw new McpError(
          ErrorCode.InvalidParams,
          'Invalid arguments for smartlead_create_automated_placement_test'
        );
      }
    
      try {
        const smartDeliveryClient = createSmartDeliveryClient(apiClient);
        
        const response = await withRetry(
          async () => smartDeliveryClient.post('/spam-test/schedule', args),
          'create automated placement test'
        );
    
        return {
          content: [
            {
              type: 'text',
              text: JSON.stringify(response.data, null, 2),
            },
          ],
          isError: false,
        };
      } catch (error: any) {
        return {
          content: [{ 
            type: 'text', 
            text: `API Error: ${error.response?.data?.message || error.message}` 
          }],
          isError: true,
        };
      }
    }
  • Defines the tool metadata, description, category, and complete inputSchema specifying all parameters, their types, descriptions, and required fields for creating an automated placement test.
    export const CREATE_AUTOMATED_PLACEMENT_TEST_TOOL: CategoryTool = {
      name: 'smartlead_create_automated_placement_test',
      description: 'Create an automated placement test that runs on a schedule using Smart Delivery.',
      category: ToolCategory.SMART_DELIVERY,
      inputSchema: {
        type: 'object',
        properties: {
          test_name: {
            type: 'string',
            description: 'Name of your test',
          },
          description: {
            type: 'string',
            description: 'Description for your test to reference later',
          },
          spam_filters: {
            type: 'array',
            items: { type: 'string' },
            description: 'Array of spam filters to test across, e.g. ["spam_assassin"]',
          },
          link_checker: {
            type: 'boolean',
            description: 'Enable to check if domains for links in email body are blacklisted',
          },
          campaign_id: {
            type: 'integer',
            description: 'Campaign ID for which you want to select the sequence to test',
          },
          sequence_mapping_id: {
            type: 'integer',
            description: 'The ID of the sequence or variant you would like to test',
          },
          provider_ids: {
            type: 'array',
            items: { type: 'integer' },
            description: 'Array of provider IDs to send test emails to',
          },
          sender_accounts: {
            type: 'array',
            items: { type: 'string' },
            description: 'Array of email addresses to use as senders',
          },
          all_email_sent_without_time_gap: {
            type: 'boolean',
            description: 'Set true to send all emails simultaneously',
          },
          min_time_btwn_emails: {
            type: 'integer',
            description: 'Time gap between each email from each mailbox (if time gap enabled)',
          },
          min_time_unit: {
            type: 'string',
            description: 'Time unit for the time gap (minutes, hours, days)',
          },
          is_warmup: {
            type: 'boolean',
            description: 'Set true to receive positive intent responses and move emails from spam to inbox',
          },
          schedule_start_time: {
            type: 'string',
            description: 'Start date and time to schedule or run the test (ISO format)',
          },
          test_end_date: {
            type: 'string',
            description: 'End date to stop running your test (YYYY-MM-DD format)',
          },
          every_days: {
            type: 'integer',
            description: 'Frequency of how often to run a new test',
          },
          tz: {
            type: 'string',
            description: 'Timezone for scheduling',
          },
          days: {
            type: 'array',
            items: { type: 'integer' },
            description: 'Days of the week to run the test (1-7, where 1 is Monday)',
          },
          starHour: {
            type: 'string',
            description: 'Test start time',
          },
          folder_id: {
            type: 'integer',
            description: 'Folder ID to assign the test to',
          },
        },
        required: ['test_name', 'spam_filters', 'link_checker', 'campaign_id', 'sequence_mapping_id', 'provider_ids', 'sender_accounts', 'all_email_sent_without_time_gap', 'min_time_btwn_emails', 'min_time_unit', 'is_warmup', 'schedule_start_time', 'test_end_date', 'every_days', 'tz', 'days'],
      },
    };
  • src/index.ts:217-219 (registration)
    Registers the array of Smart Delivery tools (including smartlead_create_automated_placement_test) with the tool registry if the smartDelivery category is enabled by license.
    if (enabledCategories.smartDelivery) {
      toolRegistry.registerMany(smartDeliveryTools);
    }
  • src/index.ts:354-356 (registration)
    Routes calls to tools in SMART_DELIVERY category (including this tool) to the handleSmartDeliveryTool dispatcher function.
    case ToolCategory.SMART_DELIVERY:
      return await handleSmartDeliveryTool(name, toolArgs, apiClient, withRetry);
    case ToolCategory.WEBHOOKS:
  • Switch case dispatcher within handleSmartDeliveryTool that directs to the specific handler for this tool.
    case 'smartlead_create_automated_placement_test': {
      return handleCreateAutomatedPlacementTest(args, apiClient, withRetry);
    }
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions scheduling and automation, it doesn't disclose critical behavioral traits such as: whether this is a write operation (likely, given 'create'), what permissions are required, whether it's idempotent, what happens on failure, rate limits, or what the tool returns. The description is too sparse for a tool with 19 parameters and no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise - a single sentence that directly states the tool's purpose. There's zero waste or unnecessary elaboration. It's appropriately sized and front-loaded with the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 19 parameters (16 required), no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, what happens after creation, error conditions, or operational implications. The description fails to provide the contextual completeness needed for an agent to understand the full scope and implications of using this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with all 19 parameters having descriptions in the schema itself. The tool description adds no additional parameter information beyond what's already documented in the schema. According to the scoring rules, when schema 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create an automated placement test') and the resource ('using Smart Delivery'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from the sibling 'smartlead_create_manual_placement_test' tool, which appears to be a related alternative for manual testing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'runs on a schedule' which implies automated, recurring testing, but provides no explicit guidance on when to use this tool versus alternatives like the manual placement test sibling. There's no mention of prerequisites, constraints, or typical use cases beyond the basic scheduling aspect.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jonathan-politzki/smartlead-mcp-server'

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