Skip to main content
Glama

Create Broadcast

neuron_create_broadcast

Create a new broadcast message in draft status. Provide recipients directly or use recipientSources to resolve from contact lists. The WhatsApp channel is auto-resolved if not specified.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name or label for the broadcast
botIdNoIdentifier (UUID) of a bot to send through. Each recipient's channel is picked by the bot's load-balancer + sticky sessions. Takes precedence over channelId.
messageNoMessage content to broadcast to recipients (optional when sending a template)
mediaUrlNoURL of media to attach (required for image or document message types)
templateNoApproved template (official WhatsApp Business API sessions only). On official API sessions, use one for broadcasts: most recipients won't have messaged you in the last 24 hours, and only templates reach them. Set messageType to 'template'.
channelIdNoIdentifier (UUID) of the WhatsApp channel to send through (auto-resolved from default channel if omitted)
recipientsNoDirect list of recipients (alternative to recipientSources)
messageTypeNoType of message to send (e.g., 'text', 'image', 'document', or 'template' on official API sessions)
scheduledAtNoISO 8601 date-time for scheduled broadcast delivery (e.g., '2025-12-31T10:00:00Z'). Creates as draft if omitted.
recipientSourcesNoResolve recipients dynamically from contact lists with filtering and exclusion

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / message / description
      Previous value: -"Message content to broadcast to recipients"New value: +"Message content to broadcast to recipients (optional when sending a template)"
    • changedInput schema / properties / messageType / description
      Previous value: -"Type of message to send (e.g., 'text', 'image', 'document')"New value: +"Type of message to send (e.g., 'text', 'image', 'document', or 'template' on official API sessions)"
    • addedInput schema / properties / template
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Approved template (official WhatsApp Business API sessions only). On official API sessions, use one for broadcasts: most recipients won't have messaged you in the last 24 hours, and only templates reach them. Set messageType to 'template'.",
      +  "properties": {
      +    "components": {
      +      "description": "Meta send-time components with variable values, e.g. [{ type: 'body', parameters: [{ type: 'text', text: 'Ada' }] }]. Omit for templates without variables.",
      +      "items": {
      +        "additionalProperties": {},
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "language": {
      +      "description": "Template language code, e.g. 'en_US'",
      +      "type": "string"
      +    },
      +    "name": {
      +      "description": "Template name exactly as approved (see neuron_list_whatsapp_templates)",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "name",
      +    "language"
      +  ],
      +  "type": "object"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "name",
      -  "message"
      -]New value: +[
      +  "name"
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / botId
      Added value: +{
      +  "description": "Identifier (UUID) of a bot to send through. Each recipient's channel is picked by the bot's load-balancer + sticky sessions. Takes precedence over channelId.",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / scheduledAt
      Added value: +{
      +  "description": "ISO 8601 date-time for scheduled broadcast delivery (e.g., '2025-12-31T10:00:00Z'). Creates as draft if omitted.",
      +  "type": "string"
      +}
  4. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish the non-destructive, non-idempotent write profile. The description adds two genuinely useful behavioral facts beyond them: the record is created as a draft (not sent immediately) and the WhatsApp channel is auto-resolved from a default if omitted. It does not discuss auth/permission needs, but the draft-status disclosure is real added value.

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

Conciseness4/5

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

Three short sentences, front-loaded with the verb+resource and the draft-status constraint. No filler; each sentence carries a distinct fact (draft creation, recipient sourcing, channel resolution).

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

Completeness4/5

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

For a 10-parameter, nested-schema tool with no output schema, the description covers the key behavioral points an agent must know before calling: draft vs. sent status, the two recipient-resolution paths, and channel auto-resolution. Template/messageType/scheduling details live in the schema, which is fully covered, so the description is adequate though not exhaustive.

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 10 parameters, including that recipients is the alternative to recipientSources. The description adds only the same pairing ('directly or use recipientSources') and channel auto-resolution, adding little beyond the structured fields. Baseline 3.

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?

States a specific verb+resource (create a broadcast message) and adds the distinguishing qualifier that it lands in 'draft status', which separates it from siblings like neuron_send_broadcast and neuron_update_broadcast. It stops short of naming those siblings explicitly, so differentiation is implicit rather than stated.

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

Usage Guidelines3/5

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

Gives usage context for the two recipient paths ('Provide recipients directly or use recipientSources to resolve from contact lists') and notes channel auto-resolution. However it never says when to prefer this draft-creation tool over neuron_send_broadcast or the various campaign/message tools, so routing guidance is only implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources