Tessryx

Patch workflow

patch_workflow

Edit an EXISTING workflow's latest version in place without resending the whole definition. Apply ordered operations (set / remove / replace_in / test) addressed by step name + a dot-path (e.g. step 'generate' path 'llm.system'), passing new code or values as raw JSON — the platform owns the escaping, so you never hand-escape the definition. For a SMALL change to a LARGE value (swap a color, fix a word), use replace_in (find→replace, unique match) so you send a few bytes, not the whole value. For a large NEW value (an embedded HTML page, a long JS block) send it with value_encoding=base64 (or gzip+base64) and a value_sha256 — base64 avoids the escapes/multibyte chars that corrupt in transit, and the sha rejects the op if it was altered anyway, so the write can't silently ship broken. The patched result is statically validated BEFORE it is written: if validation fails, no version is created and the findings are returned (valid=false). On success a NEW version is minted from the latest (an unpublished draft unless publish=true) — so there's no separate preview step: just patch it, then run_workflow / preview the created draft to see it rendered. Use this to change one block; use create_workflow_version for a wholesale rewrite.

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	No	the workflow slug (provide this or workflow_id)
`publish`	No	publish the resulting version immediately (ignored if validation fails)
`operations`	Yes	ordered edits applied to the LATEST version's definition
`workflow_id`	No	the workflow id (provide this or slug)
`expected_content_sha256`	No	the content_sha256 from the get_workflow_version you built these operations from. The patch is rejected if the latest version has changed since — nothing is applied and no version is minted. REQUIRED when any path addresses an array element by numeric index (variables[0]), because that is a claim about the definition's current shape whose failure is otherwise SILENT: if an element shifted, the patch edits the wrong one. Optional for self-locating paths — variables[name=css], variables[-] (append), a step addressed by name, or a plain field path — which mean the same thing whatever the definition holds

Output Schema

TableJSON Schema

Name	Required	Description	Default
`valid`	Yes
`created`	Yes
`version`	No
`findings`	No
`published`	Yes
`workflow_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses that a new version is minted on success, that validation failures prevent any version creation, and that publish controls immediate publication. It also explains the integrity guarantees around sha256 checks, matching the non-readonly annotation without contradiction.

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?

The description is long and somewhat repetitive with the schema text, but the density is justified given the complexity of operations, encodings, and concurrency guards. The structure flows from general behavior to specific operation guidance.

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?

It fully explains the post-patch workflow, including validation results, version minting, and how to preview the resulting draft. Since an output schema exists, it appropriately avoids over-explaining return values while still covering failure and success behavior.

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

Parameters5/5

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

The schema already covers every parameter, and the description adds practical meaning around path selectors, appending with '[-]', encoding choices, and the expected_content_sha256 requirement. This goes beyond the schema by explaining when each form is required or optional.

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 the tool edits an existing workflow's latest version via ordered operations without resending the whole definition. It also distinguishes this from create_workflow_version for wholesale rewrites.

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 gives explicit guidance on when to use patch_workflow versus create_workflow_version, when to prefer replace_in for small changes to large values, and when to use base64/gzip+base64. Validation-before-write and the no-preview-step workflow are also clearly explained.

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

All Tessryx tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?