SvelteKit MCP: The Official Svelte Server, and What Its Autofixer Found in 134 Components

If you searched “SvelteKit MCP”, you most likely want the official Svelte MCP server: a package from the Svelte team, @sveltejs/mcp, that gives a coding agent current Svelte 5 documentation and a static-analysis autofixer for the code it writes. It is one command to add to Claude Code. This site is a SvelteKit app, so on 09/26/2026 I ran that autofixer over every component in its repository. Of 134 files, 50 came back clean, 70 each blocks were missing keys across 39 files, and 34 files failed to parse. All 34 inject JSON-LD structured data, which on a site that lives on search is the code you most want checked.

My other SvelteKit post covers WebMCP, which is a different thing with a similar name, and the Claude Code complete guide covers the setup these servers plug into. The table below separates the two.

TL;DR

You want	Use	What it does
An agent that writes better Svelte	The Svelte MCP server, @sveltejs/mcp	Current docs and an autofixer, inside Claude Code or Codex
A site that exposes its own tools to browser agents	WebMCP	A browser API your pages call to register tools

The rest of this post is the first row: setup, the four tools, and what the autofixer did on a real codebase.

Add the Svelte MCP server to Claude Code

Local, over stdio, with the package fetched by npx:

claude mcp add -t stdio -s project svelte -- npx -y @sveltejs/mcp

Remote, over HTTP, with nothing to install:

claude mcp add -t http -s project svelte https://mcp.svelte.dev/mcp

The scope is user, project or local. project writes the server into the repo’s .mcp.json; once that file is committed, anyone who opens the repo in Claude Code is asked to approve the server and then gets it. The Svelte docs say the team does not log, store, or inspect code sent to the remote server. If your policy keeps code on the machine, use the local command.

For Codex, the Svelte docs give this remote configuration for config.toml:

experimental_use_rmcp_client = true
[mcp_servers.svelte]
url = "https://mcp.svelte.dev/mcp"

The Svelte team also publishes a Claude Code plugin that sets up the local server with two skills, svelte-code-writer and svelte-core-bestpractices, and says the skills ship for Codex, GitHub Copilot CLI and OpenCode too. The install steps are on the Svelte AI docs.

The four tools

Tool	What it does, per the Svelte docs
list-sections	Lists the available documentation sections
get-documentation	Fetches full, current documentation for the requested sections from svelte.dev
svelte-autofixer	Uses static analysis to suggest fixes for code the model generates
playground-link	Generates an ephemeral playground link with the generated code

The documentation tools let the agent write against current Svelte 5 docs instead of what it remembers, which is how Svelte 4 patterns end up in Svelte 5 projects. The autofixer is the check on the result.

An MCP server only helps when the agent calls it. Put one line in the repo’s CLAUDE.md or AGENTS.md: fetch Svelte documentation through the Svelte MCP server before writing a component, and run svelte-autofixer on every component you create or edit.

What the autofixer found in 134 production components

The package also installs a command line version, svelte-mcp, so you can run the autofixer on code that already exists rather than only on what an agent writes next:

npx -y @sveltejs/mcp svelte-autofixer src/lib/components/InlineCTA.svelte

I ran it on every .svelte file under src/ in this site’s repository with version 0.1.26, which assumes Svelte 5 by default.

Result	Files	Findings
Clean, no issues or suggestions	50	0
Each block without a key	39	70
Unused CSS selectors	1	54
Svelte 4 export let flagged as invalid in runes mode	2	2
Failed to parse	34	parse error only, except the page with the unused selectors
Suggestions, mostly about work done inside $effect	15	69

Autofixer output for 134 files, chudi.dev repository, 09/26/2026. One file appears in two rows: the services page failed to parse and still reported its 54 unused selectors.

Two of those rows I already knew about. The 54 unused selectors are all in one page, and svelte-check reports 54 warnings on the same page. The two Svelte 4 files are podcast pages that still declare their props with export let. The missing keys were new to me: 70 each blocks rendering lists without a key, which is harmless for static lists and a real bug for any list that reorders.

The suggestions are advice, not errors. About half of the 69 are about work done inside $effect: calling a function there that may assign state (19 in 6 files), assigning a stateful variable there where a $derived might do (7 in 5 files), and similar. Other groups include passing a function to $derived where it expects an expression (15 in 4 files) and bind:this that could be an action or attachment (9 in 7 files). One example, from the component that renders this site’s inline calls to action:

The stateful variable “adhdCheckoutHref” is assigned inside an $effect which is generally consider a malpractice. Consider using $derived if possible.

The rule is sound in general, and here it is wrong. That $effect is deliberate: the server renders the plain checkout link, and the effect adds the visitor’s attribution after the page loads in the browser, where that data lives. A $derived would run during the server render and never see it. Read the suggestions as questions for a person who knows why the code is shaped that way, not as fixes to apply.

The blind spot: JSON-LD components

34 files returned the same error: Unexpected keyword or identifier. at line undefined, column undefined. 33 returned nothing else; the services page also returned its 54 unused selectors. Those files compile and run in production. All 34 contain application/ld+json, the structured data that tells search engines and AI answer engines what a page is. Of the 36 files in the repo that emit JSON-LD, the autofixer could read 2.

This is enough to reproduce it:

<script lang="ts">
	const schema = JSON.stringify({ a: 1 });
</script>

<svelte:head>
	{@html `<script type="application/ld+json">${schema}</script>`}
</svelte:head>

That component fails. The same component rendering {schema} inside a paragraph passes. The two JSON-LD files that did parse gave away the cause: they write the closing tag as <\/script>. Change that line in the repro and the autofixer reads the file, then flags the {@html} as a possible XSS risk, which is a fair warning: JSON.stringify does not escape </ inside your data, so any schema field that can hold user text should have < replaced with \u003c before it goes in.

On a SvelteKit site that earns its traffic from search, the files that carry the schema for every page were the files the check skipped. In a real file, escape every closing tag, not only the first: about half of the 34 files have two to four of them, and one unescaped tag is enough to keep the parse failing.

One operational note. With no network access to svelte.dev, the documentation commands failed, and 70 of 134 files in my first run, eight at a time, exited before printing a result. Rerunning the failed files one at a time returned all 134. If you run it in CI behind a restrictive egress policy, allow svelte.dev or retry.

What to do with it

1. Add the server to the project scope so the whole repo gets it.
2. Add the one-line instruction to CLAUDE.md or AGENTS.md so the agent actually calls it.
3. Run the autofixer once over your existing components. Missing keys on lists that can reorder are the findings to fix first; treat the suggestions as questions.
4. Escape every closing script tag in components that inject JSON-LD, so the autofixer can read them.

For the other half of the name, WebMCP in SvelteKit covers exposing a site’s own tools to browser agents, and the Claude Code complete guide covers the rest of the setup these servers sit in.