design-system-mcp: Add new package for design system MCP tooling

[aduth]

What?

Closes #77206

Implements a new package @wordpress/design-system-mcp which serves as a local MCP server, providing a bridge between AI agents and the WordPress design system implementation.

Related: #74626

Note that the current manifests have some existing issues that need to be resolved for this to work well (e.g. #77112)

Why?

Agents are a common part of many developer's workflow, but often struggle to achieve the consistency we hope to see with a design system in recommending guidance and offerings (components, tokens). The goal of this new package is to provide a simple setup experience for someone already using AI agents in development to make those guidance and offerings more readily available, while neither increasing our own maintenance burden nor favoring one documentation vehicle over another (see "How" below).

How?

This leverages existing resources that can be reliably assured as up-to-date:

• The design token reference, which is generated automatically as an artifact from the source design tokens via a custom plugin for our Terrazzo setup
• Existing Storybook data, which is already available in raw JSON format (components.json) as of Enable components manifest for Storybook #74626

It's implemented as a npm Node binary, which works well with mcp.json configuration. This also avoids the need for external MCP server hosting. This is a common setup experience for other projects offering MCP (e.g. Chakra UI).

I had explored an alternative approach leveraging WordPress Abilities API + mcp-adapter which, while an interesting example of "dog-fooding", may not be a great fit:

• It requires that we figure out a hosting arrangement for where this lives, presumably somewhere on wordpress.org
• The bigger issue is that MCP servers using HTTP as a transport layer are stateful, and require session management. The existing WordPress tooling around MCP (i.e. mcp-adapter) is optimized for authenticated users, and isn't a good fit for a public MCP server where we'd want to support anonymous access.
• It's also overkill, since the proposed approach here doesn't do anything particularly special beyond fetching and transforming static assets

Testing Instructions

The ideal workflow (i.e. referencing the published npm package) is only possible to test once this is merged and published.

In the meantime, you can test a couple ways:

• Using the MCP inspector tool:
  1. Run npm run build to build files
  2. Run npx @modelcontextprotocol/inspector node packages/design-system-mcp/bin/design-system-mcp.mjs
  3. A browser window should be opened at http://localhost:6274/ (or visit manually)
  4. Click "Connect" (options should be configured already)
  5. Click "List Tools"
  6. Observe three tools: get_components, get_component_details, get_design_tokens
  7. Click each of the tools and then play with parameters and "Run Tool" to observe expected output
• Using mcp.json, pointing to the local built file:
  1. This varies by client, but in my case using Claude Code it looks like: claude mcp add wordpress-design-system -- node /path/to/gutenberg/packages/design-system-mcp/bin/design-system-mcp.mjs
  2. Open an agent conversation in the context of wherever you configured the MCP server
  3. Ask the agent something about the design system (e.g.

Screenshots or screencast

MCP Inspector example:

Claude Code example:

Use of AI Tools

Claude Code + Claude Opus 4.6, plus a fair bit of back-and-forth and post-processing manual edits. Used for both research of approach and package implementation.