Provides tools for interacting with a Jekyll project, including project inspection, component lifecycle management (list, get, create, validate, delete), SCSS/design token updates, and running Jekyll build and doctor commands.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jekyll-component-mcp create a new card component with SCSS and docs"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI-native development MCP server for Jekyll projects and reusable Liquid/SCSS/JavaScript components.
Related MCP server: craft
Jekyll-aware tools — not a generic filesystem wrapper
Component lifecycle — list, get, create, validate, delete
SCSS + design tokens — architecture detection and safe updates
Secure by default — project-root sandbox, allowlisted commands, write modes
Dry-run support — preview mutations before writing
Resources & prompts — structured context and review workflows for agents
Node.js 20+
A Jekyll project (optional Gemfile / Bundler)
npm install -g jekyll-component-mcp
# or use locally
npx jekyll-component-mcp --root /path/to/jekyll-projectThe package includes a skill with instructions for AI agents to install, configure, and use this MCP server. After the package is published, share this URL with an AI agent that can access web links:
https://unpkg.com/jekyll-component-mcp@latest/skills/SKILL.md
For repeatable instructions, replace latest with a published version, for example @1.0.0. You can ask the agent: "Read and follow this skill to set up and use jekyll-component-mcp: https://unpkg.com/jekyll-component-mcp@latest/skills/SKILL.md".
# Generate .jekyll-mcp.json (detects standard Jekyll, Chirpy, or Minimal Mistakes)
jekyll-component-mcp init
# From your Jekyll project root
jekyll-component-mcp --root .
# Or via environment
JEKYLL_PROJECT_ROOT=/path/to/project jekyll-component-mcpnpm run build
npx @modelcontextprotocol/inspector node dist/index.js --root /path/to/jekyll-projectMode | Create / Update | Delete / Destructive |
| ❌ | ❌ |
| ✅ | ❌ |
| ✅ | ✅ (requires |
jekyll-component-mcp init [--root <path>] [--preset auto|standard|chirpy|minimal-mistakes] [--force] [--yes]
--root <path> Project root
--readonly read-only mode
--safe-write safe-write mode (default)
--full-write full-write mode
--timeout <ms> Build timeout (default 120000)
--max-file-size <bytes> Max file size (default 2MiB)
--debug Debug logging to stderrinit detects common Jekyll include, Sass, layout, and data directories, then writes a
ready-to-use .jekyll-mcp.json. It preserves an existing configuration unless
--force is supplied. In an interactive terminal, the detected theme preset can be
confirmed or changed.
Optional .jekyll-mcp.json in the project root:
{
"root": ".",
"writeMode": "safe-write",
"build": {
"command": "bundle exec jekyll build",
"timeout": 120000
},
"paths": {
"components": "_includes/components",
"scss": "assets/scss",
"docs": "docs",
"layouts": "_layouts"
}
}Tool | Purpose |
| High-level project summary |
| Full architecture map |
| Sanitized config |
| List components |
| Component details + sources |
| Create component + SCSS + docs |
| Structured validation |
| Aliases for component discovery and inspection |
| Aliases for generation and validation |
| Destructive delete (full-write + confirm) |
| Run Jekyll build |
| Run jekyll doctor |
jekyll://project
jekyll://components
jekyll://config
jekyll_component_review
jekyll_accessibility_review
jekyll_performance_review
jekyll_production_review
Filesystem sandbox: every path is resolved under the project root; traversal and symlink escapes are rejected.
Command allowlist: only jekyll build|clean|doctor (and bundle exec variants). No arbitrary shell.
Write policy: configurable; destructive ops require full-write + confirm: true.
Secrets: config reads redact common secret keys; process output is scrubbed.
stdio: stdout is reserved for MCP JSON-RPC; all logs go to stderr.
{
"mcpServers": {
"jekyll-component": {
"command": "npx",
"args": ["-y", "jekyll-component-mcp", "--root", "/path/to/jekyll-project"]
}
}
}Add an MCP server entry pointing at node /path/to/jekyll-component-mcp/dist/index.js with --root args as needed.
npm install
npm run typecheck
npm run build
npm test
npm run dev -- --root ./examples/jekyll-component-frameworkMIT
Run a Jekyll build (bundle exec jekyll build when Gemfile present). Captures exit code, stdout, stderr, duration, and _site path. Does not accept arbitrary shell commands. Use after creating or modifying components to verify the site builds. May take up to the configured timeout (default 120s).
Inputs: clean.
Create a reusable Jekyll Liquid component and its associated SCSS, documentation, and example files. Use when the user asks to create a new reusable UI component. Do not use for one-off page markup. This operation modifies project files. Supports dry_run. Names are normalized to kebab-case.
Inputs: name (required), dry_run, example, category, +3 more.
Delete a component and its associated files (Liquid, SCSS, JS, docs, example). DESTRUCTIVE. Requires confirm: true and full-write mode. Prefer dry reasoning before calling.
Inputs: name (required), confirm (required).
Get full details for one component by name: Liquid/SCSS/JS/docs source, detected parameters (include.*), variants, accessibility notes, and class names. Use before editing or reviewing a component. Read-only.
Inputs: name (required).
List all detected reusable components with paths to Liquid, SCSS, JavaScript, documentation, and examples. Use to discover existing components before creating new ones. Read-only.
Inputs: no named parameters.
Validate a component: file existence, Liquid syntax patterns, SCSS presence, documentation, accessibility hints, and parameter consistency. Returns structured errors and warnings. Read-only.
Inputs: name (required).
Read Jekyll configuration (_config.yml etc.) with sensitive keys redacted. Use to understand site settings. Never returns API keys, tokens, or credentials. Read-only.
Inputs: no named parameters.
Create component documentation (Overview, Usage, Parameters, Variants, Example, Accessibility, Notes). Modifies project files. Supports dry_run.
Inputs: name (required), dry_run, overview, variants, +1 more.
Update or regenerate documentation for a component. Fills gaps from detected Liquid parameters when possible. Modifies project files. Supports dry_run.
Inputs: name (required), notes, dry_run, overview, +3 more.
Run jekyll doctor to check for common configuration and environment issues. Read-only regarding project source files.
Inputs: no named parameters.
Read a Liquid include by name or relative path. Returns source, front matter, parameter analysis, and basic syntax checks. Read-only. Never executes Liquid.
Inputs: name (required).
List Liquid includes under _includes (excluding the components/ and sections/ subtrees, which have dedicated tools). Read-only. Never executes Liquid.
Inputs: no named parameters.
Read a Liquid layout by name or relative path. Returns source, front matter, and analysis. Read-only. Never executes Liquid.
Inputs: name (required).
List Liquid layouts under _layouts. Read-only. Never executes Liquid.
Inputs: no named parameters.
Return a high-level summary of the Jekyll project: whether it is a Jekyll site, counts of layouts/includes/components, presence of SCSS/JS/docs, and current write mode. Use this first to orient yourself. Does not modify any files. Never exposes secrets.
Inputs: no named parameters.
Scan the project and return a structured architecture map: config files, key directories, layouts, includes, components (with liquid/scss/js/docs paths), sections, SCSS and JS files. Use when you need a detailed map before creating or modifying components. Read-only.
Inputs: force.
Create a new SCSS partial (e.g. component or utility). Writes under the configured SCSS tree. Modifies project files. Supports dry_run.
Inputs: name (required), content, dry_run, category.
Read an SCSS file and return its source plus analysis (imports, variables, CSS custom properties, mixins, selectors). Provide a path relative to the project root (from jekyll_scss_list). Read-only.
Inputs: path (required).
List SCSS/CSS files under the project SCSS root and detect architecture layers (tokens, mixins, base, utilities, components, sections). Use to understand stylesheet structure before editing. Read-only.
Inputs: no named parameters.
Get tokens matching a name or category (e.g. 'color', 'spacing', '--color-primary'). Read-only.
Inputs: name (required).
List design tokens discovered in SCSS (CSS custom properties and Sass variables), categorized by color, spacing, radius, shadow, typography, breakpoints, motion, etc. Read-only.
Inputs: no named parameters.
Update or append a design token declaration in an SCSS/CSS file. Prefer CSS custom properties. Modifies project files. Supports dry_run.
Inputs: file (required), name (required), value (required), dry_run.
Run safe project-level validation: component structure, Liquid patterns, front matter, optional Jekyll build. Returns structured errors and warnings. Does not execute arbitrary shell.
Inputs: run_build.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 23 tools
Tools are cleanly partitioned by resource (project, layout, include, component, scss, token, docs) with distinct actions. A few pairs invite mild confusion—jekyll_project_info vs jekyll_project_scan, jekyll_validate vs jekyll_component_validate, and jekyll_validate vs jekyll_build vs jekyll_doctor—but their descriptions clearly delineate scope.
Every tool follows the exact jekyll_{resource}_{action} snake_case convention (e.g. jekyll_component_create, jekyll_scss_list, jekyll_token_update). The pattern is uniform across all 23 tools with no camelCase or verb-style deviations.
23 tools is on the higher side but the domain (components, layouts, includes, SCSS, tokens, docs, validation, build) is genuinely broad and the tools are cleanly grouped. Each entry has a distinct function, so the count is defensible rather than bloated.
Strong coverage of a read-and-manage workflow: full list/get/create/delete/validate for components plus project info, tokens, docs, build, and doctor. Notable gap: no jekyll_component_update (and no SCSS update/delete), so editing an existing component's files has no dedicated tool despite guidance to 'use before editing.'
Project memory, documentation and controlled secret access for AI coding agents.
Gives AI agents direct access to your Sanity projects and guidance for working with them
Git-backed platform for skills, tools, and context for AI agents
Context and control for any AI. Agent identity, scoped access, and proof across tools.
