# Usage & traffic (/dashboard/analytics)
The **Analytics** tab answers the questions traditional web analytics can't: which tools are being called, by which AI clients, from where, and whether those calls succeed. All traffic through your server's gateway URL is measured automatically — no SDK or instrumentation required.## Summary counters [#summary-counters]Four KPI cards at the top of the tab summarize the selected time window:- **Tool calls** — total MCP tool invocations.
- **Sessions** — distinct interactions (grouped conversation units, not raw transport sessions).
- **Error rate** — percentage of gateway requests that failed.
- **Avg latency** — mean request duration across the window.## Issues [#issues]The **Issues** card groups recurring errors on your server so you can triage, resolve, and track them over time — instead of hunting through individual gateway events.A **trend chart** at the top shows total issue occurrences over the selected time window. Status and kind filters apply to both the chart and the list below\.Each row summarizes one issue:- **Title** and affected **tool** (when applicable)
- **Kind** — how the issue was detected
- A **14-day trend sparkline** of occurrences
- **Event** and **session** counts
- **Last seen** timestampExpand a row to read a sample error message and see the sessions that hit this issue recently. Click a session to open the [session timeline](/dashboard/sessions).### Kind filter [#kind-filter]Filter issues by detection type:| Kind | Description |
| -------------- | -------------------------------------------------------------------------------- |
| **Detected** | AI-identified failures (brain icon) — distinct from transport or protocol errors |
| **Tool error** | Tool returned an error result |
| **JSON-RPC** | Protocol-level JSON-RPC errors |
| **Transport** | HTTP or connection failures |### Status workflow [#status-workflow]Switch between status pills at the top of the card:- **Unresolved** — active issues needing attention
- **Resolved** — fixed and closed
- **Ignored** — acknowledged but not actionable
- **All** — every issue regardless of statusUse row actions to **Resolve**, **Reopen**, **Ignore**, or **Unignore** an issue. Counts on each pill update as you triage.For the raw event stream behind an issue, use [Gateway Requests](/dashboard/observability).## MCP Usage [#mcp-usage]The **MCP Usage** card charts tool, resource, and prompt activity over time. Switch the category chips to focus on **Tools**, **Resources**, **Prompts**, or **All**.Each chart has its own **granularity** control — **Month**, **Week**, **Day**, **Hour**, or **Min** — so you can zoom from long-term trends down to the last hour.Below the chart, a **health table** lists each entity with **Calls**, **Error rate**, **Tool result error rate** (tools only), and **p50 / p95 / p99** latency. Expand a row to see grouped error messages and the sessions that hit that tool during the period.## Clients [#clients]The **Clients** card shows which MCP clients connect to your server — Cursor, Claude, ChatGPT, Windsurf, custom agents, and others.Toggle between a **bar breakdown** and a **timeline** view, and switch the breakdown dimension between **Client**, **Version**, and **Protocol**. A per-client **health table** mirrors the usage card: calls, error rate, and latency percentiles.Expand a client row to see matching sessions, or follow **View all** to open the [Sessions](/dashboard/sessions) tab pre-filtered for that client.## Geographic distribution [#geographic-distribution]**Requests by country** maps where traffic originates. Expand a country row to see sessions from that region and jump to the Sessions tab with the country filter applied.## Goals [#goals]The **Goals** card clusters what users are trying to accomplish, derived from session intent. AI-discovered goals appear with a brain icon; you can **Keep** (pin), **Edit**, or **Archive** them, or create manual goals yourself.Each goal shows a success-rate trend chart (**Achieved**, **Failed**, **Unknown** per day) and an expandable session list. Until enough tool-call sessions exist, the card shows a learning progress state instead.Goal classification requires **User intent capture** — see [Analytics capture](/dashboard/settings#analytics-capture) in Settings.## Average output tokens [#average-output-tokens]The **Average Output Tokens** card estimates how much text your tools, prompts, and resources return to clients (\~4 characters per token). Filter by **All**, **Tools**, **Prompts**, or **Resources**, and switch granularity like the other charts.Horizontal bars compare **definition** vs **response** token segments per entity; a time-series chart tracks the average over the window. Full detail requires **Capture payloads** to be enabled.## Toolbar controls [#toolbar-controls]- **Time range** — pill switcher for **24h**, **7d**, **30d**, and **90d**.
- **Internal traffic** — include or exclude Manufact dashboard, inspector, and checklist traffic (off by default).
- **Capture settings** — link to [Settings → Analytics capture](/dashboard/settings#analytics-capture).Analytics data refreshes automatically every few seconds while the tab is open.
How far back you can look depends on your plan: 7 days on Free, 30 days on
Hobby, 365 days on Startup, unlimited on Enterprise. See
[Billing & plans](/dashboard/billing).
## Session timeline [#session-timeline]Click any session badge or row across Analytics cards to open the **session timeline** drawer: a vertical replay of every MCP event in that interaction — methods, errors, arguments, response links, and AI-assigned goal/outcome when available.For the full searchable session list, use the dedicated [Sessions](/dashboard/sessions) tab.## Going deeper [#going-deeper]Analytics shows aggregate trends and health. To inspect individual gateway requests in real time, use [Gateway Requests](/dashboard/observability). Org-wide aggregates (total servers, tool calls, and sessions over the last 30 days) are also shown on the organization **Dashboard**.
# Manufact API keys and authentication (/dashboard/api-keys)
API keys authenticate programmatic access to your organization, from the REST API, CI pipelines, and scripts. Manage them on the **API Keys** page.## Creating a key [#creating-a-key]1) Go to **API Keys** and click **Create key**.
2) Give it a descriptive name (for example `ci-deploy`).
3) Pick an expiry, never, 7, 30, 90, or 365 days.
4) Copy the key immediately: it starts with `mcp_` and is shown only once.## Using a key [#using-a-key]Send it as a bearer token (an `x-api-key` header works too):```bash
curl -H "Authorization: Bearer mcp_..." \
https://cloud.manufact.com/api/v1/servers
```See the [Manufact API docs](https://cloud.manufact.com/docs) for the full REST API reference.## CLI authentication [#cli-authentication]For interactive use, the [CLI](/cli) doesn't need an API key, `mcp-use login` opens a browser flow (or a device-code flow on headless machines) and stores a session. Use API keys for non-interactive environments like CI.## Security [#security]- Scope each key to one purpose and name it accordingly, so revoking is painless.
- Prefer expiring keys; rotate non-expiring keys periodically.
- Treat keys like passwords, keep them in your CI secret store, never in the repository.
# Billing & plans (/dashboard/billing)
Billing is per organization, managed on the **Billing** page. It shows your current plan, subscription status, usage against limits, and the plan grid for upgrades.## Plans [#plans]| | Free | Hobby | Startup | Enterprise |
| ------------------------------------ | ----------------- | ----------------- | -------------------- | -------------------- |
| Projects | 1 | 2 | 20 | Unlimited |
| Requests / month | 30k | 300k | 3M | Unlimited |
| Analytics retention | 7 days | 30 days | 365 days | Unlimited |
| Team members | 1 | 2 | 10 | Unlimited |
| Publishing checklist | ✓ | ✓ | ✓ | ✓ |
| End-to-end checks (ChatGPT & Claude) | - | ✓ | ✓ | ✓ |
| Test suites (evals) | - | ✓ | ✓ | ✓ |
| Public Chat | - | ✓ | ✓ | ✓ |
| Submission pack | - | ✓ | ✓ | ✓ |
| Preview deployments | - | ✓ | ✓ | ✓ |
| GitHub org deploys | - | ✓ | ✓ | ✓ |
| Prevent scale to zero | - | ✓ | ✓ | ✓ |
| Regions | Auto routing only | Auto routing only | Auto + US, EU & APAC | Auto + US, EU & APAC |
| Support | Community | Email | Slack | Priority |Enterprise pricing starts at $1,000/month, contact sales from the plan grid.## Usage rates [#usage-rates]Metered usage is billed from a shared, dollar-denominated credit pool (1 credit = $0.01). Each plan includes a monthly credit grant that resets every month; once a paid plan's included credits run out, additional usage is billed pay-as-you-go. Rates are the same on every plan:{/* GENERATED:usage-rates START - bun scripts/generate-billing-docs.ts */}| Usage | Rate |
| ------------------------------------ | ----------------- |
| Requests | $0.10 per 1,000 |
| Eval runs | $1 per run |
| Publishing checklist | $0.10 per run |
| End-to-end checks (ChatGPT & Claude) | $2 per run |
| Submission pack | $5 per generation |
| Build minutes | $0.07 per minute |
| Bandwidth (egress) | $0.15 per GB |{/* GENERATED:usage-rates END */}## Usage [#usage]The Billing page tracks **Projects** and **Requests this period** against your plan, plus a credit-pool breakdown (granted, used, and remaining) and per-resource metered usage.Below the credit bar, the **usage breakdown** lists metered activity for the current billing cycle: requests, build minutes, eval runs, checklist runs, submission packs, and bandwidth. Each row shows the raw count and dollar cost drawn from your credit pool. If some credits were consumed but haven't rolled into the itemized rows yet, a **Recent usage (updating)** line shows the remainder until aggregation catches up.### What is metered [#what-is-metered]| Meter | Counts toward |
| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Requests** | MCP **tool calls** only (`tools/call`). Discovery traffic such as `tools/list`, `resources/list`, and `prompts/list` is not billed as a request. |
| **Bandwidth (egress)** | Bytes sent back to clients through the gateway, including streamed responses, widgets, and asset serving — measured from actual egress, not response headers. |
| **Build minutes**, **eval runs**, **publishing checklist**, **end-to-end checks**, **submission pack** | Each action listed in [Usage rates](#usage-rates) above. |### Plan limits vs credits [#plan-limits-vs-credits]**Plan limits** (projects, team seats, analytics retention, regions) are enforced in the dashboard — when a limit blocks an action, you see an upgrade prompt at the point of friction.**Monthly request limits** on the plan grid are soft caps used for upgrade guidance on paid plans. They do not cut off traffic by themselves.**Credit pool enforcement** works differently by plan:- **Free** — when the monthly credit grant is fully used, the gateway returns `402 Payment Required` until you upgrade or receive additional credits. Paid-plan overage does not apply.
- **Paid plans** — traffic keeps flowing after included credits are used; additional metered usage is billed pay-as-you-go at the rates above.### Platform credits [#platform-credits]Some organizations receive **platform credit** (for example YC or partner grants). When present, the Billing page shows the remaining balance. Platform credits roll over month to month and are applied automatically to invoices until depleted.### Billing emails [#billing-emails]Owners and admins receive transactional email for:- **Invoice receipts** when a payment succeeds
- **Usage alerts** when included credits are mostly used (around 80%) or fully used
- **Plan changes** — upgrades, downgrades, and billing-interval switches
- **Payment failures**
- **Monthly usage digest** — a per-resource cost summary for the previous calendar month (when there was metered usage)Manage the subscription and payment method from the Stripe portal; email notifications go to the org's billing contacts automatically.## Managing your subscription [#managing-your-subscription]- **Upgrade**: pick a plan in the grid; monthly and yearly billing are both available.
- **Switch billing period**: move between monthly and yearly at any time.
- **Downgrade or cancel**: handled through the **Stripe Customer Portal** via **Manage subscription**. Cancellations apply at the end of the billing period, and the status badge reflects it.Invoices, payment methods, and email receipt delivery also live in the Stripe portal.
# Build & runtimes (/dashboard/build-runtimes)
When you deploy from GitHub, Manufact analyzes your repository and generates a build for it automatically. This page explains how the runtime and package manager are chosen, and how dependency build scripts (like `esbuild`, `sharp`, or `protobufjs`) are handled, so your deploys behave the same way they do locally.
Manufact **honors your project's own configuration** rather than imposing its own.
## Supported runtimes [#supported-runtimes]
| Runtime | Detected from | Package managers |
| ----------------- | ------------------------------------- | ----------------------- |
| **Node.js** | `package.json` (+ a lockfile) | npm, pnpm, yarn, bun |
| **Python** | `pyproject.toml` / `requirements.txt` | uv, poetry, pipenv, pip |
| **Anything else** | a committed `Dockerfile` | your image |
Deno is not auto-detected. A `deno.json` on its own will not build, because the generated image has no `deno` binary and the start command exits with code `127`. To deploy Deno (or any unsupported runtime), commit a **`Dockerfile`** to your repo, Manufact uses it as-is.
## Package manager detection [#package-manager-detection]
The package manager is chosen from the lockfile in your repo:
| Lockfile | Package manager |
| ----------------------------- | --------------- |
| `pnpm-lock.yaml` | pnpm |
| `bun.lock` / `bun.lockb` | bun |
| `yarn.lock` | yarn |
| `package-lock.json` (or none) | npm |
## pnpm version selection [#pnpm-version-selection]
Manufact selects the pnpm version as follows:
1. **Your `packageManager` field wins.** If `package.json` pins pnpm (corepack format, e.g. `"packageManager": "pnpm@11.5.3"`), that exact version is used via Corepack, including pnpm 11.
2. **Otherwise, the lockfile decides.** `lockfileVersion` maps to a pnpm major:
| `lockfileVersion` | pnpm |
| ----------------- | ---- |
| 9 (and unknown) | 10 |
| 7 | 9 |
| 6 | 8 |
| 5 | 7 |
So a project with no `packageManager` field defaults to **pnpm 10**.
## Dependency build scripts (pnpm 10+) [#dependency-build-scripts-pnpm-10]
Since pnpm 10, dependency build/`postinstall` scripts are **blocked by default** for supply-chain safety. Manufact does **not** override this, it runs a plain `pnpm install` and respects your repo's own policy. This means you control exactly which dependencies are allowed to run scripts.
To allow a dependency to build, add it to `onlyBuiltDependencies` (run `pnpm approve-builds` locally, or edit by hand) in either `package.json` or `pnpm-workspace.yaml`:
```yaml title="pnpm-workspace.yaml"
onlyBuiltDependencies:
- esbuild
- "@parcel/watcher"
- protobufjs
- core-js
```
What happens to a dependency with a build script that is **not** on the allowlist depends on the pnpm version:
| pnpm | Unlisted build script | Effect |
| ------------------------------------ | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **10** (default) | Skipped with a warning | Build **succeeds**, but the dependency's native artifacts are not built, this can fail at runtime (e.g. a missing `esbuild`/`sharp` binary). |
| **11** (opt-in via `packageManager`) | `ERR_PNPM_IGNORED_BUILDS` | Build **fails**. pnpm 11 is strict by default. |
Add it to `onlyBuiltDependencies`. Servers scaffolded with `create-mcp-use-app` already include the right allowlist. If you pin pnpm 11, you must approve builds or the deploy fails.
npm, yarn, and bun run dependency build scripts by default (bun gates untrusted postinstall scripts but does not fail the install), so no allowlist is required for those package managers.
## Build and start commands [#build-and-start-commands]
By default Manufact runs your `build` script (when present) and your `start` script. You can override both per server, **Build command** and **Start command** in [Server settings](/dashboard/settings), which is useful for monorepos or when the MCP server is a sub-package (for example `npm run mcp:build` / `npm run mcp:start`).
# Changelog (/dashboard/changelog)
# Connecting clients (/dashboard/connect-clients)
Once deployed, your server speaks MCP over HTTP at its gateway URL. Any MCP-compatible client can connect to it. The dashboard generates the exact configuration for each one.## Add to client [#add-to-client]On any server page, click the URL chip in the header, then **Add to client**.You get one-click installs or copy-paste configuration for:- **Editors**: Cursor, VS Code, VS Code Insiders
- **Claude**: Claude Desktop and Claude Code
- **CLI agents**: Gemini CLI, Codex CLI
- **SDKs**: TypeScript and Python snippets using [mcp-use](https://docs.mcp-use.com)
- **mcp-use Agent**: attach the server to a hosted agent directly## Manual configuration [#manual-configuration]If your client isn't listed, use the standard MCP remote-server config with your gateway URL:```json
{
"mcpServers": {
"my-server": {
"url": "https://.run.mcp-use.com/mcp"
}
}
}
```## Connecting from code [#connecting-from-code]With the mcp-use TypeScript SDK:```ts
import { MCPClient } from 'mcp-use';
const client = new MCPClient({
mcpServers: {
myServer: { url: 'https://.run.mcp-use.com/mcp' },
},
});
```See the [mcp-use documentation](https://docs.mcp-use.com) for agents, tool calling, and the Python equivalent.## Authentication [#authentication]If your server requires OAuth, clients go through the standard MCP OAuth flow automatically. In the dashboard, the **Authenticate** button in the server header runs the same flow for the built-in Chat and inspector tabs. Expired credentials surface on the org **Dashboard** under **Needs Attention**.## Testing before you share [#testing-before-you-share]Use the server's **Chat** tab to talk to it with an agent, and the **Tools**, **Prompts**, and **Resources** tabs to verify everything is exposed as expected, the same inspector that powers [mcp-use](https://docs.mcp-use.com), embedded in the dashboard.
# Connect an existing server (/dashboard/connect-existing-server)
Use this path when your MCP server is **already hosted elsewhere** and you want Manufact's gateway, dashboard tools, and publish workflow without deploying code on the platform.Manufact creates an **external (URL-connected) server** that proxies your endpoint through the gateway. There is no build, deployment, or repository connection.## When to use this [#when-to-use-this]- You run MCP on your own infrastructure, another cloud, or a third-party host
- You want **Chat**, the inspector (**Tools**, **Prompts**, **Resources**), [Testing](/dashboard/testing), the [publish checklist](/dashboard/publish-checks), and the [submission pack](/dashboard/submission-pack)
- You do **not** need Manufact-hosted deployments, runtime logs, environment variables, analytics, observability, Public Chat, or custom domainsFor full hosting with auto-deploy on push, see the [Quickstart](/dashboard/quickstart) or [Creating servers](/dashboard/servers#import-from-github).## Where to start [#where-to-start]You can connect by URL from three places:| Entry point | Route |
| ------------------------ | ------------------------------------------------------------------------------------- |
| **Servers → New Server** | Scroll to **Connect an existing server** at the bottom of the new-server page |
| **Onboarding → Connect** | First sign-in wizard, **Connect** tile — see [Onboarding](/dashboard/onboarding) |
| **Marketing CTAs** | Log in via `/cloud/connect-external` (with optional `url` and `feature` query params) |## Step-by-step [#step-by-step]1) Paste the full MCP endpoint URL, for example `https://your-mcp-server.com/mcp`. Manufact accepts `http://` and `https://` URLs.
2) After you stop typing, Manufact **probes** the endpoint (about 750 ms debounce) to discover capabilities and read the server name.
3) If the server requires OAuth, click **Authenticate**, complete the flow, then continue.
4) When the status shows **Connected**, click **Connect**.
5) Manufact creates the server and opens:
* **New Server page** → server **Overview**
* **Onboarding** → [publish checklist](/dashboard/publish-checks) with `autorun=1`
External servers that use OAuth store tokens on the server record after you authenticate. If your endpoint's auth requirements change, reconnect from **Settings → External MCP URL**.
## What you get vs. hosted servers [#what-you-get-vs-hosted-servers]| Feature | External (URL-connected) | Manufact-hosted |
| --------------------------------------------- | ------------------------ | --------------- |
| Overview, Chat, Tools, Prompts, Resources | Yes | Yes |
| Testing, Checklist, Submission pack | Yes | Yes |
| Public Chat | No | Yes |
| Deployments, preview environments | No | Yes |
| Runtime logs | No | Yes |
| Environment variables | No | Yes |
| Analytics, Sessions, Issues, Gateway Requests | No | Yes |
| Domains (slug / custom) | No | Yes |Hosted servers route traffic through Manufact's build and deploy pipeline. External servers proxy live requests to your URL through the gateway.## Update the URL later [#update-the-url-later]Open the server's **Settings** tab. External servers show **External MCP URL** instead of **Repository**. Paste a new URL, re-authenticate if needed, and click **Save**. See [Server settings](/dashboard/settings).## Programmatic creation [#programmatic-creation]There is no CLI or Manufact MCP tool to create external servers today. Creation is designed for the dashboard flow above. The REST API accepts `POST /api/v1/servers` with `type: "external"` and a `url` field for integrations that need it.## Next steps [#next-steps]
# Deployments (/dashboard/deployments)
Every Manufact-hosted server is backed by a deployment pipeline. A deployment goes through the steps **Cloning → Analyzing → Building → Deploying → Health Checks → Complete**, and you can follow each step live from the **Deployments** tab.## Automatic deployments [#automatic-deployments]Pushing to your production branch triggers a deployment automatically, the production branch always deploys. You can tune what else triggers a deploy in [Server settings](/dashboard/settings):- **Watch paths (globs)**: only deploy when files under specific paths change (useful in monorepos).
- **Branch allow list (globs)**: control which other branches create deployments.
- **Wait for CI**: hold the deploy until your GitHub checks pass.## Production and preview environments [#production-and-preview-environments]- **Production** is the deployment of your configured production branch. It serves your main gateway URL.
- **Preview** environments are created per branch. Each gets its own MCP URL of the form `https://--br-.run.mcp-use.com/mcp`, so you can test changes against real clients before merging.Use the **environment selector** in the server header to switch between production and preview branches, the URL chip, logs, and environment variables all follow the selected environment.
Preview deployments require the Hobby plan or higher. See [Billing & plans](/dashboard/billing).
## Manual deployments [#manual-deployments]From the **Deployments** tab you can:- **Trigger deployment**: deploy a branch on demand.
- **Redeploy**: rebuild and ship the same source (after changing environment variables or settings). For a production-branch deployment that isn't currently active, this appears as **Promote to production**.
- **Set as Active**: switch traffic to a specific deployment.
- **Start / Stop / Delete**: manage stopped, failed, or old deployments.## Deployment history [#deployment-history]The history table shows every deployment with its MCP URL, source branch and commit, duration, and creation time. Click a row to open the detail drawer with **Build Logs** (broken down by pipeline step) and **Runtime Logs** tabs.## Build configuration [#build-configuration]The build is controlled by settings configured at creation time and editable later in [Server settings](/dashboard/settings):- **Framework preset**: mcp-use, mcp-python, FastMCP, and others, or **Dockerfile** for full control.
- **Root directory**: where your server lives inside the repository.
- **Build command / start command**: override the preset defaults.## Troubleshooting failed deployments [#troubleshooting-failed-deployments]Failed deployments surface on the org **Dashboard** under **Needs Attention**, and trigger an email if you have **Failed deployment emails** enabled in account settings (on by default). Open the deployment drawer to read build logs step by step, a failure at **Health Checks** means the deployed server didn't respond correctly, which usually points to a wrong start command or a missing environment variable.
# Domains (/dashboard/domains)
Every Manufact-hosted server gets a free URL based on its **slug**, and you can add custom domains on top. Manage both on the **Domains** tab.## Slug-based URL [#slug-based-url]Your server's default URL looks like:```text
https://.run.mcp-use.com/mcp
```The slug is generated when the server is created. You can edit it on the Domains tab: the change is staged as **Pending deploy** and the old slug keeps serving traffic until your next production deployment, when the new slug takes over. Setting the slug back to its current value cancels the pending change.## Custom domains [#custom-domains]To serve your MCP server from your own domain:1. Click **Add domain** and enter the domain (for example `mcp.example.com`).
2. Add the **CNAME** record shown in the dashboard at your DNS provider, pointing to `deploy.mcp-use.com`.
3. Wait for verification, the dashboard re-checks automatically every few seconds, and SSL is provisioned for you once DNS resolves.
If verification reports a CAA error, add CAA records on your apex domain
allowing the certificate authorities listed in the dashboard
(`letsencrypt.org`, `pki.goog`, `digicert.com`, `ssl.com`).
Once verified, the domain shows **Pending deploy** until you redeploy, the dashboard prompts you. Removing an active domain is also staged until the next production deploy; removing a domain that never verified deletes it immediately.## Which URL should I distribute? [#which-url-should-i-distribute]All URLs, slug and verified custom domains, route to the same production deployment and are tracked identically in [analytics](/dashboard/analytics). Distribute a custom domain if you want the URL to survive a potential migration, or the slug URL for zero setup.
# Environment variables (/dashboard/environment-variables)
Environment variables let you pass secrets and configuration to your server at runtime, API keys, database URLs, feature flags. Manage them on the **Environment Variables** tab of your server.## Scoping [#scoping]Variables are scoped to an **environment**. Use the environment selector in the server header to edit variables for:- **Production**: your production branch deployment.
- **Preview**: a specific preview branch.This lets you point preview deployments at staging databases or sandbox API keys while production uses the real thing.## Adding variables [#adding-variables]Add keys and values one by one, or paste the contents of a `.env` file to import many at once. You can also set variables during the initial deploy on the **Configure Deployment** screen.
Saving variables does not restart your server. Trigger a redeploy from the
[Deployments](/dashboard/deployments) tab for changes to take effect, the
dashboard reminds you after saving.
## Platform-managed variables [#platform-managed-variables]Manufact injects some variables automatically at deploy time, such as `MCP_URL` (the public URL of the deployment) and `CSP_URLS`. These appear as prefilled rows so you can see exactly what your server receives; they're only saved as your own variables if you override their values.## Best practices [#best-practices]- Keep secrets out of your repository, set them here instead of committing `.env` files.
- Use separate values per environment so previews can't touch production data.
- After rotating a secret, redeploy so the running deployment picks it up.
# Welcome to Manufact Cloud (/dashboard)
Manufact Cloud is an all-in-one platform for MCP servers: deploy from GitHub in minutes, watch every tool call with MCP-native analytics, and ship your server to any AI client, Cursor, Claude, ChatGPT, and more.## Manufact Developer Resources [#manufact-developer-resources]For API docs, OpenAPI, authentication, webhooks, MCP server access, CLI docs, SDK docs, and brand assets, start at the official [Manufact developer resources](https://manufact.com/developers) page or its [markdown version](https://manufact.com/developers.md). Agents can also fetch the shared [agent deploy prompt](https://manufact.com/prompt.md) directly.
## For Agents [#for-agents]### Build an MCP server, ChatGPT App, or Claude Connector [#build-an-mcp-server-chatgpt-app-or-claude-connector]Paste this prompt into Cursor, Claude Code, Codex, or another coding agent — or fetch the same instructions from [manufact.com/prompt.md](https://manufact.com/prompt.md).Install the skill directly: ### Manage a server deployed on Manufact [#manage-a-server-deployed-on-manufact]Connect the official [Manufact MCP server](/mcp) (`https://mcp.manufact.com/mcp`) to deploy, debug, and monitor servers from your agent. Cursor and VS Code open in one click; other clients copy a ready-made command.See the [MCP server reference](/mcp) for all 20 tools.## For Humans [#for-humans]### Getting started [#getting-started]Get your MCP server up and running in minutes.
### Build & Deploy [#build--deploy]
### Monitoring [#monitoring]
### Distribution [#distribution]
### Publish [#publish]
### Organization [#organization]
# Manufact webhooks and GitHub integration (/dashboard/integrations)
Manufact deploys from GitHub through a GitHub App, managed on the **Integrations** page of your organization.## Connecting GitHub [#connecting-github]1) Go to **Integrations** and click **Connect** next to GitHub (or **Connect new Org** to add another GitHub account or organization).
2) GitHub asks which repositories the app may access, grant all repositories or pick specific ones.
3) Back in Manufact, the installation appears in the list and its repositories become available in the **New Server** repo picker.You can connect multiple GitHub accounts and organizations to a single Manufact organization.## What the app does [#what-the-app-does]* Lists repositories in the server creation flow.
* Receives push webhooks to trigger [automatic deployments](/dashboard/deployments).
* Reads commit statuses when **Wait for CI** is enabled.
* Links deployments back to their commits and branches in the dashboard.
Deploying from a GitHub organization repository requires the Hobby plan or
higher, personal GitHub account installs work on Free. See
[Billing & plans](/dashboard/billing).
## Changing repository access [#changing-repository-access]Repository access is managed on GitHub's side: open the installation from the Integrations page to add or remove repositories. To disconnect an installation entirely, use **Disconnect**: servers deployed from it keep running, but lose automatic deploys until reconnected.## Disconnecting a server's repository [#disconnecting-a-servers-repository]Per-server disconnect is different from disconnecting the organization GitHub App:| Action | Where | Effect |
| --------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Disconnect repository | Server → Settings → Repository | That server stays online. Automatic and manual deploys pause until you connect a repository again. Domain, env vars, analytics, and deployment history are preserved. |
| Disconnect GitHub App | Integrations | Removes the installation for the organization. Servers keep running, but any server still linked to that installation cannot deploy until the App is reconnected (or the server is reconnected to another installation). |To point an existing server at a different repository (for example after a monorepo migration), disconnect the current repository, then use **Connect repository** and choose the new `owner/repo`, production branch, and optional root directory. That updates the link in place (no new server) and re-enables push-to-deploy; it does not start a deployment — Deploy manually or push when you want to ship.
# Runtime logs (/dashboard/logs)
The **Runtime logs** tab streams runtime output — everything your server writes to stdout and stderr — from the **active healthy deployment** of the selected environment.## Runtime vs build logs [#runtime-vs-build-logs]There are two kinds of logs in Manufact Cloud:| Type | Where | What it contains |
| ---------------- | --------------------------------------------------------- | ---------------------------------------------------------------- |
| **Runtime logs** | **Runtime logs** tab | Your server's output while serving traffic |
| **Build logs** | [Deployments](/dashboard/deployments) → deployment drawer | The build pipeline output for one specific deployment, per phase |If the Runtime logs tab is empty, check that the selected environment has a deployment in the **running** state — logs only stream from a live deployment.## Tips [#tips]- Use the environment selector in the header to view logs for a preview branch instead of production.
- A tail of recent runtime logs is also shown on the server **Overview** page under the active deployment card.
- Log output is the fastest way to debug tool errors surfaced in [Gateway Requests](/dashboard/observability): find the failing request there, then match its timestamp here.
# Gateway Requests (/dashboard/observability)
While [Usage & traffic](/dashboard/analytics) shows aggregate trends, the **Gateway Requests** tab shows individual events: every request flowing through the gateway, refreshed every few seconds.## Event stream [#event-stream]The event table lists each request with its status, timestamp, session, client, method, details, and duration. Use the search bar and **column filters** to isolate specific tools, error responses, or clients:- **Status** — success, error, or other outcome
- **Client** — MCP client name
- **Method** — MCP method (e.g. `tools/call`, `initialize`)Click an event to open the **session detail** view: the full sequence of requests in that MCP session, so you can reconstruct exactly what a client did — initialization, tool listing, tool calls, and errors — in order.For grouped errors tracked across sessions, see the **Issues** card on [Usage & traffic](/dashboard/analytics). For a replay-oriented view with goal and outcome context, use [Sessions](/dashboard/sessions).## Payload capture [#payload-capture]By default Manufact stores request metadata only. Toggle **Capture payloads** to also store full request and response bodies for each event — invaluable when debugging why a tool call failed or what arguments a client actually sent.The same toggle lives under [Settings → Analytics capture](/dashboard/settings#analytics-capture), along with **User intent capture**.
Payloads can contain user data. Enable capture only when you need it, and
disable it again when you're done debugging.
## Performance metrics [#performance-metrics]Charts above the event stream track request volume, error rates, and latency over time, scoped to the same filters as the table.## Retention [#retention]Gateway request data follows the same retention windows as analytics: 7 days on Free, 30 on Hobby, 365 on Startup, unlimited on Enterprise.
# Onboarding (/dashboard/onboarding)
When you first sign in to Manufact Cloud, an **onboarding wizard** walks you through workspace setup and your first server. You can also reach the same flows later from **Servers → New Server** and the [Quickstart](/dashboard/quickstart).## Who sees it [#who-sees-it]- **New accounts** land on `/onboarding` after sign-up or checkout
- **Returning users** with an organization may skip organization creation; the wizard advances to invite members or goal selection
- Each step has **Skip** (go to the dashboard) and **Back** where applicable## Wizard steps [#wizard-steps]| Step | Screen | Notes |
| ---- | ------------------------------ | ------------------------------------------------------------------------------------------------------------- |
| 0 | Company website / organization | Creates or updates your organization name from your company domain. Skipped when you already have a named org |
| 1 | Invite members | Shown when your plan allows team invites; optional |
| 2 | What are you trying to do? | Choose **Deploy**, **Connect**, or **Create** — see below |
| 3+ | Path-specific | Depends on the tile you pick |## Deploy [#deploy]**Best for:** hosting on Manufact with GitHub, preview environments, analytics, and observability.1) On **What are you trying to do?**, pick **Deploy**.
2) **Connect GitHub** (or **Select Repository** if already connected).
3) Choose a repository and configure the deployment (branch, region, environment variables).
4) Click **Deploy** and wait for the pipeline to finish.This path matches [Quickstart](/dashboard/quickstart) steps 2–4. After a successful deploy you land on the server overview or dashboard.## Connect [#connect]**Best for:** a server you already host elsewhere — evals, publish checks, and submission pack without a Manufact deployment.1) On **What are you trying to do?**, pick **Connect**.
2) Paste your MCP server URL on the **Connect your MCP server** screen.
3) Complete OAuth if prompted, then click **Connect**.Manufact opens the server's [publish checklist](/dashboard/publish-checks) with `autorun=1` so checks start immediately. For the full URL-connect guide, see [Connect an existing server](/dashboard/connect-existing-server).## Create [#create]**Best for:** starting from scratch with a coding agent.1) On **What are you trying to do?**, pick **Create**.
2) Copy the agent prompt (includes a pre-approved CLI device code so `mcp-use login` works without an extra browser step).
3) Paste the prompt into Cursor, Claude Code, Codex, or another agent.
4) The wizard shows **CLI deploy progress** while the agent scaffolds and deploys via the [CLI](/cli).Install the skill directly: The device-code flow is documented in [CLI login](/cli/login) (`--device-code`).## Skip and back [#skip-and-back]- **Skip** on any step saves progress where applicable and sends you to the organization dashboard.
- **Back** returns to the previous step (for example, from goal selection to invite members, or to organization setup).## After onboarding [#after-onboarding]| Path | Typical landing page |
| ------- | ------------------------------------------------------- |
| Deploy | Server overview or deployments |
| Connect | Server checklist (`/servers/{id}/checklist?autorun=1`) |
| Create | CLI progress step, then dashboard when deploy completes |## Next steps [#next-steps]
# Roles & permissions (/dashboard/permissions)
Access in Manufact Cloud is controlled per organization by **role-based access control (RBAC)**. Every member has a role, and each role grants a set of permissions expressed as **resource + action** pairs (for example, `server: create` or `deployment: delete`).
## Built-in roles [#built-in-roles]
Three built-in roles are available on **every plan** and cover most teams. See [Team](/dashboard/team) for how to invite members and assign roles.
| Role | Summary |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Owner** | Everything an admin can do, plus manage billing and **delete the organization**. Can invite/promote any role, including other owners. |
| **Admin** | Full operational access plus billing. Cannot delete the organization or promote to owner. |
| **Member** | Full operational access to build and deploy. Cannot change billing, manage custom roles, or delete the organization. |
The built-in **member** role is not read-only — members can create, update,
and delete servers, deployments, agents, API keys, domains, and GitHub
integrations. To give someone narrower access, use an Enterprise custom role.
## Permission matrix [#permission-matrix]
Roles are built from these resources and actions. The **Roles & permissions** panel on the Team page shows the same matrix and is the source of truth for what a custom role can be granted.
| Resource | Actions | Member | Admin | Owner |
| ------------------- | ---------------------------- | :----------: | :----------: | :------------------: |
| Organization | view, update, delete | view, update | view, update | view, update, delete |
| Members | create, update, delete | yes | yes | yes |
| Invitations | create, cancel | yes | yes | yes |
| Teams | create, update, delete | yes | yes | yes |
| Roles & permissions | create, view, update, delete | view | full | full |
| Agents | create, view, update, delete | full | full | full |
| Servers | create, view, update, delete | full | full | full |
| Server pools | create, view, update, delete | full | full | full |
| Deployments | create, view, update, delete | full | full | full |
| Domains | create, view, update, delete | full | full | full |
| Chats | create, view | full | full | full |
| GitHub | create, view, update, delete | full | full | full |
| API keys | create, view, update, delete | full | full | full |
| Server evals | run | yes | yes | yes |
The only differences between built-in roles are in the **Administration** group: members can only **view** the Roles & permissions catalog, and only owners can **delete** the organization. All three roles share the same operational access.
The live catalog is served from `GET /api/v1/permissions/catalog` (public,
cached) and powers the dashboard matrix. Use it if you build tooling around
roles so your labels stay in sync with the backend.
## Custom roles (Enterprise) [#custom-roles-enterprise]
Custom roles are available on the **Enterprise** plan.
[Contact us](https://manufact.com/book-call) to enable RBAC for your
organization.
On Enterprise, owners and admins can define **custom roles** from the **Roles & permissions** panel with a fine-grained permission matrix — for example, a `deployer` role that can create and update servers and deployments but cannot manage billing, members, or delete anything.
Custom roles are scoped to the organization that creates them and are assigned to members the same way as built-in roles.
### What happens off Enterprise [#what-happens-off-enterprise]
If an organization is not on Enterprise (or downgrades from it):
* New custom roles cannot be created, and existing custom roles cannot be edited or deleted.
* Members cannot be assigned to a custom role.
* **Members already assigned to a custom role keep their existing access** until an admin reassigns them. To fully remove custom-role access, move those members to a built-in role.
## How permissions are enforced [#how-permissions-are-enforced]
Permissions are checked on the server for every API request — the dashboard also hides actions you can't perform, but the backend is the source of truth. Access is always scoped to the organization the resource belongs to, so members of one organization can never see or modify another organization's servers, deployments, or data.
# Public Chat (/dashboard/public-chat)
**Public Chat** turns your server into a product anyone can try from a browser, no MCP client required. In the dashboard, open your server and go to **Publish → Public Chat** to configure it.Public Chat requires the [Hobby plan or higher](/dashboard/billing).## Enabling Public Chat [#enabling-public-chat]1) Toggle Public Chat on.
2) Set a **title** and **description** override for the chat page.
3) Optionally add **suggested questions** (up to 8) that appear as starter prompts; there's an AI button to generate them from your server's capabilities.## SEO metadata [#seo-metadata]The **SEO Metadata** card controls how your public chat page appears in search results and when shared on social networks:- **Title** and **description** — override the defaults pulled from your server's MCP metadata.
- **Generate with AI** — drafts title and description from your server's tools and capabilities (also runs automatically the first time you enable Public Chat if both fields are empty).
- **OG image** — upload a custom 1200×630 image, or use the auto-generated dynamic preview. Reset to revert to the default.
- **Google-style preview** — shows how the page will look in search snippets before you publish.The tab shows a live preview of the page, and once enabled your chat is available at your server's URL with a `/chat` path:```text
https://.run.mcp-use.com/chat
```Verified custom domains work too: `https:///chat`.## Public transcripts [#public-transcripts]The **Public transcripts** table lists chat threads so you can see how visitors actually use your server: which questions they ask and which tools the agent invoked to answer them.
If your server needs credentials, think carefully before exposing it through
Public Chat: visitors interact with it using the server's configured access.
The dashboard shows a security warning banner for this case.
## When to use it [#when-to-use-it]- **Demos**: share a working MCP server with stakeholders or on social media.
- **Docs**: let users try your tools before installing them in a client.
- **Validation**: watch real conversations to refine tool names and descriptions before [publish checks](/dashboard/publish-checks) or generating a [submission pack](/dashboard/submission-pack).
# Publish checks (/dashboard/publish-checks)
Before you distribute a server, to your users, the MCP registry, or an app directory, the **Checklist** tab in the **Publish** section helps you verify it's ready. It works for Manufact-hosted and external (URL-connected) servers.## Checklist [#checklist]The **Checklist** tab runs an automated audit of your server for protocol compliance and platform readiness: initialization behavior, tool schemas, error handling, metadata quality, and more. The basic checklist is available on every plan and is billed at [$0.10 per run](/dashboard/billing).1) Open your server, go to **Publish → Checklist**, and click **Run checklist**.2) Each check reports as **passed**, a **warning**, an **error**, or **skipped**, with an explanation. The summary card shows your score and counts by status.While a run is in progress, use **Stop** to cancel it. Partial results streamed so far are kept.### End-to-end checks (ChatGPT & Claude) [#end-to-end-checks-chatgpt--claude]On [Hobby and above](/dashboard/billing), the checklist also includes **end-to-end checks** that exercise your server live in ChatGPT and Claude. These verify tool calls and widget rendering in real clients, not just protocol compliance. E2E checks are billed at [$2 per run](/dashboard/billing).Free plans run the basic checklist only. Upgrade to Hobby to unlock E2E checks.3) Expand a category with issues to read **How to fix** guidance for each failed check.4) For fixable issues you can copy a **fix prompt** into your own coding agent, or run the built-in **autofix** flow (requires a connected GitHub repository). In-flight autofix jobs can be stopped from the dashboard.Run it again after deploying fixes; runs are kept so you can track progress over time.## Recommended publish flow [#recommended-publish-flow]1) Pass the **Checklist** with no failures.
2) Validate behavior with [test suites](/dashboard/testing) across clients and models.
3) Try it end to end via [Public Chat](/dashboard/public-chat) or your own client setup.
4) Generate a [submission pack](/dashboard/submission-pack) and submit to the app directory.
# Quickstart (/dashboard/quickstart)
This guide walks you through deploying an MCP server from a GitHub repository and connecting it to an AI client.Prefer to have an agent do it? Copy the onboarding prompt and paste it into Cursor, Claude Code, or Codex — or fetch it directly at [manufact.com/prompt.md](https://manufact.com/prompt.md).## Choose your path [#choose-your-path]| Path | Best for | Guide |
| ------------------- | ------------------------------------- | ---------------------------------------------------------------------------- |
| Deploy from GitHub | Full hosting, auto-deploys, analytics | This quickstart (below) |
| Connect by URL | Server already hosted elsewhere | [Connect an existing server](/dashboard/connect-existing-server) |
| Build with an agent | Starting from scratch | [Onboarding → Create](/dashboard/onboarding#create) or copy the prompt above |First time in Manufact? The [onboarding wizard](/dashboard/onboarding) walks you through organization setup and these same three paths.## Before you start [#before-you-start]You need:- A [Manufact Cloud account](https://manufact.com/cloud): the Free plan covers your first server.
- One of: a GitHub repository with an MCP server, an existing MCP URL to connect, or a coding agent to scaffold a new project.If you don't have a server yet, use the agent prompt above, start from a template, or follow [Connect an existing server](/dashboard/connect-existing-server) if you already have a URL — see [Creating servers](/dashboard/servers).## 1. Create an organization [#1-create-an-organization]When you first sign in, the onboarding wizard asks you to create an organization. Organizations own servers, billing, and team members. You can create more organizations later from the organization switcher.## 2. Import your repository [#2-import-your-repository]1) Go to **Servers** and click **New Server**.
2) Choose **Import from GitHub**.
3) If this is your first deploy, connect the Manufact GitHub App and grant it access to your repository. See [GitHub integration](/dashboard/integrations) for details.
4) Pick the repository you want to deploy.## 3. Configure the deployment [#3-configure-the-deployment]On the **Configure Deployment** screen:- **Branch**: the branch to deploy as production (usually `main`).
- **Region**: leave on `AUTO`, or pick US / EU / APAC on the Startup plan and above.
- **Environment variables**: add any secrets or config your server needs. You can also paste the contents of a `.env` file to fill them in at once.
- **Advanced configuration** (optional), set a root directory for monorepos, watch paths, a Dockerfile path, or a framework preset. Manufact auto-detects most setups.Click **Deploy**. The pipeline clones your code, analyzes it, builds it, deploys it, and runs health checks before routing traffic to it, you can follow each step live.## 4. Get your server URL [#4-get-your-server-url]Once the deployment is healthy, your server is available at its gateway URL, shown in the header of every server page:```text
https://.run.mcp-use.com/mcp
```Copy it from the URL chip, or customize the slug and add custom domains on the [Domains](/dashboard/domains) tab.## 5. Connect a client [#5-connect-a-client]Click **Add to client** next to the server URL to get one-click installs and ready-made config snippets for Cursor, VS Code, Claude Desktop, Claude Code, Gemini CLI, Codex CLI, and the mcp-use SDKs. See [Connecting clients](/dashboard/connect-clients).You can also test immediately in the dashboard: the **Chat** tab connects an agent to your server, and **Tools**, **Prompts**, and **Resources** list everything your server exposes.## Next steps [#next-steps]
# Creating servers (/dashboard/servers)
A **server** is the central object in Manufact Cloud: it bundles your deployments, environments, URL, analytics, and publish workflow. Create one from **Servers → New Server**. There are four ways to get a server onto the platform.## Import from GitHub [#import-from-github]The most common path. Pick a repository through the Manufact GitHub App and configure the deployment, branch, region, environment variables, and optional advanced settings (root directory, watch paths, Dockerfile, framework preset).Manufact detects common MCP frameworks automatically, mcp-use (TypeScript and Python), FastMCP, tmcp, xmcp, Skybridge, and more. If your project doesn't match a preset, point the build at a Dockerfile instead.After the first deploy, every push to the production branch deploys automatically. See [Deployments](/dashboard/deployments).
Deploying from a GitHub organization repository (rather than a personal account) requires the Hobby plan or higher. See [Billing & plans](/dashboard/billing).
## Start from a template [#start-from-a-template]The **Templates** library offers ready-made MCP server scaffolds — starter and MCP Apps scaffolds, OAuth provider templates, example apps, and reference servers for other MCP frameworks (FastMCP, tmcp, xmcp, Skybridge, and the official TypeScript and Python SDKs). Browse them all in the [templates gallery](https://manufact.com/templates).Selecting a template creates a new repository from the template in your connected GitHub account or organization and deploys it, so you get a working server you can iterate on immediately.## Build with an agent [#build-with-an-agent]Paste the onboarding prompt into Cursor, Claude Code, Codex, or another coding agent. It walks the agent through scaffolding, deploying via the CLI, and returning your MCP URL and dashboard link.Install the skill directly: ## Connect an existing server [#connect-an-existing-server]Already hosting an MCP server elsewhere? On **New Server**, scroll to **Connect an existing server** and paste your MCP URL. No deploy required — Manufact proxies the endpoint for Chat, testing, and the publish workflow\.See [Connect an existing server](/dashboard/connect-existing-server) for the step-by-step flow, OAuth, and which features are available on external servers.## Server pages [#server-pages]Every server has the following sections in its sidebar:| Section | What it does |
| ------------------------------- | ---------------------------------------------------------------------------------- |
| **Overview** | Connection status, capability counts, active deployment, recent tool-call activity |
| **Chat** | Talk to your server with an agent, directly in the dashboard |
| **Tools / Prompts / Resources** | Inspect the MCP primitives your server exposes |
| **Deployments** | History, manual triggers, build logs, redeploy |
| **Runtime logs** | Runtime logs from the active deployment |
| **Gateway Requests** | Live gateway event stream and optional payload capture |
| **Environment Variables** | Per-environment configuration |
| **Analytics** | Usage & traffic, health tables, goals, and output tokens |
| **Sessions** | Browse, filter, and replay MCP interactions |
| **Issues** | Grouped errors and AI-detected failures |
| **Testing** | Automated test suites (Beta) |
| **Public Chat** | Hosted, shareable chat for visitors — see [Public Chat](/dashboard/public-chat) |
| **Checklist / Submission pack** | App-directory publish workflow |
| **Domains** | Slug and custom domains |
| **Settings** | Repository, region, build, analytics capture, and danger zone |## Chat [#chat]Use the **Chat** tab to send prompts and verify tool calls against your server without leaving the dashboard.
# Sessions (/dashboard/sessions)
The **Sessions** tab lists every MCP **interaction** on your server — a grouped conversation unit that may span multiple transport sessions. Use it to find specific client activity, inspect goals and outcomes, and open the session timeline for a full event replay.
## Session table [#session-table]
Each row shows:
* **Client** and version
* A **mini event chart** (recent activity dots)
* **Goal** and **Outcome** when AI classification has run (Achieved, Failed, Unknown)
* **Tool calls**, **Errors**, and **Country**
* **Last seen** timestamp
Click a row to open the **session timeline** drawer — the same replay view available from Analytics cards.
## Filters and sorting [#filters-and-sorting]
Use the toolbar and column controls to narrow the list:
* **Time range** — **24h**, **7d**, **30d**, or **90d**
* **Internal traffic** — include or exclude Manufact dashboard traffic
* **Only with tool calls** — hide initialize-only sessions (on by default)
* **Client**, **Goal** (with outcome), and **Country** column filters
* Sort by **Tool calls**, **Errors**, or **Last seen**
The table loads **50 sessions at a time** — scroll to fetch more.
## Deep links from Analytics [#deep-links-from-analytics]
Cards on [Usage & traffic](/dashboard/analytics) link here with filters pre-applied — for example, all sessions for a specific client, country, or tool during a time window. URLs carry query parameters so you can bookmark or share a filtered view.
## Session timeline [#session-timeline]
The timeline drawer shows every gateway event in order: initialization, tool listing, tool calls, errors, and optional payload previews when [Capture payloads](/dashboard/settings#analytics-capture) is enabled.
When classification has run, an **insight panel** at the top shows the assigned goal, outcome, intent summary, and classifier reasoning. You can manually override the goal or outcome from the drawer.
# Server settings (/dashboard/settings)
The **Settings** tab is the control panel for a server's configuration. Most changes require a redeploy to take effect, the dashboard prompts you when that's the case.## General [#general]Rename the server and update its description. Renaming doesn't change the server's slug, edit that on the [Domains](/dashboard/domains) tab.## Repository [#repository]See and manage the GitHub connection backing your server. For external (URL-connected) servers, this section is replaced by the **External MCP URL** field instead.## Deployment paths & triggers [#deployment-paths--triggers]Fine-tune when and how Git pushes deploy:- **Production branch**: which Git branch serves your canonical production URL and always auto-deploys.
- **Root directory**: the folder containing your server, for monorepos.
- **Branch allow list (globs)**: which branches are allowed to create deployments. The production branch always deploys.
- **Watch paths (globs)**: only changes under these paths trigger a deploy.
- **Wait for CI**: wait for GitHub checks to pass before building.## Region [#region]Choose where your server runs: **AUTO** (default), **US**, **EU**, or **APAC**. Specific regions require the Startup plan or higher; AUTO picks the best available location.## Deployment resources [#deployment-resources]**Prevent Scale to Zero** keeps your server warm so clients never hit a cold start. Available on paid plans, see [Billing & plans](/dashboard/billing).## Build & runtime settings [#build--runtime-settings]Override the framework preset's **Build Command** and **Start Command** when your project needs custom steps, and set the **Dockerfile Path** and **Port** when building from a Dockerfile.## Server configuration (JSON) [#server-configuration-json]Advanced connection configuration for the dashboard's own client (Chat and inspector tabs): custom headers, OAuth settings, and connection overrides, as a JSON document.## Rate limiting [#rate-limiting]Optionally throttle traffic at the gateway **per caller** (by real client IP):- **Disabled by default** — turn on with the toggle on the Settings tab.
- **Requests per minute** — max requests each caller can make in a rolling 60-second window (default 1,000 when enabled without a custom value).
- Exceeded callers receive `429 Too Many Requests` until the window resets.Applies independently to this server. Does not replace plan-level credit enforcement on the Free tier.## IP allowlist [#ip-allowlist]Restrict which IP addresses can reach your server through the gateway, useful for servers that should only be reachable from your own infrastructure. This section is rolling out gradually and may not be visible on your account yet.## Analytics capture [#analytics-capture]Toggles here control what the gateway stores for [Usage & traffic](/dashboard/analytics) (including the Issues card) and [Sessions](/dashboard/sessions). Changes apply immediately — no redeploy required.| Toggle | What it enables |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Capture payloads** | Store request and response bodies for gateway events — powers session timeline previews, output token estimates, tool-definition sizing, and richer error context |
| **User intent capture** | Inject an optional `user_intent` field on tool calls so AI goal discovery and session classification can cluster what users are trying to accomplish |
Payloads can contain user data. Enable capture only when you
need it, and disable it again when you're done debugging.
The **Capture payloads** toggle also appears on the [Gateway Requests](/dashboard/observability) tab for quick access while debugging.## Danger zone [#danger-zone]**Delete Server** permanently removes the server, its deployments, URLs, and analytics. This cannot be undone.
# Submission pack (/dashboard/submission-pack)
When you submit an MCP server to an app directory, for example the ChatGPT App Directory, you need more than a working endpoint. The **Submission pack** tab in the **Publish** section drafts the materials directories ask for, based on your server's actual capabilities. It works for Manufact-hosted and external (URL-connected) servers.Submission pack generation requires the [Hobby plan or higher](/dashboard/billing) and is billed at [$5 per generation](/dashboard/billing).## What it generates [#what-it-generates]Open your server and go to **Publish → Submission pack**, then click **Generate pack**. The pack includes:- Directory listing copy (name, descriptions, category)
- **Tool justifications**: why each tool needs the access it requests
- Reviewer **test-case templates** so reviewers can exercise your server quicklyEdit the drafts to match your voice, then paste them into the submission form.## Demo video and screenshots [#demo-video-and-screenshots]The pack can also generate a **demo video** and **screenshots** for app directory listings.- **Custom instructions** — steer what the demo or screenshots should emphasize (for example, "show the checkout flow"). Layout and dimension constraints still apply.
- **Tool selection** — for screenshots, pick up to four MCP tools to capture. When omitted, the generator chooses representative tools.
- **Live progress** — screenshot generation streams partial results to the dashboard as they complete.
- **Stop** — cancel an in-flight demo video or screenshot job from the dashboard.## When to use it [#when-to-use-it]Generate the submission pack after your server passes the [publish checklist](/dashboard/publish-checks) and you've validated behavior with [test suites](/dashboard/testing). A typical flow:1) Clear the [Checklist](/dashboard/publish-checks) with no failures.
2) Run [test suites](/dashboard/testing) across clients and models.
3) Try the server via [Public Chat](/dashboard/public-chat) or your own client.
4) Generate the submission pack and submit.
# Team (/dashboard/team)
Everything in Manufact Cloud belongs to an **organization**: servers, billing, integrations, and API keys. The **Team** page is where you manage who has access.## Inviting members [#inviting-members]1. Go to **Team** and enter the email address of the person to invite.
2. Pick a role and send the invitation.
3. Pending invitations are listed until accepted; you can revoke them at any time.
The number of members depends on your plan: 1 on Free, 2 on Hobby, 10 on
Startup, unlimited on Enterprise. See [Billing & plans](/dashboard/billing).
## Roles [#roles]Three built-in roles cover most teams. Each role can only invite or assign roles **at or below their own level** (for example, a member cannot invite an admin).| Role | Capabilities |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Owner** | Full operational access, billing and subscription management, delete the organization, invite any role (including other owners), and manage custom roles |
| **Admin** | Same operational access as owner, plus billing — but cannot delete the organization or invite/promote to owner |
| **Member** | Full operational access: create and manage servers, deployments, environment variables, agents, API keys, domains, GitHub integrations, and team peers at the member level — but **cannot** change billing or invite/promote anyone above member |### What “operational access” includes [#what-operational-access-includes]Members, admins, and owners can all:- Create, update, and delete servers and deployments
- Edit environment variables and redeploy
- Manage API keys and custom domains
- Connect and manage GitHub installations
- Invite and manage other **members** (not admins or owners)
- Update organization settings (name, slug)### Billing [#billing]Only **owners** and **admins** can open the billing page, upgrade plans, or manage the Stripe subscription. Members still benefit from the org’s plan limits (projects, seats, analytics retention, etc.) but must ask an admin to change billing.### Custom roles [#custom-roles]
Custom roles are available on the **Enterprise** plan. The built-in Owner,
Admin, and Member roles work on every plan. [Contact
us](https://manufact.com/book-call) to enable RBAC for your organization.
On Enterprise, owners and admins can define **custom roles** from the **Roles & permissions** panel, with a fine-grained permission matrix — for example, a role that can deploy but cannot manage billing or delete servers. The panel is shown to members who can manage roles (owners and admins); it is hidden for roles without that permission.If an organization moves off Enterprise, members already assigned to a custom role keep their current access, but no new custom roles can be created and existing members cannot be reassigned to a custom role until Enterprise is active again. Reassign those members to a built-in role to fully remove custom-role access.See [Roles & permissions](/dashboard/permissions) for the full permission matrix and how enforcement works.## Multiple organizations [#multiple-organizations]You can belong to any number of organizations and switch between them with the organization switcher in the header. Each organization has its own servers, plan, and team, useful for separating clients, products, or staging/production ownership.## Organization settings [#organization-settings]From **Org settings** you can rename the organization, change its slug, and (owners only) delete it. Deleting an organization removes all its servers and data permanently.You cannot delete an organization while it has an active paid subscription. Cancel or downgrade to **Free** first (via **Billing → Manage subscription**), then delete from Org settings.
# Testing (/dashboard/testing)
The **Testing** tab runs automated test suites against your server. A suite describes scenarios, prompts and expected behavior, and Manufact executes them across different MCP clients and LLM models, because a server that works in one client can still fail in another.Test suites require the [Hobby plan or higher](/dashboard/billing). Eval runs are billed at [$1 per run](/dashboard/billing).## Creating a suite [#creating-a-suite]1) Go to **Testing** and click **Add test suite**.
2) Define the scenarios to test: what to ask, and what a correct response looks like.
3) Pick the clients and models to run against, **Inspector** and **ChatGPT** are available today, with Claude and Cursor coming soon.## Running and reading results [#running-and-reading-results]Run a suite on demand from the list. Open a suite to see run history with pass/fail per client and model, regressions that only affect a specific client or model stand out immediately.## When to run tests [#when-to-run-tests]- **Before publishing**: alongside the [Checklist](/dashboard/publish-checks), to make sure behavior matches your tool descriptions.
- **After changing tool schemas**: renamed tools and changed parameters are the most common source of silent client breakage.
- **When upgrading frameworks**: verify your MCP framework upgrade didn't change wire behavior.Testing works for both Manufact-hosted and external servers.
# build (/cli/build)
```bash
mcp-use build [--with-inspector] [--no-typecheck]
```
Production build: bundles your server, compiles React widgets from `resources/`, type-checks, and writes a `dist/` folder with a `mcp-use.json` manifest.
| Flag | Description |
| ------------------ | ---------------------------------------------- |
| `--with-inspector` | Include the inspector in the production build. |
| `--no-typecheck` | Skip TypeScript type checking. |
Run the result with [`start`](/cli/start).
# client auth (/cli/client-auth)
```bash
mcp-use client auth status
mcp-use client auth refresh
mcp-use client auth logout
```
Manage OAuth credentials for servers connected over HTTP with OAuth.
# client connect (/cli/client-connect)
```bash
# Remote server (runs the OAuth flow on 401)
mcp-use client connect myserver https://.run.mcp-use.com/mcp
# With a bearer token instead of OAuth
mcp-use client connect myserver https://example.com/mcp --auth
# Local stdio server
mcp-use client connect local "node dist/index.js" --stdio
```
Saved servers persist in `~/.mcp-use/cli-sessions.json`. See [`client list`](/cli/client-list) and [`client tools`](/cli/client-tools).
# client interactive (/cli/client-interactive)
```bash
mcp-use client interactive
```
Opens a REPL where you can list and call tools conversationally on a saved server.
# client list (/cli/client-list)
```bash
mcp-use client list
```
Lists servers saved with [`client connect`](/cli/client-connect).
# client prompts (/cli/client-prompts)
```bash
mcp-use client prompts list
mcp-use client prompts get [args...]
```
List and fetch prompts exposed by a saved server.
# client remove (/cli/client-remove)
```bash
mcp-use client remove
```
Removes a server from `~/.mcp-use/cli-sessions.json`.
# client resources (/cli/client-resources)
```bash
mcp-use client resources list
mcp-use client resources read
```
List and read resources exposed by a saved server.
# client screenshot (/cli/client-screenshot)
```bash
mcp-use client screenshot --mcp https://example.com/mcp --tool my_tool --output shot.png
mcp-use client screenshot --tool my_tool --output shot.png
```
Renders a tool's widget headlessly to a PNG. Useful for visual regression checks and documentation. The per-server form reuses the saved session's authentication from [`client connect`](/cli/client-connect).
# client tools (/cli/client-tools)
```bash
mcp-use client tools list
mcp-use client tools describe
mcp-use client tools call [key=value ...]
```
Explore and invoke tools on a saved server. Add `--json` for machine-readable output, handy in scripts and CI.
Connect a server first with [`client connect`](/cli/client-connect).
# deploy (/cli/deploy)
```bash
mcp-use deploy
```
Deploys the current project to Manufact Cloud. By default the CLI deploys **from GitHub**: it can guide you through connecting the GitHub App and creating a repository if needed, then streams the build logs live. The project is linked to its cloud server through `.mcp-use/project.json`, so subsequent `mcp-use deploy` runs redeploy the same server.
## Flags [#flags]
| Flag | Description |
| ------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `--name ` | Name for the server. |
| `--org ` | Target organization. |
| `--branch ` | Branch to deploy (non-production branches create [preview environments](/dashboard/deployments)). |
| `--root-dir ` | Subdirectory containing the server, for monorepos. |
| `--port ` | Port your server listens on (default `3000`). |
| `--runtime ` | `node` or `python`, auto-detected by default. |
| `--region ` | `US`, `EU`, or `APAC`. |
| `--env KEY=VALUE` | Set environment variable values (repeatable). |
| `--env-file ` | Load environment variables from a file. |
| `--build-command ` | Override the build command. |
| `--start-command ` | Override the start command. |
| `--dockerfile ` | Path to a non-default Dockerfile (relative to `--root-dir` / repo root). |
| `--watch-paths ` | Only auto-deploy when matching files change ([monorepos](/dashboard/deployments)). Set on new-server creation. |
| `--wait-for-ci` | Hold GitHub auto-deploys until other check runs pass. Set on new-server creation. |
| `--new` | Force creating a new server instead of redeploying the linked one. |
| `--no-github` | Upload local source as a tarball instead of deploying from GitHub. |
| `--open` | Open the deployment in the browser when it succeeds. |
| `-y, --yes` | Skip confirmation prompts. |
## Examples [#examples]
Deploy the current repository, setting a couple of secrets:
```bash
mcp-use deploy --env OPENAI_API_KEY=sk-... --env DB_URL=postgres://...
```
Deploy a monorepo package to the EU region:
```bash
mcp-use deploy --root-dir packages/my-server --region EU
```
Deploy a monorepo package that only redeploys when its own files or shared code change:
```bash
mcp-use deploy --root-dir packages/my-server \
--watch-paths "packages/my-server/**" "packages/shared/**"
```
Deploy without GitHub (local source upload):
```bash
mcp-use deploy --no-github --name my-server
```
Deploy a feature branch as a preview:
```bash
mcp-use deploy --branch feat/new-tools
```
After a successful deploy the CLI prints your server's MCP URL, see [Connecting clients](/dashboard/connect-clients) for what to do with it.
# deployments delete (/cli/deployments-delete)
```bash
mcp-use deployments delete [-y]
```
Deletes a deployment. `-y` skips the confirmation prompt.
# deployments get (/cli/deployments-get)
```bash
mcp-use deployments get
```
Shows full deployment details, including the source commit and the deployment's MCP URL.
See also [`deployments logs`](/cli/deployments-logs) and [`deployments restart`](/cli/deployments-restart).
# deployments list (/cli/deployments-list)
```bash
mcp-use deployments list [--limit ] [--skip ] [--sort ]
```
Lists deployments in your active organization. `ls` is an alias.
See [`deployments get`](/cli/deployments-get) for full details on one deployment.
# deployments logs (/cli/deployments-logs)
```bash
mcp-use deployments logs
mcp-use deployments logs --build
mcp-use deployments logs --follow
```
| Flag | Description |
| ---------------- | ---------------------------------------- |
| `--build` | Show build logs instead of runtime logs. |
| `--follow`, `-f` | Stream logs live. |
# deployments restart (/cli/deployments-restart)
```bash
mcp-use deployments restart [--follow] [--branch ]
```
Triggers a new deployment on the same server, the CLI equivalent of **Redeploy** in the dashboard. `--follow` (`-f`) streams the build logs as it runs.
# deployments start (/cli/deployments-start)
```bash
mcp-use deployments start
```
Starts a previously stopped deployment.
# deployments stop (/cli/deployments-stop)
```bash
mcp-use deployments stop
```
Stops a deployment. To bring it back; use [`deployments restart`](/cli/deployments-restart) or [`deployments start`](/cli/deployments-start).
# dev (/cli/dev)
```bash
mcp-use dev [--port ] [--no-open] [--no-hmr] [--tunnel]
```
Starts the dev server with hot module replacement and automatically opens the **MCP Inspector** at `http://localhost:/inspector`, where you can chat with your server and call its tools. No login required.
| Flag | Description |
| ------------------------------------ | -------------------------------------------------------------------- |
| `--port ` | Port to listen on (default `3000`). |
| `--entry ` / `--mcp-dir ` | Point at a custom server entry or an MCP folder inside a larger app. |
| `--no-open` | Don't auto-open the inspector. |
| `--no-hmr` | Restart the process on change instead of HMR. |
| `--tunnel` | Expose the dev server on a public URL so remote clients can connect. |
To scaffold a new project first, use `npx create-mcp-use-app my-app`. When ready to ship; use [`deploy`](/cli/deploy).
# generate-types (/cli/generate-types)
```bash
mcp-use generate-types
```
Generates `.mcp-use/tool-registry.d.ts` from your registered tools, giving you typed `useCallTool` calls in widgets. The dev server keeps this up to date automatically during [`dev`](/cli/dev).
# Manufact CLI (/cli)
We live and breathe MCP. Still, we'll admit it: sometimes you just want a terminal. The CLI is for local development, scripted deploys, and running agents on your machine before they graduate to MCP.
`@mcp-use/cli` is the command-line companion to Manufact Cloud and the [mcp-use](https://docs.mcp-use.com) framework: build and run MCP servers locally, deploy them to Manufact Cloud, and manage servers, deployments, and environment variables without leaving the terminal.
## Installation [#installation]
No install needed, the [mcp-use](https://docs.mcp-use.com) package forwards to the CLI, so you can run commands directly:
```bash
npx mcp-use
```
For frequent use, install the CLI globally:
```bash
npm install -g @mcp-use/cli
```
Both expose the same `mcp-use` binary; if your project already depends on `mcp-use`, the command is available in your scripts as-is. Requires Node.js `^20.19.0` or `>=22.12.0`.
## Quick tour [#quick-tour]
```bash
# Authenticate with Manufact Cloud
mcp-use login
# Run your MCP server locally with hot reload + inspector
mcp-use dev
# Deploy it to Manufact Cloud
mcp-use deploy
# Watch it run
mcp-use deployments logs --follow
```
## Command reference [#command-reference]
Each command has its own page in the sidebar, grouped by area. Start with [`login`](/cli/login) for cloud commands, or [`dev`](/cli/dev) for local development.
| Area | Commands |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Authentication** | [`login`](/cli/login), [`logout`](/cli/logout), [`whoami`](/cli/whoami) |
| **Organization** | [`org list`](/cli/org-list), [`org switch`](/cli/org-switch), [`org current`](/cli/org-current) |
| **Deploy** | [`deploy`](/cli/deploy) |
| **Servers** | [`servers list`](/cli/servers-list), [`servers get`](/cli/servers-get), [`servers update`](/cli/servers-update), [`servers delete`](/cli/servers-delete) |
| **Environment variables** | [`servers env list`](/cli/servers-env-list), [`add`](/cli/servers-env-add), [`update`](/cli/servers-env-update), [`remove`](/cli/servers-env-remove) |
| **Deployments** | [`deployments list`](/cli/deployments-list), [`get`](/cli/deployments-get), [`restart`](/cli/deployments-restart), [`logs`](/cli/deployments-logs), [`stop`](/cli/deployments-stop), [`start`](/cli/deployments-start), [`delete`](/cli/deployments-delete) |
| **Local development** | [`dev`](/cli/dev), [`build`](/cli/build), [`start`](/cli/start), [`generate-types`](/cli/generate-types), [`skills add`](/cli/skills-add) |
| **Terminal client** | [`client connect`](/cli/client-connect), [`list`](/cli/client-list), [`tools`](/cli/client-tools), [`interactive`](/cli/client-interactive), [`screenshot`](/cli/client-screenshot) |
## Configuration [#configuration]
The CLI stores its state under `~/.mcp-use/`:
| File | Purpose |
| ------------------------------ | ------------------------------------------------------------------------- |
| `~/.mcp-use/config.json` | API key and active organization (written by `login` and `org switch`) |
| `~/.mcp-use/cli-sessions.json` | Servers saved with `client connect` |
| `.mcp-use/project.json` | Per-project link to its cloud server and deployment (written by `deploy`) |
A `.env` file in the current directory is loaded automatically on every command.
## Environment variables [#environment-variables]
| Variable | Purpose | Default |
| ----------------- | --------------------------------------------------- | ----------------------------------- |
| `MCP_USE_API_KEY` | API key for non-interactive login (CI) | - |
| `MCP_API_URL` | Manufact Cloud API base | `https://cloud.manufact.com/api/v1` |
| `MCP_WEB_URL` | Web app used for the device login flow | `https://manufact.com` |
| `PORT` | Port for `mcp-use start` when `--port` isn't passed | `3000` |
# login (/cli/login)
```bash
mcp-use login
```
Runs the OAuth device flow: the CLI prints a verification URL and code, opens your browser, and waits for approval. After login it creates a persistent API key and, if you belong to multiple organizations, prompts you to pick the active one.
Credentials are stored in `~/.mcp-use/config.json`. Cloud commands (`deploy`, `servers`, `deployments`, `org`) require authentication.
## Flags [#flags]
| Flag | Description |
| ------------------------ | ----------------------------------------------------------------------------------------- |
| `--api-key ` | Skip the browser flow and save an API key directly, for CI. Also reads `MCP_USE_API_KEY`. |
| `--org ` | Select the active organization non-interactively. |
| `--device-code ` | Use a pre-approved device code (used by web onboarding). |
## Example (CI) [#example-ci]
Create a key on the [API Keys page](/dashboard/api-keys), then:
```bash
mcp-use login --api-key mcp_... --org my-org
```
# logout (/cli/logout)
```bash
mcp-use logout
```
Deletes the local credentials file (`~/.mcp-use/config.json`). The API key itself is not revoked, manage keys on the [API Keys page](/dashboard/api-keys).
# org current (/cli/org-current)
```bash
mcp-use org current
```
Prints the slug and name of the organization cloud commands will target by default.
See also [`org list`](/cli/org-list) and [`org switch`](/cli/org-switch).
# org list (/cli/org-list)
```bash
mcp-use org list
```
Lists organizations you belong to, marking the active one. Cloud commands operate in the context of this organization unless you pass `--org ` for a single invocation.
See also [`org switch`](/cli/org-switch) and [`org current`](/cli/org-current).
# org switch (/cli/org-switch)
```bash
mcp-use org switch
```
Prompts you to pick a new active organization. The selection is saved to `~/.mcp-use/config.json` and used by subsequent cloud commands.
See also [`org list`](/cli/org-list) and [`org current`](/cli/org-current).
# servers delete (/cli/servers-delete)
```bash
mcp-use servers delete [-y]
```
Deletes the server **and all its deployments**. `rm` is an alias; `-y` skips the confirmation prompt.
# servers env add (/cli/servers-env-add)
```bash
mcp-use servers env add KEY=VALUE --server [--env production,preview] [--sensitive]
```
Adds an environment variable. The `--env` flag selects which environments it applies to (`production`, `preview`, `development`); `--branch` scopes it to one preview branch.
Changes take effect on the next deployment, trigger one with [`deployments restart`](/cli/deployments-restart) or [`deploy`](/cli/deploy).
# servers env list (/cli/servers-env-list)
```bash
mcp-use servers env list --server [--branch ] [--show-values]
```
Lists environment variables for a server. Values are masked unless `--show-values` is passed.
The `--branch` flag scopes the list to one preview branch. See [`servers env add`](/cli/servers-env-add) to create variables.
# servers env remove (/cli/servers-env-remove)
```bash
mcp-use servers env remove KEY --server [--branch ]
```
Removes an environment variable. Changes take effect on the next deployment.
# servers env update (/cli/servers-env-update)
```bash
mcp-use servers env update KEY --server --value [--sensitive|--no-sensitive]
```
Updates an existing variable's value. Changes take effect on the next deployment.
# servers get (/cli/servers-get)
```bash
mcp-use servers get
```
Shows the server's details and its recent deployments.
See also [`servers list`](/cli/servers-list) and [`deployments list`](/cli/deployments-list).
# servers list (/cli/servers-list)
```bash
mcp-use servers list [--limit ] [--skip ] [--sort ]
```
Lists servers in your active organization. `ls` is an alias. Sortable fields: `createdAt`, `updatedAt`, `name`.
Pass `--org ` to target a different organization without switching. See [`servers get`](/cli/servers-get) for full details on one server.
# servers update (/cli/servers-update)
```bash
mcp-use servers update [flags]
```
At least one flag is required:
| Flag | Description |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| `--name ` | Rename the server. |
| `--description ` | Update the description. |
| `--branch ` | Change the production branch. |
| `--build-command ` | Override the build command (pass `""` to clear). |
| `--start-command ` | Override the start command (pass `""` to clear). |
| `--root-dir ` | Repo subdirectory to build from (pass `""` to reset to the repo root). |
| `--watch-paths ` | Only auto-deploy when matching files change ([monorepos](/dashboard/deployments); pass `""` to clear the filter). |
| `--deploy-branches ` | Branch globs (besides the production branch) allowed to auto-deploy (pass `""` to allow all). |
| `--wait-for-ci` / `--no-wait-for-ci` | Hold auto-deploys until other GitHub check runs pass. |
Changes that affect the running deployment take effect on the next deploy; use [`deploy`](/cli/deploy) or [`deployments restart`](/cli/deployments-restart).
## Monorepo example [#monorepo-example]
Scope an existing server so only its own subtree and shared code trigger auto-deploys:
```bash
mcp-use servers update my-app \
--watch-paths "apps/my-app/**" "packages/shared/**" \
--deploy-branches "release/*"
```
# skills add (/cli/skills-add)
```bash
mcp-use skills add
```
Downloads the mcp-use agent skills into your project (`.cursor/skills`, `.claude/skills`, `.agent/skills`) so coding agents like Cursor and Claude Code get framework-specific guidance.
`skills install` is an alias for the same command.
# start (/cli/start)
```bash
mcp-use start [--port ] [--tunnel]
```
Runs the production build from `dist/`. Respects the `PORT` environment variable when `--port` isn't passed.
Build first with [`build`](/cli/build).
# whoami (/cli/whoami)
```bash
mcp-use whoami
```
Shows your email, user ID, a masked API key, and the active organization.
# cancel_org_invitation (/mcp/cancel-org-invitation)
Cancels a pending invitation. Marked **destructive**: clients may ask for confirmation before running it.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ------------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | The organization the invitation belongs to. From [`list_organizations`](/mcp/list-organizations). |
| `invitationId` | string | Yes | The invitation to cancel. From [`list_org_invitations`](/mcp/list-org-invitations). |
## Returns [#returns]
A confirmation message: `Invitation cancelled.`
# deploy (/mcp/deploy)
Deploys a GitHub repository to Manufact Cloud. This is the tool to use when a user says "deploy this repo" or "deploy the current project"; the agent should infer `repoFullName` from the local git remote when possible.
The tool checks whether the repository is already connected to a server in the organization:
* **Already connected** → it redeploys that server.
* **Not connected** → it creates a new GitHub-backed server and starts the initial deployment.
It does not accept a `serverId`; use [`redeploy`](/mcp/redeploy) when the user identified a specific existing server.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ------------------------------- | -------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | Organization to deploy into. From [`list_organizations`](/mcp/list-organizations). |
| `repoFullName` | string | Yes | GitHub repository in `owner/repo` format. |
| `branch` | string | No | Branch to deploy. Defaults to the server's production branch for existing servers, `main` for new ones. |
| `installationId` | string | No | GitHub installation to use. Only needed when the repo is accessible from multiple installations (the tool resolves it automatically otherwise). |
| `name` | string | No | Display name for a new server (defaults to the repo name). |
| `description` | string | No | Description for a new server. |
| `rootDir` | string | No | Repository subdirectory to build from. |
| `port` | number | No | Application port (1–65535). |
| `buildCommand` / `startCommand` | string | No | Command overrides for a new server. |
| `dockerfilePath` | string | No | Non-default Dockerfile path. |
| `env` | record | No | Environment variables for a new server. |
| `buildSecrets` | string\[] | No | Keys from `env` to treat as build-only secrets. |
| `region` | `AUTO` \| `US` \| `EU` \| `APAC` | No | Compute region for a new server. |
| `watchPaths` | string\[] | No | Glob patterns limiting which repo changes trigger auto-deploy. |
| `waitForCi` | boolean | No | Whether auto-deploys wait for GitHub check runs. |
## Returns [#returns]
Either `action: "redeployed_existing_server"` with the matched server and new deployment, or `action: "created_server_and_deployed"` with the created server and its initial deployment.
If multiple servers are connected to the same repository, the tool returns an error listing the matches; use [`redeploy`](/mcp/redeploy) with the right `serverId` instead.
# get_deployment_build_logs (/mcp/get-deployment-build-logs)
Returns build logs for a deployment, the output of the build pipeline. Defaults to the last 100 lines. Read-only.
There are two modes:
* **Tail** (default, or with `lines`), return the last N lines.
* **Offset streaming** (with `offset`, no `lines`), stream forward from a character offset. Use a previous response's `nextOffset` to resume following an in-flight build.
`lines` takes precedence if both are set.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | -------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | Organization that owns the deployment. From [`list_organizations`](/mcp/list-organizations). |
| `deploymentId` | string | Yes | The deployment whose build logs you want. From [`list_deployments`](/mcp/list-deployments). |
| `lines` | number | No | Return only the last N lines (1–5000, default 100). |
| `offset` | number | No | Character offset to stream forward from. Ignored if `lines` is set. |
## Returns [#returns]
The log text plus the build `status` when available. Tail mode includes `returnedLines` and `totalLength`; offset mode includes pagination info with `nextOffset`.
## Typical use [#typical-use]
Debugging a failed deployment: find it with [`list_deployments`](/mcp/list-deployments) (`status: "failed"`), then read its build logs here.
# get_deployment_runtime_logs (/mcp/get-deployment-runtime-logs)
Returns runtime logs for a deployment, what the server writes to stdout/stderr while serving traffic. Defaults to the most recent 100 lines. Read-only.
Pass `query` to filter the fetched tail to lines containing a substring (case-insensitive), useful for finding specific errors without pulling huge tails.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ----------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | Organization that owns the deployment. From [`list_organizations`](/mcp/list-organizations). |
| `deploymentId` | string | Yes | The deployment whose logs you want. From [`list_deployments`](/mcp/list-deployments). |
| `lines` | number | No | How many tail lines to fetch (1–5000, default 100). |
| `query` | string | No | Case-insensitive substring filter, applied to the fetched tail, matches are bounded by `lines`. |
## Returns [#returns]
The log text (ANSI codes stripped) plus `lines`; with `query`, also `matchedLines` and `scannedLines`.
## Related [#related]
* [`get_deployment_build_logs`](/mcp/get-deployment-build-logs): for build-time output
# get_deployment (/mcp/get-deployment)
Returns full details for one deployment: core fields (`id`, `status`, `serverId`, `domain`, `port`, timestamps, `error`, `mcpUrl`), git commit info, and source configuration (repo, branch, `rootDir`, runtime, `buildCommand`, `startCommand`). Read-only.
For log streams use [`get_deployment_build_logs`](/mcp/get-deployment-build-logs) and [`get_deployment_runtime_logs`](/mcp/get-deployment-runtime-logs).
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | --------------------------------------------------------------------------------------------- |
| `deploymentId` | string | Yes | The deployment to retrieve. From [`list_deployments`](/mcp/list-deployments). |
| `organizationId` | string | Yes | Organization the deployment belongs to. From [`list_organizations`](/mcp/list-organizations). |
## Typical use [#typical-use]
Check why a deployment failed (`status` + `error`), or grab a deployment's `mcpUrl` to connect a client to it.
# get_observability_overview (/mcp/get-observability-overview)
Returns an observability overview for one server: `totalEvents`, `successEvents`, `errorEvents`, `avgDuration` (ms), `avgRequestSize`, and `avgResponseSize`, aggregated over a time window. Read-only.
In MCP Apps-capable clients this renders the **gateway-metrics widget**: a live metrics card instead of raw JSON.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | --------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | The organization the server belongs to. From [`list_organizations`](/mcp/list-organizations). |
| `serverId` | string | Yes | The server to query. From [`list_servers`](/mcp/list-servers). |
| `startTime` | string | No | ISO 8601 lower bound (inclusive). Defaults to the last 24 hours. |
## Related [#related]
* [`list_server_events`](/mcp/list-server-events): the underlying request stream
* [`get_server_tool_breakdown`](/mcp/get-server-tool-breakdown) / [`get_server_client_breakdown`](/mcp/get-server-client-breakdown): per-tool and per-client splits
# get_organization_stats (/mcp/get-organization-stats)
Returns summary counts for an organization: server count, deployment count, gateway tool-call count, and distinct MCP session count. Read-only.
It does not return the server roster; use [`list_servers`](/mcp/list-servers) for that.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ------------------------------------------------------------------------------------ |
| `organizationId` | string | Yes | The organization to summarize. From [`list_organizations`](/mcp/list-organizations). |
## Returns [#returns]
```json
{
"organizationId": "...",
"serverCount": 4,
"deploymentCount": 23,
"gateway": { "toolCallCount": 1582, "distinctMcpSessionCount": 214 }
}
```
Gateway counts fall back to zeros if observability data is unavailable.
# get_server_client_breakdown (/mcp/get-server-client-breakdown)
Returns a breakdown of which MCP clients connect to a server, `clientName`, `clientVersion`, `protocol`, `sessionCount`, `requestCount`, plus a timeline of request counts per client per time bucket. Results are capped to the top 10 clients by request count. Read-only.
In MCP Apps-capable clients this renders the **client-breakdown widget**: a chart of clients over time.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ---------------------------------------------------------- | -------- | --------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | The organization the server belongs to. From [`list_organizations`](/mcp/list-organizations). |
| `serverId` | string | Yes | The server to query. From [`list_servers`](/mcp/list-servers). |
| `timeRange` | `"24h"` \| `"7d"` \| `"30d"` \| `"90d"` | No | Window to aggregate (default `24h`). |
| `granularity` | `"minute"` \| `"hour"` \| `"day"` \| `"week"` \| `"month"` | No | Timeline bucket size (default `hour` for 24h, `day` otherwise). |
## Related [#related]
* [`get_server_tool_breakdown`](/mcp/get-server-tool-breakdown): what those clients are calling
# get_server_domain (/mcp/get-server-domain)
Returns a server's main custom domain with its verification state: `domain`, `verified`, `status`, `sslStatus`, `cnameTarget`, and `verificationErrors`. Read-only.
The main domain lives on the server; preview domains live on individual deployments.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | --------------------------------------------------------------------------------------------- |
| `serverId` | string | Yes | The server whose domain to retrieve. From [`list_servers`](/mcp/list-servers). |
| `organizationId` | string | Yes | The organization the server belongs to. From [`list_organizations`](/mcp/list-organizations). |
## Typical use [#typical-use]
Troubleshooting a custom domain: check `verificationErrors` and `cnameTarget` against your DNS setup. See [Domains](/dashboard/domains) for the full setup flow.
# get_server_tool_breakdown (/mcp/get-server-tool-breakdown)
Returns a breakdown of tool, resource, and prompt calls on a server over the last 24 hours, bucketed hourly. Methods are aggregated with per-bucket counts, sorted by total calls. Read-only.
In MCP Apps-capable clients this renders the **tool-breakdown widget**: a chart of calls per method.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | --------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | The organization the server belongs to. From [`list_organizations`](/mcp/list-organizations). |
| `serverId` | string | Yes | The server to query. From [`list_servers`](/mcp/list-servers). |
The window is fixed at 24 hours with hourly buckets.
## Related [#related]
* [`get_server_client_breakdown`](/mcp/get-server-client-breakdown): who is calling
* [`list_server_events`](/mcp/list-server-events): the raw call stream
# get_server (/mcp/get-server)
Returns core details for one server: `id`, `slug`, `name`, `description`, `tags`, `status`, `latestDeploymentStatus`, `activeDeploymentId`, `repoFullName`, `productionBranch`, and `deploymentCount`. Read-only.
It does not include the full deployment history, domains, or internal provider config; use [`list_deployments`](/mcp/list-deployments) and [`get_server_domain`](/mcp/get-server-domain) for those.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | --------------------------------------------------------------------------------------------- |
| `serverId` | string | Yes | The server to retrieve. From [`list_servers`](/mcp/list-servers). |
| `organizationId` | string | Yes | The organization the server belongs to. From [`list_organizations`](/mcp/list-organizations). |
## Related [#related]
* [`update_server`](/mcp/update-server): change deploy config or metadata
* [`redeploy`](/mcp/redeploy): trigger a new deployment
# Manufact MCP server (/mcp)
Manufact Cloud is itself controllable over MCP. The official **Manufact Cloud MCP server** exposes the platform, organizations, servers, deployments, logs, and observability, as MCP tools, so you can manage everything from Cursor, Claude, or any other MCP client.
```text
https://mcp.manufact.com/mcp
```
## Connecting [#connecting]
Add the server to your client with the standard remote MCP configuration:
```json
{
"mcpServers": {
"manufact-cloud": {
"url": "https://mcp.manufact.com/mcp"
}
}
}
```
The transport is Streamable HTTP. Authentication uses **OAuth**: on first connection your client runs the standard MCP OAuth flow and you log in with your Manufact Cloud account. Tools then act with your own permissions, the same role-based access you have in the dashboard.
Access tokens last **7 days** and refresh tokens last **90 days** (each refresh extends the window). Manufact automatically grants the `offline_access` scope so clients receive a refresh token even when they omit it from the authorization request.
## What you can do [#what-you-can-do]
| | Example prompts |
| ------------- | ------------------------------------------------------------------------------------------- |
| **Deploy** | "Deploy this repo to Manufact Cloud", "Redeploy my-server from the main branch" |
| **Debug** | "Why did the latest deployment of my-server fail?", "Show runtime logs filtered for errors" |
| **Monitor** | "How much traffic did my-server get this week?", "Which clients call it most?" |
| **Configure** | "Change the start command and redeploy", "Is my custom domain verified?" |
| **Team** | "Invite [jane@example.com](mailto:jane@example.com) to my org as admin" |
Each of the 20 tools has its own reference page in the sidebar, grouped by area. Start with [`list_organizations`](/mcp/list-organizations), the entry point for every session.
## Design [#design]
The server follows a **composable, minimal-tool** design: each tool returns a narrow, allowlisted projection, and IDs chain across tools.
```text
list_organizations → organizationId
→ list_servers → serverId
→ list_deployments → deploymentId
→ get_deployment_runtime_logs
```
Agents are expected to chain these small calls rather than receive one giant response. A `manufact://info` resource describes the catalog and this flow, so agents can orient themselves.
## Widgets [#widgets]
The four analytics tools render **interactive widgets** (charts and tables) in clients that support MCP Apps, gateway metrics, event streams, client breakdowns, and tool breakdowns appear as live UI instead of raw JSON.
## Built with mcp-use [#built-with-mcp-use]
The server is built with the [mcp-use framework](https://docs.mcp-use.com) and hosted on Manufact Cloud itself, the same workflow described in the [Dashboard docs](/dashboard) and deployable with the [CLI](/cli).
# invite_org_member (/mcp/invite-org-member)
Sends an email invitation to join an organization with the given role.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------------------------------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | The organization to invite the member to. From [`list_organizations`](/mcp/list-organizations). |
| `email` | string | Yes | Email address to invite. |
| `role` | `"owner"` \| `"admin"` \| `"member"` | Yes | Role for the invited member. You can only invite at or below your own role (members → member only; admins → admin or member; owners → any). |
## Returns [#returns]
The created invitation: `id`, `email`, `role`, `status`, `organizationId`, and `expiresAt`.
## Related [#related]
* [`list_org_invitations`](/mcp/list-org-invitations): see pending invitations
* [`cancel_org_invitation`](/mcp/cancel-org-invitation): revoke one
# list_deployments (/mcp/list-deployments)
Lists deployments as compact rows: `id`, `name`, `status`, `serverId`, `gitBranch`, `createdAt`. Paginated server-side. Read-only.
This is the source of truth for `deploymentId`. Pass `serverId` to scope to one server, and filter by `status` (for example `failed`) when the user describes a deployment rather than naming it.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ---------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | Organization to scope the request. From [`list_organizations`](/mcp/list-organizations). |
| `serverId` | string | No | Filter to one server's deployments. From [`list_servers`](/mcp/list-servers). |
| `status` | string | No | Filter by deployment status (e.g. `running`, `failed`). |
| `limit` | number | No | Max deployments to return (1–200, default 25). |
| `offset` | number | No | Number of deployments to skip (default 0). |
## Returns [#returns]
A `deployments` array plus a `pagination` object with the effective limit, offset, total matches, and returned count.
## Related [#related]
* [`get_deployment`](/mcp/get-deployment): full details for one deployment
* [`get_deployment_build_logs`](/mcp/get-deployment-build-logs) / [`get_deployment_runtime_logs`](/mcp/get-deployment-runtime-logs): logs
# list_org_invitations (/mcp/list-org-invitations)
Lists pending invitations for an organization. Read-only.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ----------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | The organization to list invitations for. From [`list_organizations`](/mcp/list-organizations). |
## Returns [#returns]
```json
{
"invitations": [
{
"id": "...",
"email": "jane@example.com",
"role": "admin",
"status": "pending",
"expiresAt": "..."
}
]
}
```
## Related [#related]
* [`invite_org_member`](/mcp/invite-org-member): send a new invitation
* [`cancel_org_invitation`](/mcp/cancel-org-invitation): cancel a pending one
# list_organizations (/mcp/list-organizations)
Lists organizations you can access, as minimal rows: `id`, `name`, `slug`, and your `role`. Read-only.
This is the source of truth for `organizationId`, which every other tool in this server requires; call it first in any session.
## Parameters [#parameters]
None.
## Returns [#returns]
```json
{
"organizations": [
{ "id": "...", "name": "Acme", "slug": "acme", "role": "owner" }
]
}
```
## Related [#related]
* [`get_organization_stats`](/mcp/get-organization-stats): counts for one organization
* [`list_servers`](/mcp/list-servers): the servers inside an organization
# list_server_events (/mcp/list-server-events)
Returns the gateway request log for a server, newest first. Each row includes method, path, status code, duration, client name/version, country, and error details when present. Read-only.
Pagination is **cursor-based**, not offset: call again with `cursorTime` set to the previous response's `nextCursor` to page back further in time.
In MCP Apps-capable clients this renders the **gateway-events widget**: an interactive event table.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ---------------------------------------------- | -------- | --------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | The organization the server belongs to. From [`list_organizations`](/mcp/list-organizations). |
| `serverId` | string | Yes | The server to query. From [`list_servers`](/mcp/list-servers). |
| `startTime` | string | No | ISO 8601 lower bound (inclusive). Defaults to the last 24 hours. |
| `limit` | number | No | Max events to return (1–100, default 25). |
| `cursorTime` | string | No | ISO 8601 exclusive upper bound, pass the previous response's `nextCursor`. |
| `status` | `"success"` \| `"error"` \| `"4xx"` \| `"5xx"` | No | Filter by outcome. |
| `mcpOnly` | boolean | No | Only return MCP protocol events (default false). |
## Typical use [#typical-use]
Drill into errors: filter with `status: "error"`, inspect the failing requests, then match timestamps against [`get_deployment_runtime_logs`](/mcp/get-deployment-runtime-logs).
# list_servers (/mcp/list-servers)
Lists the MCP servers in an organization as compact rows: `id`, `slug`, `name`, `status`, `tags`. Offset-paginated. Read-only.
This is the source of truth for `serverId`. For full details use [`get_server`](/mcp/get-server); for deployment history use [`list_deployments`](/mcp/list-deployments) with `serverId`.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | --------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | The organization whose servers to list. From [`list_organizations`](/mcp/list-organizations). |
| `limit` | number | No | Max servers to return (1–100, upstream default 50). |
| `skip` | number | No | Number of servers to skip (default 0). |
| `sort` | enum | No | `createdAt:asc/desc`, `updatedAt:asc/desc`, or `name:asc/desc`. |
## Returns [#returns]
```json
{
"items": [{ "id": "...", "slug": "my-server", "name": "My Server", "status": "..." }],
"total": 12,
"limit": 50,
"skip": 0,
"hasMore": false
}
```
When `hasMore` is true, the response includes `nextSkip` for the next page.
# redeploy (/mcp/redeploy)
Triggers a new deployment of an existing server by `serverId`, the MCP equivalent of the dashboard's **Redeploy** button.
Use this when the user identified a specific existing server. For deploying a GitHub repository or the current project; use [`deploy`](/mcp/deploy) instead.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ---------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | Organization that owns the server. From [`list_organizations`](/mcp/list-organizations). |
| `serverId` | string | Yes | The server to deploy. From [`list_servers`](/mcp/list-servers). |
| `branch` | string | No | Branch to deploy. Defaults to the server's production branch. |
## Returns [#returns]
The created deployment with `action: "redeployed_existing_server"`. Follow its progress with [`get_deployment`](/mcp/get-deployment) and [`get_deployment_build_logs`](/mcp/get-deployment-build-logs).
# stop_deployment (/mcp/stop-deployment)
Stops a running deployment, taking it offline. Marked **destructive**: clients may ask for confirmation before running it.
To bring the server back up afterwards, call [`redeploy`](/mcp/redeploy) to trigger a new deployment.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | -------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | Organization that owns the deployment. From [`list_organizations`](/mcp/list-organizations). |
| `deploymentId` | string | Yes | The deployment to stop. From [`list_deployments`](/mcp/list-deployments). |
## Returns [#returns]
The deployment's updated state.
# update_server (/mcp/update-server)
Updates a server's deploy configuration (start command, build command, port, Dockerfile path, root dir) and/or metadata (name, description, tags, production branch).
Deploy-config fields are **merged** into the existing configuration, only the fields you pass change, the rest are preserved. Config changes don't take effect until the next deployment, so pass `redeploy: true` to trigger one immediately.
A common use: fix a broken start command (for example, set `startCommand` to a `uvicorn` command for a Python MCP server) and redeploy in one call.
## Parameters [#parameters]
| Parameter | Type | Required | Description |
| ------------------ | --------- | -------- | -------------------------------------------------------------------------------------------- |
| `organizationId` | string | Yes | The organization that owns the server. From [`list_organizations`](/mcp/list-organizations). |
| `serverId` | string | Yes | The server to update. From [`list_servers`](/mcp/list-servers). |
| `startCommand` | string | No | Process start command for the deploy pipeline. |
| `buildCommand` | string | No | Build command. Pass an empty string to clear it. |
| `port` | number | No | Application port the server listens on (1–65535). |
| `dockerfilePath` | string | No | Path to a non-default Dockerfile, relative to the root dir. |
| `rootDir` | string | No | Repository subdirectory to build from. |
| `name` | string | No | Server display name. |
| `description` | string | No | Server description. |
| `tags` | string\[] | No | Replacement set of server tags. |
| `productionBranch` | string | No | Git branch deployed for the production environment. |
| `redeploy` | boolean | No | When true, trigger a new deployment after saving (default false). |
## Returns [#returns]
The updated server, plus the new deployment when `redeploy` is true.