Skip to main content
Glama

Deploy app

deploy_app
Destructive

Deploy or update a website or web app to get a public URL. Text files only in files[]. files[] must be a JSON array, even for one file. Example: files: [{"filename":"src/App.tsx","content":"..."}]. Never pass a bare string or a single file object. Use files[] for inline text edits and diffs, not for copying large existing local file contents into tool params. Never inline or base64-encode binary assets/resources in files[]; use upload_assets first for images, fonts, media, PDFs, archives, and other client-supplied file assets, then pass upload_id. Inline deploy_app text payloads MUST be compact. For JavaScript/TypeScript/JSX/TSX string literals, use single quotes wherever valid. Keep inline HTML/CSS/JS/TS diff from/to values single-line wherever valid; do not include newline characters unless required for valid syntax. Template files from get_app_template are auto-included as the baseline — use diffs[] to modify them; content is otherwise only for entirely new files. New apps: tests/tests.txt is the intentional template-file exception and must be sent as a complete content replacement. New apps: set app_id to null, provide app_name, description, app_type, frontend_template, and features. Updates: provide existing app_id, features, and either changed files/deletePaths or upload_id. If upload_id is provided, do not also send files[] or deletePaths[]; the upload manifest owns all text changes, diffs, and delete operations. Rules: do not add @appdeploy/client or @appdeploy/sdk to package.json (platform-injected). SPAs must use HashRouter. Frontend must never import @appdeploy/sdk; backend must never import @appdeploy/client. Frontend must use api from @appdeploy/client for backend calls, never fetch() or axios. If frontend realtime is used, @appdeploy/client websocket usage is ws.connect() only; do not call ws.subscribe/ws.publish/ws.send directly on ws. After deploy, poll get_app_status every 5s until status is 'ready' or 'failed'. On a lifetime-limit error, stop deploy_app calls unless the account limit increases. The limit does not reset; show the returned upgrade link to the user. If get_app_status returns QA/e2e/runtime errors, attempt automatic fixes and redeploy up to 3 times before asking the user for guidance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoOptional deploy change type, for example 'fix', 'feature', 'refactor', 'performance', 'test', 'docs', 'chore', or 'style'.
filesNoArray of text file edit objects. MUST be a JSON array, even for one file. Never pass a bare string or a single object. Example value: [{"filename":"src/App.tsx","content":"..."}]. Each item must include filename plus either content or diffs. Use files[] for inline text edits and diffs. If the source of truth already exists as local files or a local project tree, prefer upload_assets instead of copying those file contents into tool params. If upload_id is provided, do not also send files[] or deletePaths[]; the upload manifest owns all text changes, diffs, and delete operations. Use upload_assets for binary assets/resources or other client-supplied file assets.
modelNoMANDATORY: LLM model name generating this deploy (e.g. 'claude-sonnet-4', 'gpt-4o'). If unavailable, use 'chat'.
app_idNoMANDATORY: existing app id to update, or null for new app
intentNoMANDATORY: one-line summary of what changed (e.g. 'Add dark mode toggle', 'Fix login redirect bug'). If no specific intent was given, use 'app deploy'.
app_nameYesshort display name
app_typeYesapp architecture: frontend-only or frontend+backend
featuresNoSDK features used (from get_appdeploy_sdk_reference). Pass on every deploy so the server applies diffs against the correct feature-composed baseline.
initiatorNoOptional request initiator. Use 'user' when this call directly follows a user request. Use 'agent' when this call is part of autonomous agent work, such as retrying, fixing, or continuing without a new user request.
upload_idNoOpaque upload ID from upload_assets. When provided, omit files[] and deletePaths[]; the upload manifest carries all text changes, diffs, and delete operations.
deletePathsNoArray of relative paths to delete. MUST be a JSON array, even for one path. Example value: ["src/old-file.ts"]. If upload_id is provided, do not also send files[] or deletePaths[]; the upload manifest owns all text changes, diffs, and delete operations.
descriptionNoshort description of what the app does
secret_entry_idsNoOptional one-time secret entry ids to bind during a new-app deploy. Allowed only when app_id is omitted. For existing apps, use set_app_secrets instead.
frontend_templateNoREQUIRED when app_id is null. One of: 'html-static' (simple sites), 'react-vite' (SPAs, games), 'nextjs-static' (multi-page). Template files auto-included.
resource_requirementsNoOptional widget upload slot definitions for ChatGPT web/Claude web. Use this when users will provide large resources (images/PDF/media/fonts) after code generation. Code should reference these target_path placeholders so uploaded files resolve without further code edits.

