Skip to main content
Glama

workflow_update

Replace an existing workflow document with a new version. Owners commit directly to trunk (version+1); other actors create a branch for review before merge.

Instructions

全量替换 workflow 文档——owner 直改 trunk(version+1);非 owner 写 branch-{actor}(trunk 不动,等审阅合并)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorYes操作者(=owner 直改 trunk;否则开 branch)
data_dirNo数据根目录(缺省走 getDataDir 解析链)
workflowYesworkflow 文档(与 workflow_create 同构,name 必填)
workflow_idYesworkflow 标识

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the key behaviors: owner directly modifies trunk with version+1, non-owner writes to branch-{actor} and waits for review merge. It also states 'full replacement', implying destructive overwrite. This is substantial transparency, though it doesn't cover error handling, idempotency, or return values.

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 a single, dense sentence that front-loads the core operation ('full replacement') and then explains the branching logic. Every clause earns its place, with no filler or redundancy. It is efficiently structured and immediately actionable.

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

Completeness2/5

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

For a mutation tool with no output schema and no annotations, the description omits several critical details: it does not specify return values (e.g., success/error), preconditions (e.g., workflow must exist), or side effects beyond the branch creation. It also fails to position itself against sibling tools, leaving the agent without full context for safe invocation. The core logic is clear, but completeness is lacking for a tool of this complexity.

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 description coverage is 100%, so the schema already documents all parameters. The description repeats the actor semantics ('owner vs non-owner') that are already in the schema, adding no new parameter-level insight. It does not elaborate on workflow_id, workflow, or data_dir beyond what the schema states, so it meets the baseline but adds little extra value.

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 clearly states a specific verb and resource: 'full replacement of workflow document'. It distinguishes from sibling tools like workflow_create (which implies creating new) and workflow_node_add (which implies adding nodes) by specifying 'full replacement'. The owner/non-owner branching further clarifies the scope, making the purpose unmistakable.

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 description explains the internal behavior (owner vs non-owner) but does not explicitly state when to use this tool versus alternatives like workflow_create or workflow_node_add. The term 'full replacement' implies it's for existing workflows, but no explicit 'use this when...' guidance is provided. It lacks a clear contrast with siblings, leaving the agent to infer the usage context.

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

Deploy Server

Other Tools