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

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).
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).

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).

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.

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.