neuron

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

Name	Required	Description
`name`	Yes	Display name or label for the broadcast
`botId`	No	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.
`message`	Yes	Message content to broadcast to recipients
`mediaUrl`	No	URL of media to attach (required for image or document message types)
`channelId`	No	Identifier (UUID) of the WhatsApp channel to send through (auto-resolved from default channel if omitted)
`recipients`	No	Direct list of recipients (alternative to recipientSources)
`messageType`	No	Type of message to send (e.g., 'text', 'image', 'document')
`scheduledAt`	No	ISO 8601 date-time for scheduled broadcast delivery (e.g., '2025-12-31T10:00:00Z'). Creates as draft if omitted.
`recipientSources`	No	Resolve recipients dynamically from contact lists with filtering and exclusion

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only indicate that the operation is not read-only, not idempotent, not open-world, and not destructive, which is limited. The description adds meaningful behavioral context: the broadcast is created in draft status (not sent immediately) and the channel is auto-resolved if omitted. This goes beyond the annotations and helps the agent understand the tool's behavior.

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 three short sentences, front-loaded with the core purpose, and every sentence contributes useful information. There is no redundancy or filler, making it easy to parse quickly.

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 tool with 9 parameters and no output schema, the description covers the essential usage patterns: draft status, recipient specification options, and channel auto-resolution. It does not explain every parameter, but the schema descriptions are comprehensive, and the description provides enough context for an agent to invoke the tool correctly. It could mention the relationship to send_broadcast for full completeness, but it is adequate.

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

Parameters4/5

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

The schema covers 100% of parameters with descriptions, providing a strong baseline. The description adds value by summarizing the key decision between 'recipients' and 'recipientSources' and noting that 'channelId' can be omitted due to auto-resolution, which helps the agent understand parameter relationships without reading all schema details.

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 verb ('Create'), resource ('broadcast message'), and status ('draft'), which distinguishes it from sibling tools like neuron_send_broadcast and neuron_update_broadcast. It also mentions the key alternatives for specifying recipients, making the purpose unambiguous.

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

Usage Guidelines4/5

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

The description provides clear context: it creates a draft, so it is for creating rather than sending. It also explains the two ways to provide recipients and the auto-resolution of the WhatsApp channel. However, it does not explicitly mention when to use this tool over alternatives like neuron_send_broadcast, stopping short of full when/when-not guidance.

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

All neuron tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation3/5

Most tools are clearly separated by resource type, but there is meaningful overlap in messaging entry points (send_message, send_whatsapp, compose_message, bot_api_send) and contact ingestion/sync tools (import_contacts, populate_contacts, sync_whatsapp_contacts). The descriptions help disambiguate, but with 309 tools an agent will frequently need to read closely to pick the right one.

Naming Consistency4/5

The overwhelming majority of tools follow a consistent verb_noun snake_case pattern: create_*, get_*, list_*, update_*, delete_*. Minor deviations like sales_stats, lead_stats, wallet_balance, and whoami break the pattern slightly, but overall naming is highly predictable.

Tool Count1/5

309 tools is an extreme count for any MCP server, even a broad platform. This creates significant cognitive load and navigation overhead for agents, and far exceeds the well-scoped 3-15 tool range where coherence is strongest.

Completeness4/5

The tool surface is remarkably comprehensive across bots, contacts, campaigns, flows, knowledge bases, personas, marketplace, wallet, and products. Minor gaps exist — lead sources lack update/delete tools, and there is no single get_task or get_webhook alongside their list/update/delete counterparts — but these are workable gaps rather than dead ends.

Resources

Need Help?