Alchemist Cloud Tickets MCP

The Alchemist Cloud Tickets MCP server lets an AI client (claude.ai, ChatGPT, Claude Code, Claude Desktop, Cursor, or anything that speaks the Model Context Protocol) talk to your Alchemist Cloud project tickets directly. From inside your assistant you can dispatch tickets, list and read their status, reply to a ticket that’s paused waiting on your input, watch deploys, read your deployed app’s errors, check costs, browse the project’s repo, run read-only queries against the project database, and export files — all without leaving the conversation.

Naming note: this is a dedicated server for Alchemist Cloud (project/ticket automation), separate from the Chipp MCP server (which manages Chipp apps — system prompt, knowledge, custom actions) and separate from the in-product “Alchemist” chat assistant you talk to inside the dashboard. If you previously connected an MCP client to the plain-named “Alchemist” server, your connection keeps working unchanged — the endpoint and auth are the same, only the display name was clarified.

The server speaks Streamable HTTP at https://build.chipp.ai/alchemist-api/api/mcp. There are two ways to connect, depending on what your client supports:

OAuth — for hosted connectors whose “add connector” dialog offers only a URL (claude.ai custom connectors, ChatGPT). You paste the URL and approve a browser consent screen; there’s no key to copy. Access is scoped to you (your user), so it reaches every project you own or are a member of.
API key — for clients that let you set an Authorization header (Claude Code, Claude Desktop, Cursor). Access is scoped to your tenant.

Either way you only ever see your own projects, tickets, and data.

Option A — OAuth (claude.ai, ChatGPT)

Use this for hosted connectors whose dialog only takes a URL. In claude.ai: Settings → Connectors → Add custom connector.

Paste the server URL: https://build.chipp.ai/alchemist-api/api/mcp
Leave OAuth Client ID / Client Secret blank — the connector registers itself automatically (Dynamic Client Registration). Those fields are only for pre-registered clients, which you don’t need.
Click Add. A browser window opens an Alchemist consent screen — sign in to your dashboard if prompted, then Approve. The connector is now live.

No API key is involved. Disconnect any time from your client’s connector settings (that revokes the access immediately).

Option B — API key (Claude Code, Claude Desktop, Cursor)

These clients send a bearer token, so they use a tenant API key.

Unified endpoint: with an alch_ API key you can also point your client at https://build.chipp.ai/mcp (the same URL as the Chipp MCP Server). The server routes by key type, so one URL works for both products; the alchemist-api URL below remains fully supported.

1. Create an API key

Mint a key in Settings → API keys (see API keys). The secret is shown once — copy it immediately. You can revoke it at any time.

2. Point your client at the server

Claude Code (one command):

plaintext

claude mcp add --transport http alchemist https://build.chipp.ai/alchemist-api/api/mcp \
  --header "Authorization: Bearer alch_your_key_here"

Claude Desktop / Cursor (config file):

json

{
  "mcpServers": {
    "alchemist": {
      "url": "https://build.chipp.ai/alchemist-api/api/mcp",
      "transport": "streamable-http",
      "headers": { "Authorization": "Bearer alch_your_key_here" }
    }
  }
}

Tools

Why your client may list tools this guide does not document. On this endpoint, tools/list returns the whole server registry rather than a filtered set, so a few operations tools show up in your client: propose_data_operation, propose_script_operation, run_script_operation and propose_slack_invite. They are not usable from a tenant API key or an OAuth connection. This lane binds only your tenant and your user, and those tools need a project-scoped conversation session, so every call fails immediately with no_session_bound or no_project_bound. They are reachable only from the project bridge that Alchemist’s own desktop and project-token clients use. Nothing is wrong with your setup; ignore them and use the tools below.

Tickets

