Design System MCP: realign with current DS release and publish as versioned npm package

[Spark450]

Description

The Design System MCP was previously available as a public hosted endpoint. Going forward, Design System AI tooling should be distributed as an open source, npm-packaged tool that teams install and run locally, versioned so coding agents can verify their installed MCP matches the project's Design System version.

Expected behavior

• MCP data is updated every push to dev, and published every time we publish our main packages
• MCP ships as a versioned npm package, published publicly under the @abgov npm scope, and run locally by consuming teams (not a hosted endpoint). `
• peerDependencies will have to be updated every release to the latest release of @abgov/web-components, @abgov/angular-components, and @abgov/react-components. Also make sure those peerDependencies are marked as optional.
• "How to run" is documented in the MCP repo's README and on the Design System docs site which outlines compatibility guidance.

Acceptance criteria

• Have the current MCP generation tool update a new package stored in libs for the MCP
• MCP published as a versioned npm package under the public @abgov.
  • You will need a package.json setup for the MCP that has peerDependencies, type: module, bin - listing the main executable for the MCP
• Install documentation added to the MCP repo's README.
• Install/update/compatibility documentation added to the Design System docs site.

[palasht75]

Hi, I’m interested in working on this issue.

I’ve reviewed the existing apps/design-system-mcp implementation and the package and release setup in ui-components. Before I put together the implementation plan, I wanted to confirm a few points:

• Is @abgov/design-system-mcp the intended package name, and should it live under libs/design-system-mcp?
• Should it have its own version, or stay aligned with Design System releases? What version range should the optional component peer dependencies use?
• On pushes to dev, should the MCP data only be regenerated and validated, or should a prerelease also be published?
• Should generated data be committed to the repo or created during build and release?
• Is the local package expected to support stdio only? Should the hosted endpoint and OpenShift setup be retired now or in a follow-up?
• Should the existing search and get behaviour remain unchanged, with any cleanup handled separately?
• After the package is released, should the existing DCP app and sync scripts be removed, deprecated, or kept?
• Can the new package use the same Apache-2.0 licence as ui-components?