flowforge-mcp

flowforge_create_campaign

Create an outbound voice campaign by binding an AI agent and a phone number or pool, then optionally seed recipients and set dialing parameters.

Instructions

Create an outbound campaign.

Provide an agent_id to bind an assistant, a dialing source (phone_number_id or phone_pool_id), and optionally seed recipients. Use extra_config for any other campaign setting.

Args: params: See field descriptions.

Returns: The created campaign object (with its ID) as JSON or Markdown.

Error Handling: Returns "Error: Validation failed..." if fields are malformed.

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_create_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.5/5.0

Behavior3/5

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

Annotations already supply readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true. The description adds useful context beyond them: the response is the created campaign object including its ID, format is JSON or Markdown, and malformed fields yield a specific validation error string. It says nothing about permissions, duplicate-name behavior, or side effects of seeding recipients.

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 purpose sentence and the required-field setup are front-loaded, and the Args/Returns/Error Handling structure makes scanning easy. The RST double-backtick markup adds noise and the Args stanza is essentially a pointer, mildly diluting the density.

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 creates a loosely-typed object with many optional fields; the description covers required vs optional setup, the escape hatch for unlisted settings, the return shape, and error behavior, and an output schema exists so return values need no elaboration. Only permission and duplicate-handling details are missing.

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 coverage is reported as 0% at the top level, so the description must carry weight; it does explain that agent_id binds an assistant, that phone_number_id and phone_pool_id are alternative dialing sources, and that extra_config is a passthrough for other settings — meaning the schema itself does not convey. But "Args: params: See field descriptions" defers rather than documents, so the coverage is only partial.

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?

Opens with a specific verb+resource ("Create an outbound campaign") plus the scope word "outbound," which immediately separates it from read-side siblings like flowforge_list_campaigns and flowforge_get_campaign. It does not name any sibling explicitly, so the differentiation is implied by the verb rather than stated.

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?

Gives concrete configuration guidance (bind an assistant via agent_id, choose a dialing source, optionally seed recipients), which tells the agent how to call it successfully. It never states when to prefer this over alternatives such as flowforge_start_call, flowforge_start_batch_calls, or flowforge_create_assistant, and offers no when-not conditions.

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

Deploy Server