Skip to main content
Glama
bcharleson

Instantly MCP Server

reply_to_email

Respond to existing emails using the Instantly MCP Server by providing the email ID, account, subject, and body content for direct replies.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bcc_address_email_listNoComma-separated list of BCC email addresses (optional)
bodyYesEmail body content (REQUIRED). Provide either html or text, or both.
cc_address_email_listNoComma-separated list of CC email addresses (optional)
eaccountYesThe email account to send from (REQUIRED). Must be an email address from list_accounts that exists in your workspace.
reply_to_uuidYesThe ID of the email to reply to (REQUIRED). Get this from list_emails or get_email endpoints.
subjectYesReply subject line (REQUIRED). Usually starts with "Re: "

Implementation Reference

  • Main handler implementation for reply_to_email tool. Validates input parameters, constructs the reply payload, calls the Instantly.ai /emails/reply API endpoint to send the real email reply, and returns the result.
    case 'reply_to_email': {
      console.error('[Instantly MCP] ⚠️ CRITICAL: Executing reply_to_email - WILL SEND REAL EMAIL!');
    
      // Strict validation of required parameters
      if (!args.reply_to_uuid) {
        throw new McpError(ErrorCode.InvalidParams, 'reply_to_uuid is required - the ID of the email to reply to');
      }
      if (!args.eaccount) {
        throw new McpError(ErrorCode.InvalidParams, 'eaccount is required - the email account that will send the reply');
      }
      if (!args.subject) {
        throw new McpError(ErrorCode.InvalidParams, 'subject is required - the subject line of the reply');
      }
      if (!args.body) {
        throw new McpError(ErrorCode.InvalidParams, 'body is required - the content of the reply email');
      }
    
      // Build the reply data according to API v2 specification
      const replyData = {
        reply_to_uuid: args.reply_to_uuid,
        eaccount: args.eaccount,
        subject: args.subject,
        body: args.body
      };
    
      console.error(`[Instantly MCP] ⚠️ SENDING EMAIL REPLY with data: ${JSON.stringify(replyData, null, 2)}`);
      console.error(`[Instantly MCP] ⚠️ This will send a real email to real people!`);
      console.error(`[Instantly MCP] 🔧 Using endpoint: /emails/reply`);
    
      const replyResult = await makeInstantlyRequest('/emails/reply', {
        method: 'POST',
        body: replyData
      }, apiKey);
    
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify({
              success: true,
              reply: replyResult,
              message: '⚠️ Email reply sent successfully - REAL EMAIL WAS SENT!',
              warning: 'This tool sent an actual email reply to real recipients'
            }, null, 2)
          }
        ]
      };
    }
  • Tool definition including name, description, annotations (destructive/confirmation hints), and inputSchema for reply_to_email. This is used for MCP tool registration.
    {
      name: 'reply_to_email',
      title: 'Reply to Email',
      description: '🚨 SENDS REAL EMAIL! Confirm with user first. Cannot undo!',
      annotations: { destructiveHint: true, confirmationRequiredHint: true },
      inputSchema: {
        type: 'object',
        properties: {
          reply_to_uuid: { type: 'string', description: 'Email UUID to reply to' },
          eaccount: { type: 'string', description: 'Sender account (must be active)' },
          subject: { type: 'string', description: 'Subject line' },
          body: {
            type: 'object',
            properties: {
              html: { type: 'string' },
              text: { type: 'string' }
            }
          }
        },
        required: ['reply_to_uuid', 'eaccount', 'subject', 'body']
      }
    },
  • Zod validation schema (ReplyToEmailSchema) used for input validation of reply_to_email tool parameters.
    export const ReplyToEmailSchema = z.object({
      reply_to_uuid: z.string()
        .min(1, { message: 'Reply to UUID cannot be empty' })
        .refine(
          (val) => val !== 'test-uuid',
          'reply_to_uuid must be a valid email ID. Use list_emails or get_email tools first to obtain a valid email UUID.'
        ),
      body: z.object({
        html: z.string().optional(),
        text: z.string().optional()
      }).refine(
        (val) => val.html || val.text,
        'Body must contain either html or text content'
      )
    });
  • Registration of emailTools (which includes reply_to_email) into the main TOOLS_DEFINITION array exported for MCP server registration.
    return [
      ...accountTools,
      ...campaignTools,
      ...leadTools,
      ...emailTools,
      ...analyticsTools,
    ];
  • Validation function for reply_to_email inputs, registered in TOOL_VALIDATORS map at line 833.
    export function validateReplyToEmailData(args: unknown): z.infer<typeof ReplyToEmailSchema> {
      return validateWithSchema(ReplyToEmailSchema, args, 'reply_to_email');
    }
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description 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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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/bcharleson/Instantly-MCP'

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