TDQS

A4.8/5.0
Behavior5/5

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

The annotations already flag destructiveHint=true and readOnlyHint=false, and the description reinforces this by describing updates, deletes (deletePaths), and the fact that deploy_app mutates the app. It goes beyond the annotations by disclosing platform-specific runtime behavior: SPA HashRouter requirement, SDK import constraints, ws.connect()-only websocket use, lifetime-limit non-reset semantics, and the 3-attempt auto-fix/retry loop. These details are exactly the kind of behavioral context an agent cannot infer from the schema or annotations.

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 long but information-dense; nearly every sentence encodes a constraint or workflow rule the agent needs. However, it repeats the 'files[] must be a JSON array' rule, 'upload_id owns all text changes' twice, and the binary-asset guidance appears both in the description and schema. It could be tightened without losing information, though the overall structure is sequential and readable.

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

Completeness4/5

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

For a 15-parameter deploy tool with no output schema, the description covers the full invocation lifecycle: new-app vs update payload shapes, template baseline behavior, upload vs inline file routing, SDK restrictions, polling cadence, and error/recovery rules. The main omission is the deploy_app response contract—the agent is told to poll get_app_status but not what fields deploy_app returns (e.g., app_id, deploy_id, status), which matters for chaining calls. Minor gap given the complexity.

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

Parameters5/5

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

With 100% schema_description_coverage the schema already documents all 15 parameters, but the description adds substantial value: it gives concrete files[] JSON examples, specifies that content is only for entirely new files while diffs[] are for template baselines, and clarifies the upload_id/files[]/deletePaths mutual exclusivity. It also explains why features must be passed on every deploy (correct feature-composed baseline) and when frontend_template is required (app_id null), which is beyond the schema's description.

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 and resource: 'Deploy or update a website or web app to get a public URL.' This clearly distinguishes it from siblings like get_app_status (status polling), upload_assets (asset upload), and configure_custom_domain (domain setup), so an agent can select it confidently. The scope is further refined by enumerating new-app vs update workflows.

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?

The description gives explicit when-to-use vs alternatives: 'use upload_assets first for images, fonts, media, PDFs...' and states that template files from get_app_template are auto-included so diffs[] should be used to modify them. It also prescribes separate parameter sets for new apps (app_id null...) and updates (existing app_id...), and says when to avoid files[] entirely in favor of upload_id. These are actionable selection rules, not generic statements.

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.2/5.0
Disambiguation4/5

Most tools have distinct purposes, but the 5 secrets-related tools (create_secret_entry, delete_app_secrets, get_secret_entry_status, list_app_secrets, set_app_secrets) are numerous and could cause confusion. Similarly, deploy_app and apply_app_version both involve deployment but with different contexts. Overall, descriptions help differentiate, but some overlap remains.

Naming Consistency4/5

The majority of tools follow verb_noun pattern (e.g., deploy_app, get_apps). However, the src_ prefix tools (src_glob, src_grep, src_read) deviate by using a noun prefix instead of a verb, creating a slight inconsistency. Otherwise, naming is clear and predictable.

Tool Count5/5

With 21 tools, the server covers deployment, domain management, secrets, source inspection, and asset upload without being overly large. The count is well-scoped for a deployment platform, each tool serving a necessary role.

Completeness4/5

Core workflows (deploy, status, secrets, source inspection) are well-covered. However, there are minor gaps: no tool to list available templates or manage app metadata beyond deployment. The surface is mostly complete but could benefit from a few additional administrative tools.

Resources