SvelteKit

For the complete documentation index, see llms.txt. Markdown variants of every page are available by appending .md to the URL.

The SvelteKit adapter lets your existing application serve MCP requests. It generates an ESM module with xmcpHandler(request, options?), returning a standard Response. Initial supported deployment targets are Node.js and Cloudflare Workers.

Automatic setup

Run this inside an existing TypeScript SvelteKit project:

npx init-xmcp@latest --yes

The initializer creates src/routes/mcp/+server.ts, which SvelteKit serves at /mcp. Use --route-path src/routes/api/mcp for /api/mcp. If you configured a custom routes root in SvelteKit, pass the matching directory and set http.endpoint to its public URL.

Initialization creates xmcp configuration and sample handlers, installs the packages, and prepends xmcp commands to your existing build and development scripts. Relative imports preserve your application's aliases and TypeScript configuration. Existing .ts and .js MCP route files cause a clear conflict error before configuration changes. Use --skip-route to keep your route and wire the handler yourself; --skip-tools, --skip-prompts, and --skip-resources omit those samples.

Workers mode is inferred when @sveltejs/adapter-cloudflare or @cloudflare/vite-plugin is installed. Use --cf to select it explicitly. The initializer preserves your host framework and deployment configuration. If multiple deployment adapters are installed, check the generated scripts and remove --cf for a Node deployment.

Manual setup

pnpm add xmcp zod
pnpm add -D @xmcp-dev/compiler

import type { XmcpConfig } from "xmcp";

const config: XmcpConfig = {
  http: { endpoint: "/mcp" },
  experimental: { adapter: "sveltekit" },
  paths: { tools: "./src/tools", prompts: false, resources: false },
  // The host build checks application types after the adapter exists.
  typescript: { skipTypeCheck: true },
};
export default config;

Set paths.prompts or paths.resources to directories to discover those handlers. Each uses the same exports as other xmcp transports. Create tools following the runnable SvelteKit example.

Run pnpm exec xmcp build before importing the generated adapter:

import type { RequestHandler } from "./$types";
import { xmcpHandler } from "../../../.xmcp/adapter/index.js";

export const GET: RequestHandler = ({ request }) => xmcpHandler(request);
export const POST: RequestHandler = ({ request }) => xmcpHandler(request);
export const DELETE: RequestHandler = ({ request }) => xmcpHandler(request);

Import the adapter only from server code. Do not include it in browser components. Adjust relative imports if you move the route.

Development and build order

Build the adapter first, then run the xmcp watcher alongside your host development server:

{
  "scripts": {
    "dev": "xmcp build && (xmcp dev & vite dev)"
  }
}

The xmcp watcher updates discovery when tools, prompts, or resources are added or removed. The host processes their TypeScript and framework imports. Keep .xmcp/ ignored by Git. Run xmcp before your application's production build and retain the host's type checking; skipTypeCheck only disables xmcp's separate check.

The runnable example uses SvelteKit 3 with configuration in vite.config.ts and requires Node 22.17+. Initialization also recognizes existing SvelteKit 2 projects and leaves their configuration intact.

For Node production, use SvelteKit's Node adapter. Run xmcp build && vite build && svelte-check, then start the generated server with node build. Keep the MCP endpoint server-rendered; it cannot be served by a static-only deployment.

Cloudflare Workers

Configure SvelteKit's Cloudflare adapter and add nodejs_compat to Wrangler's compatibility_flags. Build xmcp with --cf before SvelteKit:

{
  "scripts": {
    "dev": "xmcp build --cf && (xmcp dev --cf & vite dev)",
    "build": "xmcp build --cf && vite build && svelte-check",
    "preview": "wrangler dev",
    "deploy": "pnpm build && wrangler deploy"
  }
}

Vite development is useful for application edits. Validate the built Worker using wrangler dev as well. The example has separate Node and Workers scripts and a Wrangler configuration for .svelte-kit/cloudflare/_worker.js.

Workers builds emit .xmcp/adapter/index.js with the Workers-compatible runtime. xmcp does not emit a standalone Worker or rewrite Wrangler configuration in adapter mode. Tools and their dependencies must also be compatible with Workers.

Authentication and CORS

Authenticate with SvelteKit server hooks or your endpoint. After verifying credentials, pass the verified information into the handler:

return xmcpHandler(request, {
  authInfo: {
    token: verifiedToken,
    clientId: verifiedClientId,
    scopes: verifiedScopes,
  },
});

The variables above come from your application's credential verification. Reject unauthorized requests before calling the adapter. Passing authInfo forwards it to MCP handlers as extra.authInfo; it does not verify credentials itself.

Configure browser CORS and OPTIONS responses in SvelteKit server hooks or your endpoint, before invoking xmcp. Include the MCP headers required by your clients. Preserve the returned streaming response; do not parse and reserialize it. Avoid consuming the original request body before passing it to xmcp.

Stateless request metadata

Each request gets a fresh MCP server with isolated request context. Initialization does not create a persistent session. Repeat authentication and client metadata on each request: modern clients use protocol metadata, while older clients can send x-mcp-client-name and x-mcp-client-version headers.

The SDK handles protocol validation, malformed JSON, and unsupported methods. Registering GET and DELETE forwards them to the transport; it does not enable persistent sessions.