Pane

Manage Apps

apps

Destructive

The v2 app lifecycle apart from creation and redeploy, which deploy_app covers. Actions: list returns the owning human's apps; show returns full detail including manifest, timezone and has_share_token; audit is a read-only security review of every app the caller owns, computed from each app's stored manifest, which is what makes it see apps that were deployed once and never redeployed (a deploy-time warning never reaches those). It reports collections whose declared permissions expose them, worst first: severity 'high' means an anonymous visitor can exploit it today, typically a collection that admits "anyone" to write with no separate 'update' list, so any visitor can overwrite rows other people created rather than only adding their own. It changes nothing; the fix is a redeploy declaring the missing list, and the right list differs per app, so read the app before proposing one. update changes visibility and timezone, the slug being immutable, and switching to 'link' returns a share_url once; share_link_rotate issues a new share token for a 'link' app, returning a new share_url and revoking the old link, and generates one if the app has none; delete is an idempotent soft-delete, and it is recoverable: the app stops serving at once but keeps every version, collection, row, attachment, member and grant, and restore brings all of it back until the retention window elapses (list_deleted shows what is in the trash and each app's purges_at deadline, which is null when the account is never purged). restore is idempotent on a live app, and refuses with 409 when the account is at its app limit, when the app was an expired trial, or when the owning account is itself deleted; an app an operator suspended comes back suspended, not active. purge destroys a deleted app and all its data immediately and forever, with no restore afterwards, and requires the app to already be deleted, so no single call takes a serving app to unrecoverable; wake wakes a dormant app and is otherwise a no-op that reports the actual status; domain_set binds a custom domain and returns the DNS records the domain owner must publish, where the first domain bound serves the app and every later one redirects to it, which is how apex plus www is configured; domain_status returns the serving domain and its aliases, live-refreshed against Cloudflare when that is enabled, with last_error carrying the reason a domain is not activating; domain_remove unbinds one domain, or all of them when no domain is given, and is idempotent.

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	No	list only. Exact-match slug filter.
`limit`	No	list only. Page size.
`action`	Yes	list: the caller's owning human's apps. show/update/delete/wake: act on one app (app_id). audit: read-only security review of every app the caller owns. share_link_rotate: rotate a 'link' app's share token, returning a new share_url (the old link stops working); also generates one if the app has none yet. list_deleted: the apps in the trash, each with when it is purged for good. restore: bring a deleted app back with all its data (app_id). purge: destroy a deleted app forever, now (app_id). domain_set/domain_status/domain_remove: manage the app's custom domains (app_id; domain_set also needs domain).
`app_id`	No	Required for show/update/share_link_rotate/delete/restore/purge/wake/domain_set/domain_status/domain_remove.
`cursor`	No	list only. Opaque cursor from a previous next_cursor.
`domain`	No	domain_set: the bare custom domain to bind (e.g. app.example.com); the response's dns_records lists the DNS entries the domain owner must publish. domain_remove: optional, the one domain to unbind - omit it to unbind them all.
`status`	No	list only. Default: active. 'all' means every live status; deleted apps are never in this list, use action list_deleted for those.
`severity`	No	audit only. Return findings of this severity only. The response's `counts` always describe the whole audit, so filtering never hides that other findings exist.
`timezone`	No	update only. The app's IANA timezone for `schedules` reminders (e.g. Europe/Berlin). An app that declares schedules with no timezone fires reminders at 08:00 UTC.
`visibility`	No	update only. The new visibility (slug is immutable).

TDQS

A4.8/5.0

Behavior5/5

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

The description heavily enriches the annotations with side-effect detail: delete is soft and recoverable, purge destroys forever with no restore, wake is a no-op, audit changes nothing, restore refuses with 409 under specific conditions, and domain_set explains redirect behavior. This far exceeds what the annotations alone convey.

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 a single dense paragraph, which is hard to skim, but every clause adds necessary information for a 13-action tool. It is not front-loaded with headings or formatting, yet it avoids redundancy and each sentence earns its place.

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?

Despite having no output schema, the description covers return-relevant behavior: share_url generation, dns_records, counts, purges_at, aliases, last_error, and status reporting. It also addresses edge cases like expired trials, suspended apps, and deleted owning accounts, making it complete for safe invocation.

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 the baseline is 3. The description adds meaningful context beyond the schema, such as timezone behavior ('fires reminders at 08:00 UTC'), domain_remove's all-or-one semantics, and severity filtering's effect on counts. This pushes it above baseline.

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 precise scope: 'v2 app lifecycle apart from creation and redeploy, which deploy_app covers.' It enumerates all 13 actions with their specific effects, making the tool's purpose unmistakable and distinguishing it from the deploy_app sibling.

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 explicitly names deploy_app as the tool for creation/redeploy and positions this tool for everything else in the app lifecycle. Each action gets a clear context, e.g., 'list_deleted shows what is in the trash' and 'audit is a read-only security review,' so an agent knows when to invoke which sub-action.

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

All Pane 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.4/5.0

Disambiguation5/5

Each tool targets a distinct resource or action: row operations (get/list/upsert/update/delete/restore) are clearly separated, while apps, attachments, community, grants, ingest, members, publisher, review, and taste each cover a different domain. Even closely related actions like share_link_rotate and domain_set have clearly scoped descriptions, so an agent can reliably select the right tool.

Naming Consistency4/5

Tool names use two patterns: noun-like names for resource areas (apps, attachments, community, grants, ingest, members) and verb_noun names for row operations (upsert_row, delete_row, etc.). This deviation is predictable and readable, but it is not perfectly uniform, so a slight deduction applies.

Tool Count4/5

With 22 tools, the server is on the heavier side, but the breadth of the platform (app lifecycle, data storage, attachments, community, reviews, feedback, identity) justifies the count. Each tool represents a meaningful feature area with multiple internal actions, so none feels redundant.

Completeness5/5

The tool surface covers the full lifecycle for apps (create, read, update, delete), rows (create, read, update, delete, restore, list deleted), attachments, membership, grants, ingest, community, and reviews. Obvious gaps like rollback or version history are not core to the domain, and the presence of get_skill helps agents understand the workflow.

Resources

Need Help?