dispatch_ticket — create and dispatch a ticket. mode: "build" runs the full implementation workflow; mode: "investigate" runs a read-only research flow (no code changes, no deploy). Write the title + description as a complete, self-contained brief — the platform plans and verifies its own work internally, without asking follow-up questions. Pass depends_on (an array of ticket UUIDs or #N references) to make the ticket wait until those parents succeed (DAG dependencies).
propose_ticket_batch — draft several related tickets at once, with dependency edges between them, behind ONE approval instead of one approval per ticket. Each draft ticket carries a stable node_id you mint (never a real ticket id); a dependency can point at another draft in the same batch (type: "node", ref = its node_id) or at an already-filed ticket (type: "existing", ref = its key/UUID — this is how you extend a chain you started earlier). Validates the whole graph up front (no cycles, every project accessible, every dependency names what it consumes, one cohesive outcome per ticket) and returns an approval card plus a batch_proposal_id. Nothing is created yet.
dispatch_ticket_batch — file every ticket in a batch proposed by propose_ticket_batch, after the requester has reviewed the card. Safe to call again for the same batch_proposal_id: an already-dispatched batch returns the same created ticket keys instead of filing duplicates.
start_sandbox_change — queue a small code change directly onto a project’s sandbox coding agent, instead of filing a ticket for it. Takes one instruction (plain language, written for an agent that has the repo open) and an optional idempotency_key. Use it for a change you can describe in a sentence or two; use dispatch_ticket for larger work that needs planning, review, and the full pipeline. The work runs asynchronously: the call returns as soon as the request is queued, and a human reviews the change in the project workspace before it merges. There is no project argument — the change targets the project bound to the connection, so this tool only works on a project-scoped connection (a bare tenant API key has no project bound and the call is refused). Opt-in per project, off by default: the tool is only offered to projects that have turned it on in project settings. Everywhere else it is neither listed nor callable, and dispatch_ticket remains the way to request code work.
resolve_sandbox_review — answer a sandbox change that is waiting for review. A queued change pauses before it merges so a human can look at the preview; this applies their answer. Takes the review’s message_id, a decision of approve (let it land) or request_changes (send it back), and optional feedback passed to the agent verbatim. Answering a review that was already resolved, in the project workspace or by the review timeout, is a safe no-op rather than an error. Same project-scoped connection requirement as start_sandbox_change, and gated by the same per-project opt-in — the two are enabled together, so a project that can start a change can also answer its review.
list_tickets — recent tickets, optionally filtered by project or status.
get_ticket — one ticket by UUID or number (#42).
get_ticket_audit — the agent’s per-turn narration across all nodes in the ticket’s graph.
get_ticket_reports — durable per-phase execution reports and the final completion summary.
get_scope_graph — the dependency graph and live progress rollup for a multi-ticket scope (depends_on DAG).
update_ticket — edit a not-yet-started ticket’s title, body, or kind.
cancel_ticket / retry_ticket — stop or re-run a ticket.
reply_to_ticket — answer a ticket that’s paused awaiting_input (the agent asked a question mid-build — an ambiguity, a missing credential). Relay the human’s answer; a continuation ticket resumes the work automatically. Never paste a secret value here — if the agent asked for a credential, use the secure submission link from its question.

Projects and deploys

list_projects — your projects, with deploy status and public URL.
get_project — one project, with its latest deploy and a cost breakdown.
list_deploys — recent deploys for a project, with failure reasons.
create_project — create a new project from a template (provisions the GitHub repo, initial deploy, and public URL; returns immediately, the deploy runs async — poll get_project / list_deploys for build progress).
get_deploy_gate_status — whether a project’s deploy gate (“deploy trains”) has work piling up: the gate mode, when it last actually released, how many contributions are currently held, and a live preview of the release notes / QA checklist a release would generate right now. Check this before proactively suggesting a deploy.
trigger_deploy — release everything currently held behind a manual or scheduled deploy gate (same action as “Deploy now” in the dashboard). No-ops cleanly when the gate is continuous or nothing is pending.

Production errors

get_project_errors — recent error logs from a project’s live app (pick a time window and an optional substring filter).
get_alert_status — whether the error-investigation agent is currently working an alert on a project, and how often alerts have recurred.
get_env_status — whether the project’s production deployment is missing any required environment variables (from its startup env-validation logs; presence status only, never values).
get_project_logs — read recent logs from a project’s deployed app: pick a time window (5m-7d), a level (error/warn/info/all), and an optional substring or regex filter. Curated query, capped at 500 lines.

Billing

get_credit_balance — your current credit balance.
get_project_cost / get_ticket_cost — cost breakdowns by project or ticket (LLM, sandbox, pod, storage).

Repo access

read_repo_file — read a single file from the project’s GitHub repo (at the HEAD of the default branch).
list_repo_dir — list the entries in a repo directory (capped at 500).
search_repo — case-insensitive literal substring search across the repo.

Database

inspect_schema — read the project database schema. Columns holding secrets are masked out.
query_database — run a single read-only SQL query (SELECT / CTE only) against the project database. Writes and DDL are rejected at the connection level.

Email ingestion

provision_email_ingestion — set up the inbound email pipeline for a project: mints the ingest credential, creates the MX record and inbound mail server, and wires deliveries to the project’s /api/ingest/email route. Idempotent; re-run to repair drift.
get_email_ingestion_status — the project’s ingest address and provisioning health (never returns the token).
deprovision_email_ingestion — tear the pipeline down (the dormant ingest route stays safe; re-provisioning reuses the credential).

Outbound mailbox

set_project_outbound_mailbox — configure a project’s custom outbound mailbox: a real mailbox on the customer’s own mail provider (SMTP credentials), so the project’s agent sends and is addressed as that real mailbox instead of the platform default.
get_project_outbound_mailbox_status — a project’s custom outbound mailbox status: host, port, username, whether a password is set, and a preview of the resolved From header. Never returns the password.

File delivery

export_csv — build a CSV from { columns, rows }, store it in private R2, and return a short-lived signed download URL.
deliver_file — upload arbitrary bytes to private R2 and return a short-lived signed download URL.

Incident diagnostics

what_changed — correlate recent deploys against the error rate around them, the first question in any incident (“did this start after a deploy?”). Returns each deploy that completed in the window with the error count in the equal-length span before and after it, flagging the ones where errors rose.
watch_deploy — watch a deploy settle and return a regression verdict plus the exact rollback target, comparing the error rate after it against the equal-length span before.
get_runtime_health — read a managed project’s pod state: replica readiness, restart counts, crashloops, OOMKills, and pods stuck Pending. A pod that crashes before serving traffic writes no application logs, so this covers the blind spot get_project_errors cannot see.
get_migration_status — compare the migrations recorded as applied on the live database against the migration files in the repo, and report which are pending. Use it when a deploy succeeded but the app errors on a missing column or table.
get_user_journey — reconstruct one end user’s timeline: their Chipp Insights beacon events (pageviews, identify, client-side errors) merged with server-side error lines mentioning them, oldest first. This is the support-ticket tool: aggregate analytics cannot answer “what happened to THIS person”.

Release control

Platform releases govern the self-hosted project; project deploys govern a customer project. Rollback-shaped actions are deliberately ungated — they are the recovery path, and they are reversible and audited.

get_platform_release_state — read the current mode (auto = every push deploys on the next train window, manual = builds publish but hold) and the desired-state pointer.
set_platform_release_mode — switch between auto and manual. Switching to manual is a pause, and is allowed freely.
list_platform_releases — recent platform releases, newest first: git sha, status (candidate / promoted / deployed / superseded / rolled_back), commit subjects, and operator notes.
promote_platform_release — promote a release to production, the same action as “Deploy now” on the Releases tab. Moves the desired-state pointer; the reconciler applies it.
rollback_platform_release — move the desired-state pointer back to a previously deployed release. Ungated and available in any mode.
list_platform_release_events — the release audit trail (published / promoted / rollback / deployed / superseded / mode_changed), newest first. Answers “who moved the pointer, when, and why”.
get_project_release_status — a project’s rollback-relevant deploy state: whether it is pinned, and which recent deploys are recalled.
rollback_project_deploy — roll a project back to a previously completed deploy by re-applying its built image, and pin the project so nothing rolls forward past it until cleared.
clear_release_pin — remove that pin so normal forward deploys resume.
recall_deploy — mark a deploy known-bad so it can never be chosen as a rollback target again. If the recalled deploy is the live one, a rollback to the newest non-recalled completed deploy is queued automatically.
clear_recall — un-mark a previously recalled deploy, when the recall turned out to be a misdiagnosis.
get_ci_run_log — read the REAL failed GitHub Actions job log for the project’s repo: which jobs failed, the exact step that failed, and a redacted tail of each job’s log. Call this FIRST when a deploy or CI run is red — a release checkpoint’s detail is a fixed placeholder line and tells you nothing.

Data-layer brief

record_data_layer_brief — record the project’s data-layer brief (what data the app stores and why). Recording after a confirmation resets the status to recorded, so a materially revised brief must be re-confirmed.
confirm_data_layer_brief — confirm the recorded brief. This is the only thing that sets the status to confirmed, which is what opens the build gate. A confirmed brief that says “no data layer” is a valid outcome for a static app.

Install the official Chipp chat widget into a project by AGENT NAME, so a project gets a real Chipp agent instead of a hand-rolled chat UI.

find_chipp_agent_by_name — resolve a Chipp agent by human-readable name across every workspace the current builder can access. Returns single (safe to install directly), multiple (show a picker, then pass the chosen application_id), or no match. The discovery step; always call it first.
install_chipp_agent_widget — install or update the widget for a project: resolves the agent by name (or by an application_id already confirmed via the picker), derives a theme from the project’s own design tokens, and commits the official widget-v2 embed to the project’s repo.
get_chipp_agent_widget_status — report the project’s CURRENT widget config (bound application, presentation mode/position/behavior/greeting, theme), or null if never installed. Call this BEFORE generating any new chat or AI-assistant UI: if a config exists, modify it through install_chipp_agent_widget instead of building a second integration.
remove_chipp_agent_widget — uninstall the widget: supersedes the persisted config and deletes the generated files in one commit. Never touches the underlying Chipp agent or its conversations. Idempotent.

Tool schemas (request/response reference)

For the complete machine-readable request and response schemas for dispatch_ticket, list_tickets, and get_ticket — including all field types, required/optional markers, annotated example payloads, and error code tables — see the Tickets MCP Tool Schemas reference page.

Notes

Reads are curated and bounded. The one SQL surface, query_database, is read-only (SELECT / CTE only, writes and DDL rejected) and tenant-scoped; there is no raw log-query tool. Every tool returns a structured result scoped to your tenant.
An OAuth connection (Option A) is scoped to your user and uses short-lived tokens that refresh automatically; revoke it by removing the connector in your client. An API key (Option B) is scoped to your tenant and stops working the instant you revoke it in Settings → API keys.
An API key authenticates any HTTP call to the platform API, not just MCP.
This page is also available as raw markdown at https://build.chipp.ai/alchemist-api/api/docs/mcp-server.md, and the whole doc set at https://build.chipp.ai/alchemist-api/api/docs/llms-full.txt — point an AI agent at either.