Skip to main content
Glama
usewrit

writ-mcp

Official
by usewrit
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Edit a saved workflow

writ_update_workflow
Destructive

Inspect or customize an existing saved workflow in place: edit settings, patch recorded steps, or rebuild its agent skill (SKILL.md) without recreating it.

Instructions

Inspect or completely customize an existing saved workflow in place. An edit answers with a compact outline of the steps (verbose=true for the full definition). An api_call step is {type:'api_call', config:{function_name, method, url, headers, body_template, response_extractions}} — function_name binds the step to the function of that name, which is what writ_run_workflow function_name selects. With no edit arguments, returns the full workflow and its zero-based step indexes. patch changes workflow settings including persona, residential egress/country, human behavior, headless/fast mode, device routing, timeouts, retries, schedules, auth/browser config, functions, streaming, sessions and raw replay. step_updates recursively edits one or more recorded steps (selectors, scripts, URLs, waits, flags, extraction config, and generic api_call.config.flow programs); replace_steps deliberately replaces the complete step list. AGENT SKILL: skill_md (in the read) is the SKILL.md that teaches an agent to call this workflow over MCP; regenerate_skill=true rebuilds it from the current functions, then patch.skill_md writes your edited version (YAML frontmatter name + description, then Markdown); patch.skill_md=null removes it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patchNoSparse settings patch. Supports every WorkflowUpdate field except credentials and captured recorded_session material; use vault/persona/session management for those.
verboseNoAnswer an edit with the full workflow definition instead of the compact step outline (default false).
workflowNoWorkflow name (or use workflow_id).
workflow_idNo
step_updatesNo
replace_stepsNoComplete recorded-step replacement. Prefer step_updates for a targeted edit.
regenerate_skillNoRebuild the workflow's agent skill (SKILL.md) from its current functions, inputs and sign-in, replacing any edited version; the answer carries the new skill_md. Runs after any patch in the same call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already mark destructiveHint=true and readOnlyHint=false, so the description correctly implies mutation and the ability to replace steps. The description adds critical context: 'replace_steps deliberately replaces the complete step list', and details on patch fields and skill regeneration. It doesn't elaborate on permissions or side effects like data loss, but with annotations covering the safety profile, this is strong.

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 description is dense and front-loads the core purpose, but it is quite long and includes detailed technical examples (api_call structure) that could be moved to a separate section. Some sentences are lengthy and could be split for clarity, but overall it is informative without excessive fluff.

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?

Given the tool's complexity (7 parameters, nested objects, many patch fields), the description covers key behaviors: read vs edit, verbose mode, step_updates vs replace_steps, skill regeneration, and patch scope. It lacks explicit prerequisites (e.g., authentication needs) and error handling, but with no output schema and schema at 71%, it is largely complete for an agent to call correctly.

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?

Schema coverage is 71%, so there is some gap. The description adds meaning beyond schema: it explains that patch changes settings including a long list of specific fields; that step_updates recursively edits steps with examples (selectors, scripts, URLs, waits, flags, extraction config); and clarifies the api_call step structure with config fields. This compensates for the schema gap effectively, though not exhaustively.

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 ('Inspect or completely customize') and resource ('existing saved workflow in place'), and differentiates itself from siblings by naming writ_run_workflow function_name binding. An agent can tell this is the edit tool, distinct from writ_list_workflows or writ_run_workflow.

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

Usage Guidelines4/5

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

Provides clear context: 'With no edit arguments, returns the full workflow', 'Prefer step_updates for a targeted edit', and explains replace_steps vs step_updates. However, it doesn't explicitly state when-not-to-use (e.g., for creation, use a different tool) or list alternatives beyond replace_steps.

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