analyze_resource
ChatGPTCheck whether a resource and everything it depends on is sound — the deployability question. Pass 'hypothetical' to preview a change instead: hypothetical='delete' or 'unpublish' reports what would break WITHOUT changing anything (run it before deleting something other resources may use), and hypothetical='publish' checks whether the draft you are about to publish actually resolves. An APP is the usual subject: it walks every root the app contains (endpoints, schedules, domains) to the end of each chain and reports what would break. Returns findings {resource, path, severity, check, message}: errors are broken now (a reference that does not resolve, a dependency never published, a declared domain that routes elsewhere, a step naming a resource outside its workflow's scope, a call to a workflow that continues, which cannot run as a sub-workflow), warnings are risks (a published resource following @latest, a sub-workflow call cycle, a domain not yet verified, a sub-workflow step that the scope it runs under for one caller will refuse), info is advisory. deployable is true when there are no errors. Also reports incomplete_nodes: resources whose references are built at run time and so cannot be checked statically. For a non-root subject like a workflow, analysis starts there rather than from whatever reaches it, so severities are not weighted by reachability.
create_api_template
ChatGPTApi template authoring — create a BRAND-NEW api template (mints the template + its version 1). Fetch the definition's JSON Schema with get_api_template_definition_schema and author against it. Iterate with execute_api_template before wiring the template into a workflow; pass publish=true to publish in the same step once you're happy. (To add a version to an api template that already exists, use create_api_template_version.)
create_api_template_version
ChatGPTApi template versioning — add a new version to an EXISTING api template (by template_id) to evolve an api template you already created. Author the new version's definition against the schema from get_api_template_definition_schema. Pass publish=true to publish this api template version immediately. (For a brand-new api template, use create_api_template.)
create_app
ChatGPTApp authoring — create a BRAND-NEW app (mints the app + its version 1). Start here when building a page or an API bundle: choose the app's slug (its folder prefix, e.g. 'storefront'), then author each member resource under that prefix (storefront/page, storefront/products, storefront/checkout, …) so the app's prefix rule captures them automatically — you never hand-add members. The definition holds the membership selector (prefix rules + includes/excludes) and display; fetch its JSON Schema with get_app_definition_schema and author against it. An empty definition is a valid draft, but publishing requires a membership that selects something. Pass publish=true to publish v1 immediately. (To add a version to an existing app, use create_app_version.)
create_app_version
ChatGPTApp versioning — add a new version to an EXISTING app (by app_id) to change its membership selector (prefix rules, includes/excludes) or display. Author the new version's definition against the schema from get_app_definition_schema. Pass publish=true to make it the live manifest immediately. (For a brand-new app, use create_app.)
create_custom_domain
ChatGPTClaim a custom hostname for this tenant and generate its DNS challenge. The claim alone grants NOTHING until ownership is proven — it returns TWO DNS records (an ownership TXT and a permanent routing CNAME) in dns_records that the customer must add at their DNS provider. Present those records to the human, wait for them to add them, then call verify_custom_domain. slug_prefix/root_endpoint are optional here and are usually set later with update_custom_domain (after the domain verifies).
create_datafile
ChatGPTCreate a new datafile holding a JSON object. A datafile MUST be bound to a schema (schema_id) — the schema validates the JSON and generates the human editor; author or pick one with the schema tools first. Property order in json is preserved verbatim. Publish it with publish_datafile to serve it from the CDN.
create_dynamic_endpoint
ChatGPTDynamic endpoint authoring — create a BRAND-NEW dynamic endpoint (mints the endpoint + its version 1). The definition binds the endpoint to a workflow (by versioned-slug reference) plus a cache setting; fetch its JSON Schema with get_dynamic_endpoint_definition_schema and author against it. Pass publish=true to take the endpoint live in one step, or publish later with publish_dynamic_endpoint. (To add a version to a dynamic endpoint that already exists, use create_dynamic_endpoint_version.)
create_dynamic_endpoint_version
ChatGPTDynamic endpoint versioning — add a new version to an EXISTING dynamic endpoint (by endpoint_id) to evolve a dynamic endpoint you already created. Author the new version's definition against the schema from get_dynamic_endpoint_definition_schema. Pass publish=true to take this dynamic endpoint version live immediately. (For a brand-new dynamic endpoint, use create_dynamic_endpoint.)
create_schedule
ChatGPTSchedule authoring — create a BRAND-NEW schedule (mints the schedule + its version 1). The definition names a workflow (versioned-slug ref, published/latest), a recurrence (EITHER a 5-field cron + IANA timezone, OR an 'every N minutes/hours' interval), and an optional static input bound as the workflow's $input on every fire; fetch its JSON Schema with get_schedule_definition_schema and author against it. Pass publish=true to activate it (start firing) in one step, or publish later with publish_schedule. (To add a version to a schedule that already exists, use create_schedule_version.)
create_schedule_version
ChatGPTSchedule versioning — add a new version to an EXISTING schedule (by schedule_id) to change its cron, timezone, workflow, or input. Author the new version's definition against the schema from get_schedule_definition_schema. Pass publish=true to activate this version immediately. (For a brand-new schedule, use create_schedule.)
create_schema
ChatGPTSchema authoring — create a BRAND-NEW schema (mints the schema + its version 1). json_schema is the JSON Schema body datafiles bound to this schema (by schema_id) are validated against; property order is preserved exactly — it sets the field order of the generated editor, so author it in the order you want humans to see. Media uploads, entity references, cron and colors need an x-tessryx-ui hint or they render as bare text — get_guide("schemas"). Pass publish=true to publish schema version 1 immediately (the version datafiles resolve by default), or later with publish_schema. (To add a version to a schema that already exists, use create_schema_version.)
create_schema_version
ChatGPTSchema versioning — add a new version to an EXISTING schema (by schema_id) to evolve a schema you already created. Property order in the new schema version is preserved verbatim (it drives the generated editor's field order). Media uploads, entity references, cron and colors need an x-tessryx-ui hint or they render as bare text — get_guide("schemas"). publish_schema (or publish=true here) chooses which schema version is live. (For a brand-new schema, use create_schema.)
create_workflow
ChatGPTWorkflow authoring — create a BRAND-NEW workflow (mints the workflow + its version 1). A workflow composes blocks (api_call, sub_workflow, data) over $input and returns {content_type, output}. Fetch the definition's JSON Schema with get_workflow_definition_schema and author against it. The definition is statically validated BEFORE it is written: on error-severity findings nothing is minted (valid=false, created=false, findings returned) — so you never need a separate validate_workflow pass. On success the result also carries any advisory (warning/info) findings, e.g. a bare identifier that should be $-prefixed, or literal text better authored with language "literal". Pass publish=true to create and publish in one step. (To add a version to a workflow that already exists, use create_workflow_version.)
create_workflow_version
ChatGPTWorkflow versioning — add a new version to an EXISTING workflow (by workflow_id) to evolve a workflow you already created. Author the new version's definition against the schema from get_workflow_definition_schema. Like create_workflow, the definition is statically validated BEFORE it is written: error-severity findings mint nothing (valid=false, created=false), and a successful write returns any advisory (warning/info) findings. Pass publish=true to publish this workflow version immediately, or later with publish_workflow. (For a brand-new workflow, use create_workflow.)
delete_api_template
ChatGPTPermanently delete an api template and all its versions. Cannot be undone; a workflow api_call that references it fails cleanly at run time.
delete_app
ChatGPTPermanently delete an app and all its versions. This cannot be undone. It deletes only the app (the lens) — its member resources are untouched and continue to exist on their own. To simply hide the app without deleting, use unpublish_app.
delete_datafile
ChatGPTPermanently delete a datafile (unpublishing it from the CDN first if published). Cannot be undone; anything referencing it is left dangling and degrades.
delete_dynamic_endpoint
ChatGPTPermanently delete a dynamic endpoint. Unlike unpublish, this removes the resource entirely — it no longer appears in list_dynamic_endpoints. Cannot be undone. Nothing purges cached copies: the edge can keep serving its copy of the public URL until the endpoint's s_maxage_seconds run out.
delete_schedule
ChatGPTPermanently delete a schedule and all its versions and run history. This cannot be undone. To simply stop it firing without deleting, use unpublish_schedule.
delete_schema
ChatGPTPermanently delete a schema and all its versions. Cannot be undone; datafiles or workflows bound to it keep the dangling reference and simply skip schema validation.
delete_workflow
ChatGPTPermanently delete a workflow and all its versions. Cannot be undone; endpoints or sub_workflow references to it fail cleanly at run/serve time.
execute_api_template
ChatGPTExecute an api template live against the given variables and return the full trace: the rendered request (method, url, headers, body) and the response (status, headers, body, duration). Use this to debug a template before wiring it into a workflow. This runs the real outbound request.
get_api_template
ChatGPTGet a single api template by slug or id, including the definition body of its current version (published if any, else latest). Use get_api_template_version to read a specific older version.
get_api_template_definition_schema
ChatGPTGet the JSON Schema an api template definition must satisfy. Fetch this before authoring the definition for create_api_template / create_api_template_version.
get_api_template_version
ChatGPTRead back the full stored definition of an api template version by slug or id. Returns the exact definition body that was authored (as a JSON string, so you can parse it to diff or patch and resubmit as a new version) plus its checksum. Omit version to get the latest version.
get_app
ChatGPTGet a single app by slug or id. Returns its metadata plus published_manifest — the TYPED selector of its last-published version (membership prefix rules + includes/excludes, and display), so you can read the app's shape from concrete fields. published_manifest is absent when the app is unpublished; to read/edit the raw definition body (draft or any version) use get_app_version.
get_app_definition_schema
ChatGPTGet the JSON Schema an app definition must satisfy: the membership SELECTOR (prefix rules — a slug folder + the member kinds it covers — plus explicit includes/excludes) and display metadata. Fetch this before authoring the definition for create_app / create_app_version.
get_app_members
ChatGPTResolve an app's LIVE member set — the concrete resources its selector currently matches. The app stores only rules (prefix rules + includes/excludes); this fans out to each member kind's list and returns the resolved union(prefixes) + includes − excludes as {kind, slug, display_name}. Members are always current (a lens, not a pinned list). Resolves the published version by default; pass version to preview a draft's members before publishing. A kind with too many members to list (a blog's datafiles run to thousands) is NOT enumerated: it is omitted from members entirely and reported under summarized_kinds as a count plus a per-folder rollup, and members_complete is then false — so count can exceed members length. To see the items of a summarized kind, call that kind's own list tool with one of the reported slug_prefix values (e.g. list_datafiles); this tool never pages a whole collection. Use this to see or verify what an app contains.
get_app_version
ChatGPTRead back the full stored definition of an app version by slug or id. Returns the exact definition body that was authored (as a JSON string, so you can parse it to diff or edit and resubmit as a new version) plus its checksum. Omit version to get the latest version. This is the EDITING view; get_app returns the typed published manifest for reading.
get_asset
ChatGPTGet a single published asset by slug or media id, including its absolute CDN URL, content type, and size. Use this to confirm an asset exists and fetch the URL to embed.
get_custom_domain
ChatGPTGet a single custom domain by hostname: its lifecycle status, the DNS records the customer must publish, its routing (slug_prefix + root_endpoint), and any human-facing check/certificate messages. Use this to answer 'is my domain live yet?' and to re-display the DNS records for a pending domain.
get_datafile
ChatGPTGet a single datafile by slug or id, including its JSON content and last published CDN path.
get_dynamic_endpoint
ChatGPTGet a single dynamic endpoint by slug or id, including its public URL and the definition body of its current version (published if any, else latest). Use get_dynamic_endpoint_version to read a specific older version.
get_dynamic_endpoint_definition_schema
ChatGPTGet the JSON Schema a dynamic endpoint definition must satisfy. Fetch this before authoring the definition for create_dynamic_endpoint / create_dynamic_endpoint_version.
get_dynamic_endpoint_version
ChatGPTRead back the full stored definition of a dynamic endpoint version by slug or id. Returns the exact definition body that was authored (as a JSON string, so you can parse it to diff or patch and resubmit as a new version) plus its checksum. Omit version to get the latest version.
get_guide
ChatGPTFetch a Tessryx guide by topic (markdown). Use list_guides to see the available topics. Reach for the relevant guide before authoring to avoid trial-and-error.
get_resource_graph
ChatGPTBrowse how resources connect, in either direction. direction 'depends_on' (default) shows what this resource NEEDS, following 'depth' hops (default 3). direction 'depended_on_by' shows what would BREAK if you changed or deleted it — transitive and not depth-limited, since the chain (api template → the workflows calling it → the endpoints running those) is the answer; use it before a delete or a breaking edit. Each edge carries the reference text as authored, whether it names @published or @latest, and what that resolves to right now, so version drift is visible and not just connectivity. Check unscanned_kinds on a reverse result: a schema's referrers include every datafile and are too expensive to enumerate, so an empty answer there does NOT mean nothing depends on it. To find out whether something is broken rather than what it connects to, use analyze_resource.
get_schedule
ChatGPTGet a single schedule by slug or id, including its cron status (last_published_version, next_run_at, last_run_id) and the definition body of its current version (published if any, else latest). Use get_schedule_version to read a specific older version.
get_schedule_definition_schema
ChatGPTGet the JSON Schema a schedule definition must satisfy (workflow reference; recurrence as EITHER a 5-field cron + IANA timezone OR an 'every N minutes/hours' interval; optional static input). Fetch this before authoring the definition for create_schedule / create_schedule_version.
get_schedule_version
ChatGPTRead back the full stored definition of a schedule version by slug or id. Returns the exact definition body that was authored (as a JSON string, so you can parse it to diff or patch and resubmit as a new version) plus its checksum. Omit version to get the latest version.
get_schema
ChatGPTGet a single schema by slug or id, including the JSON Schema body of its current version — use it to author a datafile that conforms.
get_secret
ChatGPTGet a single secret by slug or id (metadata only — the value is never returned; value_preview is a non-sensitive hint such as the last few characters). To add or change a secret's value, send the user to https://tessryx.io/dashboard/secrets; it cannot be set through this assistant.
get_workflow
ChatGPTGet a single workflow by slug or id, including the definition body of its current version (published if any, else latest) and its latest/last-published version numbers. Use get_workflow_version to read a specific older version.
get_workflow_definition_schema
ChatGPTGet the JSON Schema a workflow definition must satisfy. Fetch this before authoring the definition for create_workflow / create_workflow_version.
get_workflow_run
ChatGPTGet the stored record of a past workflow run by run id: status, content_type, and the output (decoded as a string; output_truncated is true when the stored output was sampled down). Runs from a LIVE ENDPOINT SERVE keep only the first few KB of the page — re-run or preview the endpoint to see a whole render. Runs you triggered (run_workflow, preview) store their output in full.
get_workflow_run_traces
ChatGPTGet the full per-step execution trace of a run by run id (paged). Each step lists its blocks with the input each consumed and the output it produced, plus any error_message, and the variable scope captured at that step. Use this to debug why an expression or block produced the wrong value. Large captured values are shortened, with a marker saying so: a scope entry may point at the block output beside it rather than repeat it (the value is in the same trace). On UNATTENDED runs only — a live endpoint serve, a schedule falling due — text copied verbatim from the definition (a literal expression) is also replaced by its path there; read it with get_workflow_version. Those runs are shortened harder overall too, so to capture a value in full, re-run it yourself (run_workflow / preview_dynamic_endpoint / run_schedule_now) — runs you trigger keep everything, literals included. A loop block, and an llm block with tools (an agent), lists iterations: each loop iteration or agent turn with the blocks it ran (iterations_total is how many actually ran; a long run keeps the first and last and may drop some between). For an agent turn the first block is an llm block recording that one model call — its output carries stop_reason, input/output tokens, tool_calls and the start of the reply, and started_at/finished_at give how long the call took — followed by the tools it called.
get_workflow_version
ChatGPTRead back the full stored definition of a workflow version by slug or id. Returns the exact definition body that was authored (as a JSON string, so you can parse it to diff or patch and resubmit as a new version) plus its content_sha256. Omit version to get the latest version.
list_api_templates
ChatGPTList the api templates belonging to the authenticated tenant. An api template is a reusable, parameterized HTTP or gRPC request a workflow invokes to reach an external system.
list_app_versions
ChatGPTGet the earliest and latest version numbers of an app (by slug or id), to know the range you can fetch with get_app_version.
list_apps
ChatGPTList the apps belonging to the authenticated tenant. An APP is the foremost organizing container — a versioned, publishable grouping of resources (schemas, datafiles, api templates, workflows, dynamic endpoints, schedules) that share a slug-folder prefix, e.g. everything under 'storefront/'. When building a new page or a shared-API bundle, work inside an app: pick its slug prefix, then author each resource under that prefix so it is captured automatically. Returns summaries; fetch one with get_app.
list_assets
ChatGPTList the binary assets (images, files) this tenant has published to the media CDN, with each asset's absolute URL. Supports a slug-prefix browse and pagination. Assets are produced by a workflow's asset block; use this to see what has already been published and to get an asset's URL to embed in a page. If the image or file you need is not here, send the user to https://tessryx.io/dashboard/media to upload it — you cannot upload a binary the user has not given you.
list_custom_domains
ChatGPTList the custom domains claimed by the authenticated tenant. A custom domain serves the tenant's dynamic endpoints on the customer's own hostname (shop.customer.com) instead of the default <tenant>.tessryx.app/<slug> URL. Optionally filter by lifecycle status (PENDING, VERIFIED, CERT_PENDING, ACTIVE).
list_datafiles
ChatGPTList the datafiles belonging to the authenticated tenant. A datafile is a published JSON object served from a CDN — the data layer a page can fetch and hydrate from.
list_dynamic_endpoint_runs
ChatGPTList a dynamic endpoint's recent EXECUTIONS, newest-first — the place to look when a live page is broken. Each item carries the outcome (status + the failure message the public URL hides behind a 500) plus request_path, the resolved path including any :param values, so you can see WHICH request failed on a parameterised endpoint. run_id resolves to the full run and its step traces via get_workflow_run / get_workflow_run_traces. Only cache MISSES that reached the origin appear here, so this is renders, not traffic; history is kept for about two weeks. Defaults to live serves — pass previews=true for the editor-preview history instead.
list_dynamic_endpoints
ChatGPTList the dynamic endpoints belonging to the authenticated tenant. A dynamic endpoint binds a public URL to a workflow; it is both a page render and a callable API route.
list_guides
ChatGPTList the available Tessryx guides (topic + what each covers). Read a guide with get_guide before building something you're unsure how to model — they cover the platform overview, an end-to-end page recipe, and the authoring lifecycle.
list_runs
ChatGPTList a workflow's past runs, most-recent-first, by workflow id. Optionally filter by status (succeeded, failed, running, cancelled). Returns run summaries (run_id, status, message, timestamps); use get_workflow_run for a run's output or get_workflow_run_traces for per-step detail.
list_schedule_runs
ChatGPTList a schedule's fire history, newest-first. Each item is a thin REFERENCE to a workflow run (run_id + the cron slot it fired for) — resolve its status/output/traces with the workflow run tools (get_workflow_run / get_workflow_run_traces). An AUTOMATIC fire is stored as a diagnosis, not an archive: its status, message, failing step and a head of each captured value are kept, but the output is sampled (output_truncated) and large trace values are shortened. Use run_schedule_now to capture a firing in full.
list_schedule_versions
ChatGPTGet the earliest and latest version numbers of a schedule (by slug or id), to know the range you can fetch with get_schedule_version.
list_schedules
ChatGPTList the schedules belonging to the authenticated tenant. A schedule is "cron for workflows": it runs a workflow on a recurring cron. Returns summaries (no definition body); fetch a body with get_schedule / get_schedule_version.
list_schemas
ChatGPTList the schemas belonging to the authenticated tenant. Schemas are JSON Schemas that datafiles validate against; reference one by schema_id when creating a datafile.
list_secrets
ChatGPTList the secrets belonging to the authenticated tenant (metadata only — never the secret value). A secret is a stored credential (API key, token) that an api template references by slug in its auth block to inject on outbound calls. Use this to discover which secrets exist so you can wire an api template's auth.secret to the right slug. If the secret you need does not exist yet, send the user to https://tessryx.io/dashboard/secrets to create it — secrets cannot be created or set through this assistant.
list_workflows
ChatGPTList the workflows belonging to the authenticated tenant. Supports an optional slug prefix filter and pagination.
patch_datafile
ChatGPTEdit an EXISTING datafile's JSON in place without resending the whole document — the right tool for changing one field of a large datafile, appending a blog post to a list, or fixing a word in a long string. Apply ordered operations (set / remove / replace_in / test) addressed by a dot-path from the document root (e.g. 'posts[slug=hello].title', or 'posts[-]' with op 'set' to APPEND). Pass values as raw JSON — the platform owns the escaping. For a SMALL change to a LARGE string use replace_in (find→replace, must match exactly once) so you send a few bytes. For a large NEW value send it with value_encoding=base64 (or gzip+base64) plus a value_sha256, so transcription damage is rejected instead of silently written. This is SAFER than update_datafile, not just cheaper: the patch is applied to the content it just read and the write is gated on that exact content, so a concurrent write is always reported rather than clobbered — no read-modify-write race, even with no arguments from you. The result is validated against the datafile's bound schema before it lands; a patch that would break the schema is rejected and nothing is written. Property order is preserved: untouched parts of the document come back byte-identical, so the change you make is the whole diff. Set republish=true to push the result to the CDN path it was last published at.
patch_workflow
ChatGPTEdit 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.
preview_dynamic_endpoint
ChatGPTRender what a dynamic endpoint serves WITHOUT publishing — runs the endpoint's workflow through the full serve path (input + bound datafile + content-type) and returns the response, so you can preview a DRAFT before publishing (or verify any version). Omit version to preview the latest draft; pass a version to preview that one. For a :param endpoint (e.g. 'post/:slug'), pass sample params (e.g. {"slug":"hello"}) — they run through the definition's input_transform, so you can preview a specific URL and confirm a good value renders and a bad one fails input validation. This executes the workflow (may have side effects). Returns content_type, output (decoded as a string), the run status (status=failed with a message when the render did not succeed), the run_id (drill into the full run/traces with get_workflow_run_traces), and resolved_input (the $input the transform produced, for debugging the mapping).
publish_api_template
ChatGPTPublish an api template version, making it the version workflows resolve when they reference it @published.
publish_app
ChatGPTPublish an app version, making it the live manifest (visible per role, its selector authoritative). Rejected if the version's membership selects nothing. Publishing an app promotes only its manifest — never its members, which publish independently on their own lifecycles.
publish_datafile
ChatGPTPublish a datafile to a CDN path you choose, so a page can fetch() it client-side. Only needed for that client-side fetch — NOT to bind a datafile server-side (an endpoint's @latest datafile ref reads the stored draft directly). Pass expected_content_sha256 (from the create/update/get that produced this content) — publish fails if the content changed since, so you publish the exact version you intend. Returns the public CDN URL.
publish_dynamic_endpoint
ChatGPTPublish a dynamic endpoint version, taking it live at its public URL (edge-cached). The response includes the public URL to share.
publish_schedule
ChatGPTPublish a schedule version, making it the ACTIVE definition — the dispatcher starts firing its workflow on the version's cron. Enforces the per-plan minimum-interval floor at publish.
publish_schema
ChatGPTPublish a schema version, making it the version a datafile resolves when it binds to this schema without requesting the latest.
publish_workflow
ChatGPTPublish a workflow version, making it the version served to callers (including dynamic endpoints that reference it @published).
rename_app_slug
ChatGPTRename an app's slug (its unique per-tenant identifier / folder prefix). Fails if the new slug is already in use. Note: this renames the APP; it does not move member resources, which are matched by their own slugs.
rename_schedule_slug
ChatGPTRename a schedule's slug (its unique per-tenant identifier). Fails if the new slug is already in use.
run_schedule_now
ChatGPTFire a schedule ONCE, immediately, WITHOUT publishing — so you can test a draft before it goes live (parallels preview_dynamic_endpoint). Runs the version's workflow (omit version for the latest draft) and returns a reference to the workflow run it triggered; resolve its outcome with get_workflow_run. Unlike an automatic fire, this one is captured in FULL — output and traces intact — so it is also how you reproduce something a due firing only sampled. This executes the workflow (may have side effects).
run_workflow
ChatGPTRun a workflow now and return the outcome: status, content_type, the workflow's output (decoded as a string; read it per content_type), and a trace_summary of which steps ran. Pass version=<n> to test an unpublished draft (the number returned by create_workflow_version); omit for the published version. For per-block detail when debugging, call get_workflow_run_traces with the returned run_id.
unpublish_app
ChatGPTHide an app (last_published_version -> 0) while preserving its definition; republish any version later. Does not touch its members.
unpublish_datafile
ChatGPTPull a published datafile off the CDN so its URL stops serving.
unpublish_dynamic_endpoint
ChatGPTTake a dynamic endpoint offline so its public URL stops serving content.
unpublish_schedule
ChatGPTDeactivate a schedule so it stops firing on its cron. The definition is preserved (last_published_version -> 0); republish any version later to resume.
update_api_template
ChatGPTUpdate an api template's display_name and description (metadata only — this does NOT change the request definition; author that with create_api_template_version, and the slug cannot be changed). This is a WHOLESALE replace: display_name is required and description is set to exactly what you pass (an empty/omitted description CLEARS it), so to change one field while keeping the other, read the current values with get_api_template first and pass both.
update_app
ChatGPTUpdate an app's display name and description (metadata only — the membership selector and display metadata live in the versioned definition; change those with create_app_version). This is a WHOLESALE replace: display_name is required and description is set to exactly what you pass (an empty/omitted description CLEARS it), so to change one field while keeping the other, read the current values with get_app first and pass both.
update_custom_domain
ChatGPTUpdate a custom domain's mutable settings: its label (display_name) and its routing (slug_prefix + root_endpoint). This is how a domain becomes the public front door of an app: set slug_prefix to the app's slug prefix so shop.customer.com/<path> serves <slug_prefix>/<path>, and root_endpoint to the app's landing endpoint so '/' has a page. All provided fields are set WHOLESALE — an empty value CLEARS that setting. The hostname identifies the domain and cannot be changed — and these tools cannot delete a domain, so a hostname cannot be moved from here; removing a claim is done in the Tessryx app.
update_datafile
ChatGPTUpdate a datafile. This is a partial update at the FIELD level: only the arguments you provide change. Provide json to replace the WHOLE document (its property order is preserved verbatim); omit it to change only metadata. To change PART of an existing document, prefer patch_datafile — it sends just the edit and cannot lose a concurrent write. Use this tool when you are replacing the whole document anyway; both preserve property order. Sending json here means get_datafile, change the object you got back, then send it all — pass expected_content_sha256 with that round trip so a change you did not see is reported instead of overwritten. Republish to push the change to the CDN.
update_dynamic_endpoint
ChatGPTUpdate a dynamic endpoint's display_name, description, and content_type (metadata only — this does NOT change the workflow binding or cache setting; author those with create_dynamic_endpoint_version, and the slug cannot be changed). This is a WHOLESALE replace: display_name is required and description + content_type are set to exactly what you pass. IMPORTANT: an empty content_type CLEARS it, reverting the endpoint to serving whatever content-type the workflow returns (e.g. a text/html page would start serving as text/plain). So read the current values with get_dynamic_endpoint first and pass all fields you want to keep.
update_schedule
ChatGPTUpdate a schedule's display name and description (metadata only — the cron/workflow/input live in the versioned definition; change those with create_schedule_version). This is a WHOLESALE replace: display_name is required and description is set to exactly what you pass (an empty/omitted description CLEARS it), so to change one field while keeping the other, read the current values with get_schedule first and pass both.
update_schema
ChatGPTUpdate a schema's display_name and description (metadata only — this does NOT change the JSON Schema body; author that with create_schema_version, and the slug cannot be changed). This is a WHOLESALE replace: display_name is required and description is set to exactly what you pass (an empty/omitted description CLEARS it), so to change one field while keeping the other, read the current values with get_schema first and pass both.
update_workflow
ChatGPTUpdate a workflow's display_name and description (metadata only — this does NOT change the workflow's logic; edit that with create_workflow_version / patch_workflow, and the slug cannot be changed). This is a WHOLESALE replace: display_name is required and description is set to exactly what you pass (an empty/omitted description CLEARS it), so to change one field while keeping the other, read the current values with get_workflow first and pass both.
validate_workflow
ChatGPTStatically check a workflow definition WITHOUT running it — use this to catch authoring mistakes before create_workflow / create_workflow_version. Returns a findings list: JSON/schema shape, per-expression syntax, variable scope (a $var referenced where it isn't in scope), and resolution of referenced api_templates / sub_workflows / schemas / secrets. valid is true when there are no error-severity findings; warnings/info are advisory. Author the definition against get_workflow_definition_schema.
verify_custom_domain
ChatGPTCheck the DNS TXT challenge for a claimed domain and, on success, take the global (hostname -> tenant) binding and start certificate issuance. Call this ONCE after the human confirms they have added the DNS records from create_custom_domain. DNS can take minutes to propagate, so do NOT poll this in a loop — if verified is false, tell the human it may take a few minutes and check back later (the server throttles rapid re-checks). Read get_custom_domain to watch the certificate go from CERT_PENDING to ACTIVE. First-to-verify wins: verifying is what actually claims the hostname.
whoami
ChatGPTReturn the authenticated user and tenant for the current MCP session.
