Tessryx
Build and run websites, APIs, automations, and admin tools from chat.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeCan modify data
What it can do
- Analyze Resource: Check whether a resource and everything it depends on is sound — the deployability question. Pass 'hypothetical' to preview a change instead: hypothetical='delete' or 'unpublish' rep
- Create Api Template: Api 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 autho
- Create Api Template Version: Api 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
What data it sees
Do you need an account
No: the server works without sign-in
Build and run websites, APIs, automations, and admin tools from chat. Your agent creates the data, logic, pages, and scheduled jobs; Tessryx hosts them on your own domain. No code generated, nothing to deploy.
What your agent builds:
- Pages and APIs — workflows that return HTML or JSON, bound to public URLs with edge caching.
- A data layer — JSON datafiles validated by JSON Schema. The same schema generates a human editor, so non-developers can maintain the content afterwards.
- Integrations — parameterized HTTP calls to external systems, with credentials held as write-only secrets.
- Scheduled jobs — cron or interval triggers that recompute data on their own.
Authentication is OAuth 2.1 — sign in through your browser, no API keys to manage.
Server tool list (60)
Raw names from tools/list. Only developers need these.
| analyze_resource | Check 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), warnings are risks (a published resource following @latest, a sub-workflow call cycle, a domain not yet verified), 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 | Api 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 | Api 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 | App 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 | App 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 | Claim 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 | Create 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 | Dynamic 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 | Dynamic 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 | Schedule 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 | Schedule 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 | Schema 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 | Schema 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 | Workflow 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 | Workflow 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 | Permanently 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 | Permanently 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 | Permanently 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 | Permanently delete a dynamic endpoint (the server purges its public edge URL first). Unlike unpublish, this removes the resource entirely — it no longer appears in list_dynamic_endpoints. Cannot be undone. |
| delete_schedule | Permanently 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 | Permanently 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 | Permanently 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 | Execute 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 | Get 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 | Get 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 | Read 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 | Get 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 | Get 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 | Resolve 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 | Read 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 | Get 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 | Get 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 | Get a single datafile by slug or id, including its JSON content and last published CDN path. |
| get_dynamic_endpoint | Get 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 | Get 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 | Read 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 | Fetch 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 | Browse 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 | Get 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 | Get 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 | Read 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 | Get 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 | Get 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 | Get 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 | Get the JSON Schema a workflow definition must satisfy. Fetch this before authoring the definition for create_workflow / create_workflow_version. |
| get_workflow_run | Get 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 | Get 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. |
| get_workflow_version | Read 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 | List 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 | Get 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 | List 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 | List 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 | List 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 | List 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 | List 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 | List 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 | List 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 | List 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 | List 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 | Get the earliest and latest version numbers of a schedule (by slug or id), to know the range you can fetch with get_schedule_version. |