flowforge-mcp

flowforge_start_call

Places one outbound phone call via a FlowForge assistant by supplying a destination number and assistant ID, returning a call ID for follow-up.

Instructions

Place a single outbound phone call using a FlowForge assistant.

Args: params: phone_number (E.164), assistant_id, optional caller_phone_number and template_variables.

Returns: JSON/Markdown with call_id (use it with flowforge_get_call), room_name, job_id and SIP identifiers.

Examples: - "Call +14155551234 with assistant abc" -> phone_number + assistant_id. - To personalize: template_variables={'customer_name': 'Alex'}.

Error Handling: Returns "Error: ..." (e.g. 404 if the assistant_id is unknown).

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_start_call"
  }
}

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.9/5.0

Behavior4/5

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

Annotations already declare the write, open-world, non-idempotent profile, so the description adds value with concrete error behavior (returns 'Error: ...', 404 for unknown assistant_id) and the return payload fields (call_id, room_name, job_id, SIP identifiers). It still doesn't state side effects like actual dialing, cost, or whether retries create duplicate calls — relevant since idempotentHint=false.

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?

Front-loaded one-line purpose followed by Args/Returns/Examples/Error Handling sections; each section earns its place. The example lines are somewhat redundant with the Args section but aid invocation.

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 an outbound-call trigger with an output schema and full annotations, the definition covers inputs, error mode, and follow-up tool. It could go further by noting that the call is actually placed immediately or by calling out why idempotency is false, but nothing critical is 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?

The Args section enumerates phone_number (E.164), assistant_id, and the two optional fields, but nearly all of this meaning is already present in the nested schema's property descriptions, and it omits response_format entirely. With the reported top-level schema coverage at 0%, the description partially compensates but leaves one parameter undocumented in prose.

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

Purpose5/5

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

States a specific verb and resource — 'Place a single outbound phone call using a FlowForge assistant' — and the word 'single' implicitly contrasts with the sibling flowforge_start_batch_calls. An agent can distinguish this from the batch and campaign tools without opening the schema.

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 by 'single outbound call', and it names flowforge_get_call as the follow-up for the returned call_id. However, it never explicitly says when to use this versus flowforge_start_batch_calls or campaign-based flows, and gives no prerequisites (e.g. the assistant must exist and be configured).

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

Deploy Server