Skip to main content
Glama
Sign In

neonloops

by com.neonloops
OverviewDiscussionsAdmin

Workflows: edit

workflows_edit
Destructive

Changes an existing neonloops workflow's draft: adds, configures, connects, removes or renames steps and edges, tidies the layout, and sets the name, description, status, project or cost cap. Make a draft with workflows_create and read it with workflows_get first; runs_test_draft tries the result and workflows_publish makes it live. Operations run in order and save in one write against the revision you pass: when one is refused none applies, and a change made since your read is never overwritten. Settings are saved after the checks and before the operations. A removed step is gone; re-adding it makes a new step and id. The answer gives the new revision, the ids of new steps and edges, and whether a run would accept the graph.

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": {
      "workflow_id": "<workflow_id>"
    },
    "name": "workflows_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
revisionNoNeeded with operations: the revision from workflows_get or the previous workflows_edit answer, passed back exactly as it came. If the graph changed since, the operations are refused, not merged. Settings alone need none.
settingsNoSettings to change. They are saved once the revision and every operation have passed their checks, and before the operations are written: a refused check saves nothing, and a write refused after that leaves them saved.
operationsNoGraph changes, applied in this order and saved in one write: all of them, or none when one is refused (the refusal names its index). A step added here is connected or configured in a later call, by the id this answer returns.
workflow_idYesThe workflow to change.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the destructive and open-world annotations, the description explains atomic all-or-nothing operation execution, revision-based conflict refusal, and the ordering of settings saves versus operation writes. It also discloses that removed steps are gone, re-adding creates a new step and id, and the response includes the new revision, new ids, and whether a run would accept the graph.

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?

The description is dense but front-loaded, starting with the core purpose before prerequisites, transactional behavior, removal semantics, and response contents. Each sentence contributes relevant operational context for a complex editing tool, with no obvious filler.

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

Completeness5/5

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

Given the complex nested schema, destructive editing behavior, and absence of an output schema, the description supplies the missing high-level context: atomic writes, revision conflicts, settings ordering, removal consequences, and the shape of the answer. An agent has enough information to choose the tool and understand the key risks before invoking it.

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

Parameters4/5

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

The input schema already has 100% description coverage and thoroughly documents parameters, so the description's main added value is cross-parameter execution semantics: operations run in order and save together, revision conflicts are refused rather than merged, and settings are saved after checks but before operations. These are meaningful clarifications beyond individual field descriptions, though much parameter detail remains in the schema.

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?

The description states a specific verb and resource: it changes an existing workflow's draft by adding, configuring, connecting, removing, or renaming steps and edges, tidying layout, and updating settings. It clearly distinguishes editing from creating, reading, testing, and publishing through references to workflows_create, workflows_get, runs_test_draft, and workflows_publish.

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

Usage Guidelines5/5

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

It explicitly tells the agent to create a draft with workflows_create and read it with workflows_get first, then use runs_test_draft and workflows_publish for testing and publication. These named alternatives and prerequisites make when-to-use guidance direct and unambiguous.

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

All neonloops toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources