Skip to main content
Glama
Sign In
Flodesk MCP Server

Flodesk MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Execute reviewed subscriber tasks

submit_subscriber_batch
Destructive

Execute a prevalidated, hash-verified batch of up to 20 ordered subscriber, segment, or workflow tasks, halting at the first failure with known results and unattempted indices.

Instructions

Confirmed one-to-twenty ordered subscriber/segment/workflow/custom-field tasks. Prevalidate all and verify exact hash before first request. Stop on first failure with known results/failed index/unattempted indices; no retries, rollback or implicit continuation.

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": {
      "tasks": "<tasks>",
      "review_sha256": "<review_sha256>"
    },
    "name": "submit_subscriber_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
tasksYesOne to twenty exact ordered supported subscriber/segment/workflow/custom-field operations. Native batch upserts may affect up to50 subscribers per task; not a20-person budget.
accountNoExact selected private account profile; binds label, not key ownership.
confirmNoSet true only when the user asked for exactly this action.
review_sha256YesExact preview_subscriber_batch hash for identical requests, profile label, schema and order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.0
    • changedInput schema / properties / confirm / description
      Previous value: -"Explicit approval for this exact requested ordered batch."New value: +"Set true only when the user asked for exactly this action."
  2. First observedv2.0.0

TDQS

A3.9/5.0
Behavior5/5

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

Annotations only state destructive, non-idempotent, openWorld. The description adds substantial execution semantics beyond that: prevalidation, exact-hash verification before the first request, stop-on-first-failure behavior, and explicitly no retries, no rollback, no implicit continuation. It even names the failure payload shape (known results / failed index / unattempted indices).

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?

Two tight sentences, front-loaded with the scope and the confirmation/hash gate before the failure semantics. No filler. Slightly telegraphic ('Confirmed one-to-twenty ordered ... tasks') but every clause carries information.

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 destructive, non-idempotent batch executor with no output schema, the description covers the critical concerns: gating (confirm + hash), failure behavior, and partial-completion reporting. It does not describe the success return shape, but the failure contract is the higher-risk gap and it is covered.

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 the schema already documents tasks, account, confirm and review_sha256. The description restates the ordering and the 1-20 bound and the hash requirement, but adds no format or syntax detail beyond the structured fields, so 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?

States a specific resource and scope: executing 1-20 ordered subscriber/segment/workflow/custom-field tasks that were already reviewed. The verb is implicit (submit/execute) but the hash-verification requirement makes it distinguishable from preview_subscriber_batch. It is clear, though it never names the sibling that produces the hash.

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

Usage Guidelines3/5

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

Usage context is implied — this runs a batch that was previously previewed and confirmed — but the description never explicitly says 'use after preview_subscriber_batch' or when to prefer it over calling the individual sibling tools directly. The routing hint lives only in the schema's review_sha256 description, not the tool description.

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