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. Dates show when Glama detected each change.

First observedSep 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The sparse annotations (openWorldHint=false, destructiveHint=false) are meaningfully extended: the description discloses validation-before-write ("statically validated BEFORE it is written: if validation fails, no version is created"), non-destructive version minting ("a NEW version is minted from the latest (an unpublished draft unless publish=true)"), and transmission-integrity guarantees ("the write can't silently ship broken"). This is consistent with destructiveHint=false — the original version survives as a prior version. Substantial behavioral context is added beyond the annotations.

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 (~200 words) but front-loaded with the core purpose, and every subsequent sentence earns its place by covering a distinct decision: escaping ownership, encoding choice by payload size, validation-before-write safety, draft-minting outcome, and sibling routing. The logical flow — what → how → strategy → safety → result → alternative — is coherent. Only minor redundancy with the schema (publish=true semantics) keeps it from a 5.

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?

This is a complex tool (5 top-level parameters, an 8-field operations array, 4 op types, integrity hashes, and a staleness guard), yet the description covers the strategic layer — addressing by step name + dot-path, encoding choices, validation-before-write, latest-version semantics — while the 100%-covered schema and output schema carry parameter and return details. An agent has everything needed to select the correct op, encoding, and guard parameters. Nothing material is left to inference.

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 description coverage is 100%, so the schema already documents every parameter; per the baseline, the description gets credit only for added meaning. It adds decision strategy that maps to parameters: when to use value_encoding=base64/gzip+base64 vs utf8 (large text avoiding corrupting escapes), when value_sha256 is needed (transmission verification), and when replace_in vs set is cheaper (payload sizing). It does not redundantly restate schema text, though the strategic guidance is a tier above merely adequate.

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 first sentence states a precise verb-resource-scope: "Edit an EXISTING workflow's latest version in place without resending the whole definition." It is clearly differentiated from the closest sibling: "Use this to change one block; use create_workflow_version for a wholesale rewrite," and the "without resending the whole definition" phrasing implicitly separates it from update_workflow. An agent can route correctly without opening any schema.

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?

Explicit when-to-use guidance abounds: "Use this to change one block; use create_workflow_version for a wholesale rewrite." It also provides intra-tool selection rules — "use replace_in (find→replace, unique match) so you send a few bytes" for small changes to large values, base64/gzip+base64 with value_sha256 for large new values, and run_workflow/preview on the resulting draft. Both exclusions and named alternatives are present.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Every resource family follows the same verb+noun pattern and each tool name uniquely identifies a resource-action pair (create_app vs create_app_version vs update_app vs publish_app). Closest overlaps like analyze_resource vs get_resource_graph and patch_datafile vs update_datafile are explicitly differentiated by their descriptions, so misselection risk is low despite the scale.

Naming Consistency5/5

Names are almost uniformly verb_noun snake_case with a consistent lifecycle vocabulary: create/get/update/delete/list/publish/unpublish/version. Minor outliers like whoami and run_schedule_now are idiomatic and do not break the predictability of the set.

Tool Count1/5

At 93 tools this far exceeds the calibration's 50+ extreme-mismatch case. The count is inflated by repeating create/get/update/delete/version/publish/unpublish across ten resource families; even though each family is systematic, the combined surface is very hard for an agent to navigate and keep in context.

Completeness4/5

Core CRUD/publish/version lifecycles are present for apps, workflows, endpoints, schedules, schemas, datafiles, and api templates, and dependency analysis is well covered. However, secret creation/updating, asset upload, custom-domain deletion, and version-range enumeration for several resource types are absent or left to the external dashboard, so agents hit a few manual dead ends.

Resources

Need Help?