Skip to main content
Glama

WebSlop

by ai.webslop.api

update_app

Update an app's settings: name, subdomain, environment variables, resource limits, access control, runtime configuration, and more.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appYesApp ID (UUID) or subdomain
nameNoNew display name (1-100 chars)
env_varsNoEnvironment variables as a JSON string of key-value pairs (replaces all existing env vars)
always_onNoKeep the app running 24/7 without auto-sleep. Requires a billing tier that supports always-on apps.
cpu_limitNoCPU limit (0.5 to 4 cores). Capped by the app's billing tier.
subdomainNoRename the app subdomain (WARNING: changes the app URL and recreates the Docker service — use with care)
memory_limitNoMemory limit, e.g. "512M", "1G", "2G". Capped by the app's billing tier (team tier for team apps; up to 2G on team plans).
start_scriptNoWhich package.json script to run (e.g. "dev", "serve"). Defaults to "start". Set to empty string to reset to default.
watch_ignoreNoComma-separated paths to ignore for file watching (e.g. "public,dist,output"). Always ignores node_modules.
sso_auth_modeNo"any" = any Bonto user can access; "list" = only users in sso_auth_allowed_users.
allow_remixingNoAllow other Bonto users to create a copy (remix) of this app.
git_auto_commitNoEnable/disable automatic version history snapshots when files change. Default: true.
sso_auth_enabledNoEnable/disable Bonto SSO login requirement. When enabled, visitors must sign in with a Bonto account.
watch_extensionsNoComma-separated file extensions that trigger nodemon restart (e.g. "js,ts"). Leave empty for default (js,ts,json,html,css).
workspace_mountsNoJSON array of app IDs to mount as read-write volumes at /app/workspace/[slug]/. E.g. '["uuid1","uuid2"]'. Pass '[]' to remove all mounts.
http_auth_enabledNoEnable or disable HTTP Basic Auth protection. Set to false to remove password protection without changing stored credentials.
http_auth_passwordNoPassword for HTTP Basic Auth (plaintext, will be hashed). Min 8 chars. Set to enable Basic Auth on this app.
http_auth_usernameNoUsername for HTTP Basic Auth. Set http_auth_password together with this to enable password protection.
sso_auth_allowed_usersNoJSON array of Bonto user email addresses allowed when sso_auth_mode is "list". E.g. '["alice@example.com","bob@example.com"]'.
healthcheck_timeout_secsNoTimeout (seconds) for each healthcheck request. Default: 10.
healthcheck_interval_secsNoHow often (seconds) to check if the app is alive. Default: 30.
healthcheck_start_period_secsNoGrace period (seconds) before the first healthcheck runs after container start. Default: 30.

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description must convey behavioral traits, but it only lists settings categories. It omits important side effects such as env_vars replacing all existing variables, subdomain changes recreating the Docker service, or that some changes are capped by billing tier. This is a significant transparency gap for a mutation tool.

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

Conciseness5/5

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

The description is a single concise sentence that front-loads the main action and lists key categories. Every word is functional, and it avoids unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 22 parameters, no output schema, and no annotation support, the description is far too brief. It does not mention that updates are partial (only provided fields change), whether changes trigger restarts, or what the response contains. The schema covers parameter details, but the description fails to provide the high-level context needed for a tool of this complexity.

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?

The input schema has 100% coverage of all 22 parameters with detailed descriptions, so the baseline is 3. The description adds minimal extra meaning by grouping parameters into categories like 'resource limits' and 'access control', but does not provide any new parameter-level semantics beyond the schema.

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 clearly states the tool's function as updating an app's settings, with a specific verb (update) and resource (app's settings). It lists the categories of settings (name, subdomain, environment variables, resource limits, access control, runtime configuration), which differentiates it from sibling tools like create_app, delete_app, or get_app.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that this tool is for modifying existing apps but does not provide explicit guidance on when to use it vs alternatives. It does not mention that this should be used only for existing apps, nor does it explain when to use restart_app or other tools.

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

All WebSlop toolsInspect
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

A3.7/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but a few pairs could be confused: get_app vs. get_app_status both report on app state, and update_app vs. set_node_version both modify runtime configuration. Descriptions are detailed enough to mitigate most ambiguity, but the overlap is notable.

Naming Consistency4/5

Tool names largely follow a consistent verb_noun snake_case pattern (e.g., list_apps, create_app, delete_file). Minor deviations include the bare verb 'login' and the noun-first 'git_info', which break the pattern slightly but are still understandable.

Tool Count3/5

At 37 tools, the set is on the heavy side, well above the typical 3-15 range. However, the server covers a broad PaaS domain (auth, app lifecycle, file management, packages, versions, git, metrics), and each tool addresses a distinct operation. It feels over-engineered in places but not gratuitously so.

Completeness5/5

The tool surface is impressively complete for a deployment platform: authentication, app CRUD, start/stop/restart, file operations (read/write/delete/rename/search/upload), package management, version snapshots and restore, git remote and push/pull, logs, metrics, and configuration. No critical dead-ends are apparent.

Resources