Skip to main content
Glama

Meisa

by io.meisa
OverviewDiscussionsAdmin

Add Sequence Step

meisa_add_sequence_step

Add a step to a sequence. A drip is built from ordered steps; a typical flow is email -> delay -> email -> delay. Choose step_type and provide the matching fields: for 'email' pass email_template_id; for 'delay' pass delay_value and delay_unit; for 'condition' pass condition_rules and condition_logic; for 'action' pass action_type and action_config. Steps are appended unless you pass a 0-based position to insert at (later steps shift down). To build a full drip, call this once per step in order. On an email step after the first email, pass thread_with_first_email: true to send it as a reply in the same inbox thread as the sequence's first email.

Input Schema

NameRequiredDescriptionDefault
nameNoOptional custom name for the step.
positionNo0-based insert position. Omit to append at the end.
step_typeYesThe kind of step. email sends a template; delay waits; condition branches; action runs an action.
delay_unitNoFor a 'delay' step: the unit for delay_value. Defaults to days.
action_typeNoFor an 'action' step: which action to perform.
delay_valueNoFor a 'delay' step: how long to wait (>=1).
sequence_idYesUUID of the sequence to add the step to.
action_configNoFor an 'action' step: action-specific configuration, e.g. {"tag": "engaged"} for add_tag.
condition_logicNoFor a 'condition' step: whether all rules ('and') or any rule ('or') must match. Defaults to 'and'.
condition_rulesNoFor a 'condition' step: the list of rule objects to evaluate.
email_template_idNoFor an 'email' step: the UUID of the template to send (use meisa_list_templates to find it).
thread_with_first_emailNoFor an 'email' step after the sequence's first email: true sends it as a reply in the same inbox thread as the first email each contact received, with the subject "Re: <first email subject>". A contact who never received the first email gets a normal new email with the template's own subject. Rejected on the first email step and on non-email steps. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / thread_with_first_email
      Added value: +{
+  "description": "For an 'email' step after the sequence's first email: true sends it as a reply in the same inbox thread as the first email each contact received, with the subject \"Re: <first email subject>\". A contact who never received the first email gets a normal new email with the template's own subject. Rejected on the first email step and on non-email steps. Default false.",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing append-vs-insert semantics ('steps are appended unless you pass a 0-based position... later steps shift down'), the rejection cases for thread_with_first_email, and the fallback behavior for contacts who never received the first email. Annotations only cover the generic mutation profile (non-readonly, non-destructive, non-idempotent).

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?

Front-loads the core action, then the flow model, then the per-type field mapping, then the insert/ordering nuance, then the threading caveat. Five dense sentences with no filler for a 12-parameter tool.

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?

Given 12 parameters, nested objects, and no output schema, the description covers the conditional parameter requirements and ordering side effects well. It omits return-value shape, auth/permission requirements, and any cap on step count, which are minor gaps for a non-idempotent mutation.

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?

Schema coverage is 100%, so baseline is 3, but the description adds genuine cross-parameter semantics the schema cannot express: the step_type-to-field coupling (email→email_template_id, delay→delay_value/delay_unit, condition→condition_rules/condition_logic, action→action_type/action_config) and the 0-based insert behavior.

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?

States a specific verb+resource ('Add a step to a sequence') and immediately contextualizes it within drip construction ('a drip is built from ordered steps'). It is clearly distinguishable from siblings like meisa_update_sequence_step, meisa_delete_sequence_step, and meisa_reorder_sequence_steps.

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?

Gives explicit usage context ('To build a full drip, call this once per step in order') and states which fields to pass per step_type. It does not explicitly name alternatives such as update_sequence_step or reorder_sequence_steps, so it stops short of full when/when-not routing.

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

All Meisa toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources