AppDeploy

Start deploying an existing app at a specific version. Use the 'version' value (not 'name') from get_app_versions. Returns true if accepted and deployment started; use get_app_status to observe completion.

apply_app_version

Attach one or more submitted secret entry ids to an existing app. Reusing a secret name replaces the stored value for that app.

set_app_secrets

Use this when you need to manage a custom domain for an existing app, including adding a hostname, verifying DNS, or deleting it.

configure_custom_domain

Create a one-time pre-authorized browser link so the user can submit a backend secret value outside chat without an extra login step. The returned secret_entry_url should be opened in a new tab. In terminal or CLI clients, present the full raw URL in plain text instead of a markdown link label.

create_secret_entry

Use this when you want to permanently delete an app. Use only on explicit user request. This is irreversible; after deletion, status checks will return not found.

delete_app

Delete one or more backend secret names from an existing app. Missing names are ignored.

delete_app_secrets

Use this when the user asks to deploy or publish a website or web app and wants a public URL. If the user plans to provide large resources later (images/PDF/media/fonts), include resource_requirements with stable target_path placeholders so the widget can request exact files and uploads can resolve those paths. For each resource_requirements slot, ensure type resolution via accept and/or target_path extension so widget placeholders map to the right file type. If user-attached files are intended as resources, do not stream them as base64 in files[]; have the user upload them via the widget Resources flow. If the user provides or attaches any image or binary file they want used in the app, including logos, favicons, icons, backgrounds, photos, PDFs, media, or fonts, you MUST route it through the widget Resources upload flow. Do not invent asset filenames, reference local/chat attachment paths, use placeholder paths that are not in resource_requirements, or inline/base64 the file in deploy_app.files[]. Instead, define one deploy_app.resource_requirements slot per user-provided file with a stable target_path under public/resources/... and make the app code reference that exact target_path placeholder so the uploaded file resolves after the user uploads it. When setting resource_requirements.name, keep labels faithful to user wording and do not invent terms. Do not use components names from the template. Every deploy_app call must include non-empty 'model' and 'intent'. Every deploy_app call should include 'initiator' and 'type' when known. Before generating files or calling this tool, you must call get_deploy_instructions and follow its constraints. After deploy_app starts, keep polling get_app_status every 5 seconds in the same turn until terminal status. Do not hand status polling back 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. 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.

deploy_app

Returns types, rules, and examples for one requested SDK feature plus its dependencies. Input must be { feature: <one enum value> }. Call this after reviewing deploy instructions and before writing code that imports or calls @appdeploy/client or @appdeploy/sdk. Available features: api, realtime, auth, notifications, invites, database, storage, secrets, ai.generate, ai.extract, ai.ocr, ai.classify, ai.scrape, ai.run, ai.image, cron. Choose features by scenario: Use api for standard backend HTTP routes and transport basics; realtime for live cross-client sync and subscriptions; auth for sign-in, user identity, and protected app state; notifications for push delivery and enable/subscribe UX; invites for share links, join codes, and invite lifecycle flows; database for persisted CRUD records; storage for file uploads/downloads and signed URLs; secrets for backend-only credentials or API keys; ai.generate for single generation calls; ai.extract for schema-based structured extraction; ai.ocr for OCR/transcription from images; ai.classify for fixed-label classification; ai.scrape for AI-friendly web page extraction; ai.run for bounded multi-step AI tool loops; ai.image for image generation; cron for scheduled jobs. Call get_appdeploy_sdk_reference once per top-level SDK feature, using the singular feature field with exactly one enum value. Request one top-level SDK feature per call. Do not separately request dependency features; request the highest-level feature and use the dependencies returned with it. Dependency expansion: realtime -> realtime + api + database; auth -> auth + api; notifications -> notifications + api + auth; invites -> invites + api; database -> database + api; storage -> storage + api; secrets -> secrets + api; ai.generate -> ai.generate + api; ai.extract -> ai.extract + api; ai.ocr -> ai.ocr + api; ai.classify -> ai.classify + api; ai.scrape -> ai.scrape + api; ai.run -> ai.run + api; ai.image -> ai.image + api.

get_appdeploy_sdk_reference

Widget-only helper for the ChatGPT mode reminder. Use this when the AppDeploy reminder widget needs to know whether it is active and whether get_app_template, get_appdeploy_sdk_reference, or deploy_app was called after the latest get_deploy_instructions in this MCP session.

get_mode_reminder_status

Use this when deploy_app returns, when checking deployment status, or when the app has errors or is not working as expected. Returns deployment status, e2e test status, QA snapshot, and frontend/backend error logs; treat deployed_and_testing status as non-final, always inspect QA/errors, and call get_e2e_qa_run_details if e2e tests fail.

get_app_status