flowforge-mcp

flowforge_update_assistant

Idempotent

Update an existing voice assistant by supplying its ID and only the fields to change; unspecified fields remain unchanged. Returns the updated assistant as JSON or Markdown.

Instructions

Update an existing assistant. Only the fields you supply are changed.

Args: params: assistant_id and a fields object of changes.

Returns: The updated assistant object as JSON or Markdown.

Error Handling: Returns "Error: Resource not found..." if the ID is wrong.

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

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

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, so the safety profile is covered and the description is consistent with it. The description adds real value by stating patch semantics (only supplied keys change) and a concrete error case ('Error: Resource not found...'), but says nothing about permissions, effects on in-progress calls, or how clearing a field works.

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

Conciseness3/5

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

The lead sentence is front-loaded and useful, but the remainder is raw docstring boilerplate (Args/Returns/Error Handling) and the Returns line restates behavior already captured by the schema's response_format descriptions. It stays short, yet some sections do not earn their place.

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

Completeness3/5

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

An output schema exists, so the return-value explanation was not strictly needed, and error handling is a genuine addition. Gaps remain for a mutation tool: whether fields can be cleared/nullified, whether updates affect active assistants, and what happens on invalid field names are all unaddressed.

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?

Reported schema coverage is 0%, largely because the top-level 'params' wrapper is undocumented, and the description does cover that wrapper by naming assistant_id and a fields object. However it adds nothing about response_format or about valid field names/values beyond what the nested schema already spells out, so it only partially compensates.

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?

The first sentence gives a specific verb and resource ('Update an existing assistant') plus the partial-update scope ('Only the fields you supply are changed'). It is distinguishable from flowforge_create_assistant and flowforge_delete_assistant by the verb alone, though no sibling is named.

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?

There is no explicit when-to-use guidance, no prerequisites naming (e.g. the assistant must already exist and be listed via flowforge_list_assistants), and no routing to alternatives such as flowforge_create_assistant or flowforge_assistant_lifecycle. Usage is only implied by the word 'update'.

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

Deploy Server