Skip to main content
Glama
EvandroSchechtel

WhatsApp Business MCP Server

send_interactive_message

Send WhatsApp messages with interactive buttons or selection lists to engage recipients and collect responses through structured options.

Instructions

Send an interactive message with buttons or a selection list.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesRecipient phone number
interactive_typeYesType of interactive message
body_textYesMain body text of the message
buttonsNoButtons array (max 3) for button type. Each needs id and title.
sectionsNoSections for list type. Each section has title and rows.
header_textNoHeader text
footer_textNoFooter text
button_textNoButton label for list typeMenu

Implementation Reference

  • The core implementation of the interactive message logic, performing the actual API request.
    async sendInteractiveMessage(
      to: string,
      interactiveType: "button" | "list",
      interactive: {
        header?: unknown;
        body: { text: string };
        footer?: { text: string };
        action: unknown;
      }
    ) {
      return this.request(`/${this.config.phoneNumberId}/messages`, "POST", {
        messaging_product: "whatsapp",
        to,
        type: "interactive",
        interactive: { type: interactiveType, ...interactive },
      });
    }
  • src/index.ts:188-230 (registration)
    The MCP tool definition and registration for "send_interactive_message", which validates input parameters and calls the WhatsApp client handler.
    server.tool(
      "send_interactive_message",
      "Send an interactive message with buttons or a selection list.",
      {
        to: z.string().describe("Recipient phone number"),
        interactive_type: z.enum(["button", "list"]).describe("Type of interactive message"),
        body_text: z.string().describe("Main body text of the message"),
        buttons: z
          .array(z.object({ id: z.string(), title: z.string() }))
          .optional()
          .describe("Buttons array (max 3) for button type. Each needs id and title."),
        sections: z
          .array(
            z.object({
              title: z.string(),
              rows: z.array(z.object({ id: z.string(), title: z.string(), description: z.string().optional() })),
            })
          )
          .optional()
          .describe("Sections for list type. Each section has title and rows."),
        header_text: z.string().optional().describe("Header text"),
        footer_text: z.string().optional().describe("Footer text"),
        button_text: z.string().optional().default("Menu").describe("Button label for list type"),
      },
      async ({ to, interactive_type, body_text, buttons, sections, header_text, footer_text, button_text }) => {
        const action: Record<string, unknown> =
          interactive_type === "button"
            ? { buttons: (buttons || []).map((b) => ({ type: "reply", reply: b })) }
            : { button: button_text, sections: sections || [] };
    
        return executeWithHooks(
          "send_interactive_message",
          { to, interactive_type, body_text },
          config,
          () =>
            wa.sendInteractiveMessage(to, interactive_type, {
              ...(header_text ? { header: { type: "text", text: header_text } } : {}),
              body: { text: body_text },
              ...(footer_text ? { footer: { text: footer_text } } : {}),
              action,
            })
        );
      }
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the tool sends a message but lacks details on behavioral traits such as permissions required, rate limits, delivery guarantees, error handling, or what happens upon invocation (e.g., does it trigger notifications?). This is inadequate for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose without redundancy. 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.

Completeness2/5

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

Given the complexity (8 parameters, mutation operation, no output schema, and no annotations), the description is incomplete. It lacks information on behavioral aspects, usage context, and expected outcomes, leaving significant gaps for an AI agent to understand how to invoke this tool effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description adds minimal value beyond the schema by hinting at the interactive_type options ('buttons or a selection list'), but it doesn't explain parameter interactions or provide additional context. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

The description clearly states the action ('send') and resource ('interactive message'), specifying it includes 'buttons or a selection list'. It distinguishes from siblings like send_text_message or send_template_message by focusing on interactivity. However, it doesn't explicitly contrast with all sibling tools (e.g., send_contact_message).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives is provided. The description mentions 'buttons or a selection list', which implies usage for interactive content, but it doesn't specify scenarios, prerequisites, or exclusions compared to other send_* tools in the sibling list.

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/EvandroSchechtel/mcp-whatsapp'

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