Local MCP

Let the AI assistant in your code editor check, test and debug your Siteglide code safely, alongside Siteglide CLI.

Written By Luke Wakefield

Last updated 4 days ago

The Local MCP is a set of tools your AI coding assistant can use to work with your Siteglide project. It runs on your computer alongside Siteglide CLI. As well as editing files, the assistant can validate Liquid, GraphQL and YAML, run GraphQL, evaluate Liquid against staging and read logs, using the Siteglide CLI setup you already have.

It works with Cursor, Claude Code, Windsurf and other editors that support MCP. It needs Siteglide CLI v1.11 or later.

If you want an AI app to work with your site content and data without a local project, use the Cloud MCP instead. See MCP overview to compare the two.

Why use it?

Catch mistakes before they reach your site. The assistant validates Liquid, GraphQL and YAML against Siteglide rules as it goes, and fixes problems before it saves files.

Test against real data. The assistant can run Liquid and GraphQL against your site from the editor, reading and updating your data. This makes it powerful, so point it at a staging site.

Debug faster. Pull recent platform logs when something fails, instead of switching between the admin, the terminal and your editor.

Your credentials stay on your machine. Credentials stay in Siteglide CLI. The assistant uses environment names, such as staging, and should never read or paste your tokens.

Same platform as your site. The Local MCP talks to the same environments you sync to with siteglide-cli sync.

What you need

Siteglide CLI 2.0 or later, with an environment added (for example, staging).
Git set up for your project. It's optional, but strongly recommended. See Version Control (Git).
A staging copy of your site for testing. Agencies can create one in the Copies tab.
An AI coding assistant that supports MCP, such as Cursor.

Set it up

1. Pull your project

siteglide-cli pull <env>

Replace <env> with your environment name, for example staging. On the first pull the CLI asks a few one-time questions, including which AI assistants you use and whether to set up Git. It then offers to install the Siteglide MCP (@siteglide/siteglide-mcp) and adds it to your editor's MCP settings in the project folder. Type y.

When a newer compatible version of the MCP is out, pull offers to update it. If you say no, it asks again after 7 days.

2. Turn it on in your editor

In Cursor, open Settings, then Tools & MCP, turn on the siteglide server, and reload the window. Other editors have a similar MCP settings page.

3. Check it's working

Ask your assistant: "List my Siteglide environments and validate my homepage Liquid."

If it lists your environments and labels them staging or production, you're set.

How to use it

You don't call the tools yourself. Describe what you want in chat and the assistant picks the right tool.

You want to	Example prompt
Fix or build a section	"Validate this Liquid partial and fix any errors."
Check a GraphQL query	"Run this query against staging and show me the record shape."
Preview Liquid output	"Evaluate this Liquid snippet against staging data."
Debug an error	"Fetch recent logs from staging for this page."
Check sync before editing	"Is sync running, and which environment is it pointed at?"
Sort out Git	"Check my Git setup for this project and help me fix anything missing."
Resolve a sync conflict	"Sync warned me about a remote change. What happened and what should I keep?"

The first time you use it, the assistant may ask about your role and how much Git and CLI experience you have. It uses your answers to pitch its explanations at the right level. They're saved in your project, so it only asks once.

What the assistant can do

Tool	What it does
`validate_code`	Checks Liquid, GraphQL and YAML in your project before or after the assistant saves changes. Works offline.
`siteglide_rules` / `siteglide_guide`	Loads Siteglide's rules and conventions, so the assistant follows how Siteglide works rather than generic platformOS advice.
`envs_list`	Lists your environments and labels each one staging or production. It never shows tokens or emails.
`sync_status`	Shows whether `siteglide-cli sync` is running for this project, and against which environment.
`git_status`	Checks your Git install, identity, repository and remotes, and can walk you through setting up Git.
`audience`	Reads or asks for your role and experience level, so explanations suit you.
`remote_check_status`	Reads the CLI's logs when a sync, pull or deploy found a remote change or a conflict, so the assistant can explain it and help you decide what to keep.
`graphql_exec`	Runs GraphQL queries and mutations to read or update CMS, WebApp and CRM data. Changes on production need your approval.
`liquid_exec`	Evaluates Liquid against staging. It's blocked on production.
`logs_fetch`	Fetches recent logs for an environment.

Staging and production safety

The Local MCP is built to keep live sites safe from accidental changes.

Environments are labelled by their URL, not their name. A site on a staging address counts as staging. Everything else, including custom domains, counts as production, even if you named it "test".
The assistant checks sync before editing. If any sync is running against production, it follows a stricter process and asks you before changing files.
Liquid evaluation is blocked on production. If the assistant needs to work with production data, it writes the Liquid into your project files so you can review it before you sync.
GraphQL changes on production need your approval. It can read production data, but asks you before a mutation runs.
Your credentials stay with the CLI. The assistant uses environment names and is told never to open your CLI config file.
Data from your site is marked as untrusted. This helps the assistant ignore any instructions hidden in that data.
Sync, pull and deploy stay with you. The Local MCP has no tools to run them. It doesn't stop the assistant running those commands if you ask it to.
One command at a time. The CLI won't start a second sync for the same environment in the same folder, and won't run sync, pull and deploy at the same time in one project. You can sync two different environments at once, but the assistant treats that as production.

Good practice

Turn on your assistant's privacy mode, or turn off training on your data.
Say "staging" in your prompt when you want live tests.
Pull before the assistant starts generating code.
Use Git. With CLI 2.0, pull, sync and deploy merge remote changes into your work instead of overwriting it, and Git lets you see exactly what the assistant changed. See Version Control (Git).

Known limitations

Existing projects already on GitHub. The smoothest start is a new site with the new CLI and MCP. If your project already uses GitHub, the first pull creates a baseline with one larger merge. Your assistant can help you work through it.
Images and other binary files. CSS, JS and other text files are checked for conflicts. Binary files such as images aren't yet, so take care when two people change the same image.
Deleted or moved files can come back. If someone with an old copy syncs after a file was deleted or moved, the CLI sees it as a new file. Pull after big moves and ask teammates to do the same.
There's no embeddings tool yet.

Troubleshooting

The assistant doesn't have Siteglide tools. Turn on the siteglide MCP server in your editor settings and reload.

The tools fail to start. Run siteglide-cli pull <env> again. It reinstalls or updates the MCP if needed and fixes the editor settings.

You're stuck on a temporary branch after a pull or sync. Ask the assistant: "I'm stuck on a temp branch after a Siteglide pull, help me get back." It knows how to rescue you.

Validation passes but the site looks wrong. Check sync is running and pointed at the right environment. Give the assistant the page URL, or paste errors from the page and browser console into chat.

Something else isn't working. Tell us on the Siteglide feedback board.

Was this helpful?

Still need help? Ask the team