neuron_sync_newslettersSynchronize and import WhatsApp Channels from a connected WhatsApp session into Neuron. Discovers channels created outside Neuron.
| Name | Required | Description | Default |
|---|---|---|---|
| channelId | Yes | Identifier (UUID) of the WhatsApp session channel to sync newsletters from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, which the description complements by stating it 'imports' and 'discovers' non-destructively. However, the description does not disclose what happens on re-sync (e.g., overwriting or deduplication) or how it interacts with existing data. The write nature is evident from 'import' but minimal additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and a secondary benefit. Every word is essential with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and differentiator (discovering external channels), but lacks details on the return value (no output schema), the state after sync, and implicit dependencies like a connected WhatsApp session. Given the single parameter and annotations, it is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter channelId described as a UUID for the WhatsApp session channel. The description adds no additional meaning or constraints about this parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool synchronizes and imports WhatsApp Channels from a connected session, discovering channels created outside Neuron. The verb 'synchronize and import' and the resource 'WhatsApp Channels' are specific. Sibling tools like neuron_create_newsletter and neuron_post_to_newsletter have distinct purposes, but there is a slight naming inconsistency between 'newsletters' in tool name and 'WhatsApp Channels' in description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to import WhatsApp channels created externally into Neuron, but it does not explicitly state when to use this tool versus alternatives like neuron_create_newsletter or neuron_sync_whatsapp_contacts. There is no mention of prerequisites such as an active WhatsApp session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.