Skip to main content
Glama
Sign In
Flodesk MCP Server

Flodesk MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Add a subscriber to workflow.

add_subscriber_to_workflow
Destructive

Add a subscriber to a Flodesk workflow by email or ID to start automation; abandoned cart workflows are not supported.

Instructions

Notes:

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workflow_id": "<workflow_id>"
    },
    "name": "add_subscriber_to_workflow"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNo`id` is required if `email` is not present
emailNo`email` is required if `id` is not present
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
workflow_idYesExact native path parameter.
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.0
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true for the requested mutation or exclusive private output file."New value: +"Set true only when the user asked for exactly this action."
  2. First observedv2.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds non-duplicated context: the workflow must not currently have the subscriber active and abandoned-cart workflows reject this call. That explains why the operation is non-idempotent and where it fails, which is meaningful beyond the annotations. It still says nothing about success/return behavior or permission requirements.

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?

The content is two tight bullets with no filler, and the most consequential constraint (repeat-subscriber precondition) is listed first. The HTML markup (br, ul, li) is noisy overhead but the underlying text is lean. No wasted sentences.

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 7-parameter, nested-body, destructive mutation, the description supplies the failure constraints that the schema and annotations cannot express, and the 100%-covered schema plus explicit annotations carry the rest. No output schema exists, but for an add-to-workflow call the return surface is trivial. Adequate; only the absence of any permission/account-scoping note keeps it from a 5.

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 every parameter (id/email alternatives, account, confirm, payload, payload_file, workflow_id) is already documented in the schema. The description names no parameters and adds no semantics beyond it. Baseline 3 applies.

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?

The tool name and title state a specific verb+resource (add a subscriber to a workflow), and the sibling set contains unambiguous counterparts (remove_subscriber_from_workflow, add_subscriber_to_segments) that make the resource separable. However, the description body itself never states the purpose and opens directly with 'Notes', so it contributes no purpose statement of its own. Clear in practice, but the description adds no sibling differentiation beyond the name.

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 two bullets give real usage conditions: the repeat-subscriber preconditions (must have completed the workflow, 'Allow repeat subscribers' must be on) and an explicit exclusion (abandoned cart workflows cannot use this endpoint). This tells the agent when the call will fail, which is above-average guidance. It stops short of naming alternatives for the excluded case, so it is not a 5.

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

Deploy Server

Other Tools