SvGrid

@svgrid/mcp

The official Model Context Protocol server for SvGrid.

Website · Docs · Pricing

---

Point any MCP-capable client - Claude Desktop, Claude Code, Cursor, Zed - at this server and the model answers with accurate, version-pinned facts about SvGrid: real prop, method, and event names, plus every demo's source as grounding. No hallucinated APIs, no stale blog posts.

Why this beats pasting docs into the chat. A model working from memory invents plausible SvGrid APIs, because it learned from a mix of other grids and older versions. Pasting docs helps for one question and then falls out of the context window. This server puts the current API surface and every working demo source one tool call away, for every question, pinned to the version you installed.

Tools exposed

Five. tools/list is sent on every request, so the tool surface is pure overhead on every turn - this server used to spend ~4,710 tokens of it on 36 tools, 79% of them Studio tools most sessions never call once.

The docs and demos are also served as MCP resources (svgrid://doc/ , svgrid://example/ ), and four prompts ship ready to run: build_grid, build_sheet, explain_api, review_grid_code.

Every pre-3.0 tool name still answers - search_docs, get_doc, list_examples, get_example_source, list_docs, get_api_reference, check_svgrid_code, introspect_source, scaffold_entity, and all 27 individual studio_* tools. They are not listed, because listing is what costs context and answering an unadvertised name costs nothing. Their response shape follows 3.0.

svgrid_check_code - the one a retrieval server cannot do

Reading the docs makes a model *likelier* to be right. This makes it *checkable*. Hand it a file and it answers with line-numbered diagnostics and the exact replacement for each:

{

"ok": false, "checkedAgainst": "@svgrid/grid@2.6.20", "compiler": "svelte", "counts": { "errors": 3, "warnings": 0, "info": 0 }, "diagnostics": [ { "rule": "svgrid/renamed-prop", "severity": "error", "line": 24, "message": "rowData is not a SvGrid prop.", "fix": "Use data." }, { "rule": "svgrid/renamed-column-key", "severity": "error", "line": 10, "message": "accessorKey is not a SvGrid column key.", "fix": "Use field." }, { "rule": "svelte/legacy-event-directive", "severity": "error", "line": 30, "message": "on:rowClick never fires: SvGrid dispatches no component events, it takes callback props.", "fix": "Use onRowClick={...}." } ] }

What it checks:

• Every name, against the installed version. Importable symbols, props, ColumnDef keys, grid API methods, theme stylesheets. The list is generated from the package sources at build time, so it cannot drift from what the package exports, and an unknown name comes back with the nearest real one.
• Cross-package mistakes. A symbol that lives in @svgrid/enterprise, or an api method that only exists after installEnterprise(api).
• Svelte 5 rules. export let and $: in a runes file (compiler errors), on: / / createEventDispatcher (deprecations), and a plain let array that gets mutated and silently never re-renders.
• The file, compiled. When a Svelte compiler is reachable - the user's project copy first, then the one shipped here - real parse errors come back too. The result says which of the two ran in its compiler field, so "no errors" is never mistaken for "this compiles".

It is tuned to shut up when the code is right: it reports nothing across every demo in this repo, which is what a CI test asserts. A verifier that cries wolf is worse than none, because a model will happily "fix" working code.

Studio: drive the app model (agent co-designer)

The studio_* tools let an agent build and edit the same validated project model the visual designer uses - add entities, screens, blocks, components, wire data sources, theme, RBAC, auth, the typed data layer, and the deploy target - then generate the full runnable app or export the studio.config.json the designer can Load. Every edit runs through the model's own functions + validateProject, so the agent can't produce an invalid app.

Opt-in. Set SVGRID_MCP_STUDIO=1, or a valid SVGRID_LICENSE_KEY, in the server's env. Tools that need a licence to be useful should not cost every other user context on every request.

These tools and svgrid_scaffold run on @svgrid/enterprise, an optional peer that npx -y @svgrid/mcp does not install (it would double the cold start). Install both in the project and run the local server:

npm i -D @svgrid/mcp @svgrid/enterprise

claude mcp add svgrid -- npx svgrid-mcp

A typical session: studio_project (new) → one studio_apply batch per screen → studio_configure → studio_build (generate) → write the files and run svelte-check.

studio_apply batches on purpose. Twenty-seven one-per-mutation tools made a five-screen app twenty-odd round trips; a whole screen is now one call, and a failure reports which op failed and what already applied.

Two ways to run it

# No install: point any MCP client at the hosted server

claude mcp add --transport http svgrid https://mcp.svgrid.com/mcp

The remote server is live at https://mcp.svgrid.com/mcp and carries the docs, verification and preview tools (source). Use stdio when you want the compiler pass, the Studio tools, or no third-party endpoint in the loop.

Run

# One-shot via npx (no install)

npx @svgrid/mcp

Or install globally, then run the bin

npm install -g @svgrid/mcp svgrid-mcp

The server speaks MCP over stdio: stdout is reserved for JSON-RPC, logs go to stderr.

Connect Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{

"mcpServers": { "svgrid": { "command": "npx", "args": ["-y", "@svgrid/mcp"] } } }

Restart Claude Desktop and open a new chat - the tools above are now available.

Connect Claude Code

claude mcp add svgrid -- npx -y @svgrid/mcp

Then run /mcp in a session to confirm svgrid is listed. Ask something like *"using svgrid, build a grid that groups by department and shows a sparkline per row"* and the model will pull the relevant demo sources before generating code.

Connect Cursor / Zed

Add the same mcpServers block to the editor's MCP configuration:

{

"mcpServers": { "svgrid": { "command": "npx", "args": ["-y", "@svgrid/mcp"] } } }

Build from source

cd packages/mcp

pnpm build node dist/index.js

pnpm build first runs scripts/build-manifests.mjs, which reads examples/src/demos/*.svelte and docs/**/*.md from the workspace and inlines them into src/data.ts, so the published package is fully self-contained.

Enterprise features

Export to Excel and PDF, pivot tables, the Kanban board, the scheduler, the spreadsheet and the server-side row model live in @svgrid/enterprise, which is commercial. Answers say so: a paid doc or demo in svgrid_search results carries "enterprise": true, a question about a paid feature gets one line with the trial link, and svgrid_check_code adds it when the fix is to install the package. The package runs without a license key and shows a watermark until one is set. The 30-day trial adds a download of every demo and 30 days of email support.

Licensing

MIT - free to run, no license key. Some tools generate SvGrid Studio projects, and Studio itself is commercial; see svgrid.com/pricing. The MIT @svgrid/grid core is free for any use.

SvGrid™ and sv-grid™ are trademarks of jQWidgets Ltd.