Skip to main content
Glama
Sign In
Flodesk MCP Server

Flodesk MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Publish a Studio email export as a draft campaign.

publish_studio_email
Destructive

Publish a Studio email export as a draft Flodesk campaign for review before sending.

Instructions

Publish a Studio email export as a draft campaign.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "publish_studio_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
htmlNo
titleNo
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.
asset_idNo
campaign_idNo
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

D1.9/5.0
Behavior2/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 partly covered. The description adds nothing beyond the title: it does not explain the confirm requirement, account scoping, rate/auth constraints, or what the destructive behavior actually affects (existing drafts, campaigns).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is one short sentence with nothing wasted, but that brevity is under-specification rather than economy — the whole sentence is the title restated, so no informational content is front-loaded for the agent to use.

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

Completeness1/5

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

For a non-idempotent, destructive, open-world mutation tool with a nested payload object, 8 parameters, and mutually exclusive body encodings, a single title sentence is wholly inadequate; no output schema exists to offload return-value explanation either.

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

Parameters2/5

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

Schema coverage is only 50% across 8 parameters including a nested object. The description never mentions html, title, asset_id, campaign_id, payload, payload_file, or the confirm guardrail, so it does not compensate for the undocumented half of the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance is given, and no alternative is named. The presence of publish_canva_email as a sibling makes this omission meaningful, and the mandatory-ish 'confirm' semantics implied by the schema are never mentioned.

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