Server factory

The server factory is the pipeline that turns an API definition into a deployed MCP server. It runs in three stages — import → generate → deploy — and you can drive it from the dashboard or the CLI.

1. Import a spec

MCPCloud parses your API definition and extracts each operation as a candidate tool. Each import creates an apiSource, a draft server, and editable draft tools.

MCPCloud Import API source screen — The Import API source screen — bring in an OpenAPI document, introspect a GraphQL endpoint, or ingest a GitHub repo.

Supported sources:

OpenAPI / Swagger

Upload a JSON/YAML file or point at a remote spec URL. Each path + method becomes a typed tool.

GraphQL

Endpoint introspection turns queries and mutations into tools.

GitHub repository

Synthesize a tool surface from source in a repo.

Remote URL

Remote imports preserve the source URL and can auto-recheck daily for spec changes.

Validation warnings are surfaced before generation — missing descriptions, ambiguous parameter types, unsupported auth schemes, and non-JSON request/response shapes.

After import you curate the surface — keep the operations worth exposing as tools and drop the rest (for example, 587 Stripe operations curated down to 34 useful tools).

2. Enrich and generate

For every selected operation, Claude rewrites the tool description for agent comprehension, and MCPCloud runs deterministic codegen to produce a typed TypeScript tool:

server.tool("confirm_payment_intent",
  { payment_intent_id: z.string() },
  async ({ payment_intent_id }) => {
    const res = await tally.post(
      `/payment-intents/${payment_intent_id}/confirm`,
    )
    return { content: [{ type: "text", text: JSON.stringify(res) }] }
  }
)

Tool descriptions stay editable, secrets never land in generated source, and the generated output remains portable. Enrichment is a per-tool operation — running it server-wide fans out across all unenriched tools.

Every build is scanned with ESLint security rules and Semgrep before it can deploy. No eval(), no dynamic imports.

3. Deploy to the edge

The generated bundle is uploaded to a global edge runtime (Cloudflare Workers) with sub-5ms cold starts. A typical build log:

✔ Worker bundle uploaded (84 kB)
✔ Runtime bindings configured
✔ Health check passed
✔ Promoted to production

The new build becomes live and the previous one is marked replaced. Each deployment is immutable and addressable by id.

Drive it from the CLI

# Create a project + server skeleton, then iterate locally and ship
mcp init
mcp dev <serverId> --spec ./openapi.yaml      # hot-reload on spec changes
mcp servers push-spec <serverId> --spec ./openapi.yaml --deploy --wait

Use mcp servers deploy <serverId> --wait to long-poll deployment events until the build reaches a terminal state — ideal for CI.

Upstream auth bindings

When your server proxies an authenticated upstream, bind credentials at deploy time so they are encrypted and injected at runtime:

mcp servers deploy <serverId> \
  --upstream-base-url https://api.example.com \
  --upstream-api-key "$UPSTREAM_KEY"

Continue to transports & auth for how clients reach the deployed server.

Start here

How it works

Support

Server Factory

Server factory

1. Import a spec

OpenAPI / Swagger

GraphQL

GitHub repository

Remote URL

2. Enrich and generate

3. Deploy to the edge

Drive it from the CLI

Upstream auth bindings

​Server factory

​1. Import a spec

OpenAPI / Swagger

GraphQL

GitHub repository

Remote URL

​2. Enrich and generate

​3. Deploy to the edge

​Drive it from the CLI

​Upstream auth bindings

Server factory

1. Import a spec

2. Enrich and generate

3. Deploy to the edge

Drive it from the CLI

Upstream auth bindings