flowforge-mcp

flowforge_control_campaign

Start, stop, pause, resume, or clone a campaign by ID to control when voice-agent calling runs. Returns updated status or the cloned campaign, with error messages on invalid state changes.

Instructions

Change a campaign's run state: start, stop, pause, resume, or clone it.

Args: params: campaign_id and action.

Returns: The API result (e.g. updated status, or the clone object).

Error Handling: Returns "Error: ..." on failure (e.g. resuming a non-paused campaign).

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": {
      "params": "<params>"
    },
    "name": "flowforge_control_campaign"
  }
}

Input Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 6, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. Beyond that, the description adds real value: it states the return shape ('updated status, or the clone object') and documents the "Error: ..." failure convention with a concrete precondition example. It still omits that clone creates a new campaign object and whether stop terminates in-flight calls, which are notable side effects.

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?

Four tight lines with a front-loaded purpose sentence followed by Args/Returns/Error blocks. Nothing is padded, and the structure maps directly onto what an agent needs before calling.

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?

The tool is small (one nested params object, three inner fields) and an output schema exists, so return values need little elaboration. The definition covers purpose, required inputs, return shape, and failure behavior; the main gaps are the undocumented response_format and the copy semantics of clone.

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?

Top-level schema description coverage is 0% (the 'params' object carries no description), so the description must compensate. It names campaign_id and action but omits response_format entirely, even though that parameter materially affects output and is only documented inside the nested schema.

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?

Uses a specific verb ('Change') plus resource ('a campaign's run state') and enumerates the five concrete actions (start, stop, pause, resume, clone). This implicitly separates it from siblings like update_campaign_settings, delete_campaign, and get_campaign, but it never names those siblings to make the boundary explicit.

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?

The phrase 'Change a campaign's run state' implies the use case, and the error note ('resuming a non-paused campaign') hints at a precondition. However, there is no explicit when-to-use/when-not-to-use guidance and no pointer to update_campaign_settings for non-run-state changes, leaving the agent to infer the boundary.

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

Deploy Server