Skip to main content
Glama

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
NameRequiredDescriptionDefault
slugNolist only. Exact-match slug filter.
limitNolist only. Page size.
actionYeslist: 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_idNoRequired for show/update/share_link_rotate/delete/restore/purge/wake/domain_set/domain_status/domain_remove.
cursorNolist only. Opaque cursor from a previous next_cursor.
domainNodomain_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.
statusNolist only. Default: active. 'all' means every live status; deleted apps are never in this list, use action list_deleted for those.
severityNoaudit only. Return findings of this severity only. The response's `counts` always describe the whole audit, so filtering never hides that other findings exist.
timezoneNoupdate 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.
visibilityNoupdate only. The new visibility (slug is immutable).

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say destructiveHint=true, but the description goes far beyond: delete is soft and recoverable, purge is immediate and permanent, audit changes nothing, share_link_rotate revokes the old token, restore is idempotent and has 409 conditions, wake is a no-op that reports actual status, and domain_set has redirect behavior. This is rich behavioral disclosure with no contradiction to annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single massive run-on paragraph with dense, nested clauses and multiple separate actions and exceptions crammed into consecutive sentences. It duplicates much of the action enum's schema description and would be far more navigable as bullets or shorter per-action paragraphs. Every sentence is informative, but the structure is not appropriately sized or scannable.

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?

For a 13-action tool with no output schema, the description covers return values (share_url, dns_records, aliases, last_error, purges_at), error conditions (409 cases, suspended restore state), lifecycle behavior (soft-delete, retention, purge), and subtle domain behavior. Nothing an agent needs to invoke safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds action-level behavioral context rather than new parameter-level meaning; it does not significantly clarify parameter types, formats, or constraints beyond what the schema descriptions already provide.

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 states a specific resource and scope: the v2 app lifecycle, excluding creation and redeploy, which deploy_app covers. It enumerates all 13 possible actions with their distinct effects, making the tool's purpose and boundary unambiguous even among many siblings.

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?

Explicitly names deploy_app as the alternative for creation/redeploy, sets preconditions for purge ('requires the app to already be deleted, so no single call takes a serving app to unrecoverable'), and advises reading the app before proposing a permission fix in audit. It also clarifies when restore refuses and when domain_remove acts on all domains.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools are clearly distinct, with row operations (list, get, upsert, update, delete, restore) well separated. Some boundaries like apps vs deploy_app and credentials vs grants require careful reading, but descriptions resolve the overlap.

Naming Consistency2/5

Tool names mix resource nouns (apps, attachments, connections) with verb_noun actions (delete_row, deploy_app). Singular and plural forms are inconsistent, and there is no uniform pattern across the set.

Tool Count3/5

24 tools is on the heavy side, but the platform's breadth (app deployment, data, auth, community) justifies the count. Each tool has a distinct role, though the set slightly exceeds the typical well-scoped range.

Completeness4/5

The surface covers the full app lifecycle: deploy, manage, delete, row CRUD with restore, attachments, credentials, and community features. Minor gaps like no dedicated row search or outbound webhook management are workable via existing tools.