Tessryx

Create app

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.)

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	Yes	Unique per-tenant slug; this is the app's folder prefix (hierarchical segments allowed, e.g. storefront or marketing/campaigns).
`publish`	No	If true, immediately publish the version this call creates (the common create-then-publish in one step). Defaults to false; omit to leave the version as an unpublished draft.
`definition`	Yes	The app definition, as a JSON object. Fetch the exact JSON Schema it must satisfy with get_app_definition_schema and author against it (or copy an existing one with the get_*_version tool). The owning service validates it on submit.
`description`	No	What this app is (human + LLM-facing prose).
`display_name`	No	Human-readable name.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes
`app_id`	Yes
`version`	Yes
`published`	Yes

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?

Annotations only carry openWorldHint=false and destructiveHint=false, so the description carries the behavioral burden — and it carries it thoroughly. It discloses the minting behavior (app + version 1 created together), automatic member capture via prefix rules ('you never hand-add members'), and the side-effect of publish=true. It also reveals the validation rule that an empty definition is draft-valid but unpublishable, which no structured field communicates.

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 core purpose is front-loaded in the first sentence, with publish behavior and sibling routing following logically. It runs long, but every clause contributes — workflow, membership semantics, schema reference, draft rule — with no filler or repetition of schema content. Slightly dense but appropriately so for a tool with a nested definition object.

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?

With an output schema present, return-value explanation is unnecessary. The description covers the invocation workflow, definition schema lookup, publish semantics, validation constraints, and sibling alternatives. Nothing an agent needs to correctly select and invoke this tool is missing.

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 100%, so baseline is 3, and the description adds genuine meaning on top: slug becomes the folder prefix that drives automatic membership ('storefront/page, storefront/products…'), and definition is disclosed as holding the membership selector (prefix rules + includes/excludes). publish=true gains workflow context as 'publish v1 immediately'. It adds little for display_name/description, but those are self-explanatory.

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 opens with a specific verb+resource: 'create a BRAND-NEW app (mints the app + its version 1)'. It explicitly differentiates itself from its closest sibling with '(To add a version to an existing app, use create_app_version.)', and the slug-as-folder-prefix explanation further separates it from API-template/workflow creators. An agent can tell exactly what this tool produces and how it differs from similar tools.

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?

States when to start here — 'Start here when building a page or an API bundle' — and names the exclusion: adding a version to an existing app goes through create_app_version. It also walks through the authoring flow (choose slug, author members under the prefix, fetch the definition schema) and clarifies draft-vs-publish behavior. This is explicit, actionable routing guidance.

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?