The changelog and version switch are what set this apart from a model recalling Ant Design from training: asking whether a component supports something becomes a question with a version attached, which is the form the question actually takes in a real project. Fetch the examples and the typed API before generating a screen — the union types are exactly the detail that makes generated antd code compile or fail.
A local Ant Design reference. Component documentation, example code, API tables and changelogs are bundled and served as tools, and the active antd version can be switched so the answers match the version the project is on.
- The list of available components, for turning a described interface into the components that can build it
- Full documentation for one or several named components in a single call
- Example code per component, so generation starts from working usage rather than from an invented prop set
- The component API with TypeScript types and union values — the part that decides whether a prop takes a string or one of four literals
- Changelogs for named components, which answers whether the feature you want exists in the version installed or needs an upgrade
- A version switch, so all of the above answer for the antd version the project actually uses
- Best-practice notes per component, gathered by a crawler the author describes as still rough
Node.js 16 or newer. It runs as npx antd-mcp, or from a local build with node dist/cli.js after npm install and npm run build. Nothing to authorize and no network calls for lookups — the component docs, examples and API data are extracted into the repository, with scripts to re-extract them from a local clone of the Ant Design repository and to regenerate the component changelog file when it is missing.
One command — npx antd-mcp