Skip to main content
Glama

neuron

by io.github.conquext

Create Flow

neuron_create_flow

Create a new automation flow. A flow is a directed graph of nodes connected by edges. The graph MUST start with at least one trigger node (entry point). Edges connect nodes via output handles.

BEFORE BUILDING: call neuron_get_flow_catalog and read its reference — it carries the JSON shapes you cannot guess: the ConditionGroup + operator list for branch/filter/switch conditions, the cases/assignments/weekdays composite shapes, the handle wiring map, and copy-ready examples. Condition field on a logic node must be a {{template}} (e.g. '{{trigger.text}}'); on a trigger's config.conditions it is a raw payload path (e.g. 'text').

AFTER SAVING: the flow always saves, but the response includes a warnings array flagging likely bugs (unknown node type, missing required field, malformed conditions/cases/assignments, edges wired to a handle a node never emits, missing trigger). Always check it and fix any warnings — a warning means that part will silently no-op at run time.

TEMPLATE RESOLUTION: Node config values support {{…}} templates resolved at runtime: {{trigger.text}} — the triggering message text {{trigger.contactPhone}} — the sender's phone {{trigger.senderName}} — the sender's name {{vars.myVar}} — a variable set by logic.set_variable {{nodes.n_abc.output.text}} — output from a previous node {{= amount * 1.1 }} — inline expression (arithmetic, comparisons, ternary)

ERROR HANDLING: Any node's config can include __errorHandling: { continueOnFail: true, retryCount: 3, retryDelayMs: 1000 } to retry on failure with exponential backoff and/or continue on the 'error' handle instead of failing the run.

WIRING RULES:

  • logic.branch: 'true' and 'false' handles

  • logic.switch / logic.ai_router: one handle per case id, plus 'default'

  • logic.wait_for_reply: 'default' (replied) and 'timeout'

  • logic.wait_for_approval: 'approved', 'rejected', 'timeout'

  • logic.wait_first_of: 'reply', 'event', 'timeout'

  • logic.loop: 'loop' (body) and 'done'

  • action.lookup_contact: 'found' and 'not_found'

  • action.call_flow: 'default' (returned), 'timeout', 'error'

  • All other nodes: 'default' handle (or 'error' when continueOnFail is on)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesHuman-readable name for the flow.
graphNoThe flow graph — nodes and edges. Omit to create an empty flow (edit later in the UI).
enabledNoWhether the flow should be active immediately (default: false).
descriptionNoOptional description of what the flow does.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description reveals critical runtime behavior: the flow always saves, the response includes a warnings array, warnings indicate silent no-ops, templates are resolved at runtime, and __errorHandling can retry or continue on error. This gives the agent accurate expectations about side effects and failure modes.

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 long but well-structured with clear section headers and front-loaded purpose. Every section—catalog prerequisite, warnings, templates, error handling, wiring rules—earns its place given the complexity of the flow graph schema, and there is no filler or tautology.

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

Completeness5/5

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

There is no output schema, so the description compensates by explaining the warnings array and the meaning of warnings. It also covers the trigger requirement, catalog reference, template resolution, error handling, and wiring rules, making the tool sufficiently callable without external knowledge.

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

Parameters5/5

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

Even though the schema has 100% parameter coverage, the description adds substantial semantic detail: exact template syntax and resolved values, the shape of __errorHandling, per-node-type sourceHandle wiring, and the distinction between template fields on logic nodes versus raw payload paths on triggers. This goes far beyond the schema's field descriptions.

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 opens with a specific verb and resource—'Create a new automation flow'—and immediately defines the core artifact as a directed graph of nodes and edges. This is enough to distinguish it from sibling tools like neuron_get_flow, neuron_update_flow, and neuron_run_flow without needing to inspect their schemas.

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 gives explicit preconditions ('BEFORE BUILDING: call neuron_get_flow_catalog') and post-save guidance ('AFTER SAVING: ... check it and fix any warnings'). It does not explicitly state that neuron_update_flow should be used for existing flows instead of this create tool, so the exclusion is implied rather than stated.

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

All neuron toolsInspect
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