Vibe Design System: monday.com's React Component Library and Its MCP Server

The problem Vibe solves inside monday.com's product surface

Vibe exists so that applications built in React.js can share one visual and behavioural vocabulary with monday.com itself. The README calls it the "Official monday.com UI resources for application development in React.js", and the packages cover components, styles and guidelines. That framing matters. This is not a neutral component kit that happens to be maintained by a SaaS company. It is the resource set for building things that should look and behave like monday.com.

The audience follows from that. Teams writing monday.com apps, marketplace integrations, or internal tools that sit next to the monday.com UI are the intended users. If you are building a standalone product with its own brand, the value proposition is weaker: you would be adopting another company's visual language and its release cadence. The repository topics include react, typescript, design-system, icons and component-library, which is a fair summary of what is inside.

Package layout: @vibe/core, @vibe/icons, @vibe/testkit and the rest

The ecosystem is split rather than monolithic. The README lists @vibe/core for the component library, @vibe/icons for icons, @vibe/testkit for Playwright testing utilities, @vibe/codemod for codemods and CLI tools, @vibe/style for styling foundations (which the README says are included in @vibe/core), vibe-storybook-components for Storybook blocks, and @vibe/mcp for the MCP server. There is also storybook-addon-playground, which the README links to a separate mondaycom repository rather than this one.

That split is a real design decision with consequences. Installing @vibe/core does not automatically give you the icons package or the testkit. You add the packages you need. The upside is that a test-only dependency like @vibe/testkit does not have to ship in your production bundle. The cost is more entries in package.json and more version numbers to track. The published release list shows the packages version independently: @vibe/wizard at 4.0.4 while @vibe/typography and @vibe/tooltip both sit at 4.0.20. Do not assume a single version number covers the whole system.

Getting it running: install, tokens, imports

The install path is short. The README gives two options:

npm install @vibe/core

yarn add @vibe/core

One step is easy to miss. The README states that to load all the relevant CSS tokens you import the tokens file in your root application file:

import "@vibe/core/tokens";

Skip that import and components will render without the token layer. The README does not spell out what the failure looks like, so treat the import as mandatory rather than optional.

Components come from the package root entry. The README example is:

import { Button } from "@vibe/core";

There is no documented per-component deep import path in the material, so the root entry is the interface you should plan around. Documentation, a catalog and a playground live at vibe.monday.com, and the README links directly to the catalog and playground routes rather than describing component APIs inline. For anything beyond the install and import skeleton, the site is the reference.

The MCP server and what it changes about using the library

The most unusual part of this repository is @vibe/mcp. The README describes it as an MCP (Model Context Protocol) server that provides assistance for working with Vibe components: discovering component APIs, getting usage examples, finding appropriate icons, and following best practices. Installation instructions are not in this README. They live in the package README at packages/mcp/README.md, and the README says to follow those instructions to integrate the server into your preferred AI development tools.

This is a different kind of dependency from a component library. A normal UI kit is consumed by your build. An MCP server is consumed by your editor or agent, and it answers questions about the library. That is useful precisely because the component surface is large and the documentation lives on a separate site. Whether it works well depends on how complete the server's knowledge is, which the repository material does not quantify. Treat the MCP server as a discovery aid, not as a substitute for reading the component docs before you ship.

Version churn is the real cost: Vibe 2, 3 and 4

The README is unusually direct about version history, and that is the most useful part of it for anyone evaluating maintenance cost. Vibe 3, published as @vibe/core v3, will no longer receive new features or enhancements but will continue to receive critical bug fixes as needed. Vibe 2, published under the older name monday-ui-react-core, is no longer maintained at all. Vibe 4 is the actively maintained line, and the README recommends following the migration guide to upgrade to it.

Three major lines with different maintenance statuses means the name on your dependency line tells you which support you are getting. A project still on monday-ui-react-core is on an unmaintained package. A project on v3 is on bug fixes only, with no new components. Only v4 gets ongoing support and new work. The repository also ships @vibe/codemod, described as codemods and CLI tools, which is the mechanism the project provides for mechanical parts of an upgrade. The README does not list which codemods exist, so check the codemod package README before planning a migration by hand.

The cadence is also worth noting. The three most recent releases listed all landed on 2026-09-08, and the repository's last push was 2026-09-10. That is an actively released project, which cuts both ways: you get fixes, and you get version bumps to absorb.

Where Vibe is the wrong tool

The clearest limitation is scope. Vibe is monday.com's design system, and adopting it means adopting monday.com's visual and interaction decisions. If your product has its own brand identity, you will spend effort overriding tokens and component styles rather than benefiting from them. That is a worse starting position than a headless or unstyled primitive library where the visual layer was always yours to define.

A second limitation is the documentation surface. The README covers installation, the tokens import and the root import path, then points to vibe.monday.com for everything else. Component-level API detail, prop tables and examples are not in this repository's README. If you need to evaluate whether a specific component supports a specific behaviour, you have to go to the site, and the material here does not tell you how complete or current that site is for any given component.

A third is the license. The repository metadata supplied here lists the license as unknown. The README does not state a license. Before this library goes anywhere near a commercial product, read the actual license file in the repository. Nothing in the material here lets me tell you what terms apply.

Finally, the MCP server is only as good as the tooling you connect it to. If your team does not use an MCP-capable editor or agent, that package adds nothing to your workflow.

What a different choice looks like: unstyled primitives plus your own layer

The natural alternative is a headless or minimally styled React primitive library, where behaviour and accessibility are provided and appearance is entirely yours. The difference in approach is where the design decisions live. Vibe ships components, styles and guidelines together, so the visual result is largely determined by the library and the tokens you import from @vibe/core/tokens. A headless library ships the behaviour and leaves the styling layer to you from the first line.

That distinction decides the work. With Vibe, the fast path is a UI that looks like monday.com, and the slow path is fighting the tokens to make it look like something else. With headless primitives, every component starts unstyled, so you build the visual layer once and reuse it, and no vendor's brand is baked in. Neither is better in the abstract. If looking like monday.com is the goal, Vibe removes a large amount of design work. If it is not, a headless library removes a large amount of override work.

Who should adopt Vibe, and what to check first

Adopt Vibe if you are building a React application that should match monday.com, or that runs inside the monday.com platform, and you want the official components, icons and tokens from the vendor rather than a reimplementation. The install is two commands plus a tokens import, the package split lets you keep test utilities out of production, and the codemod package gives you a migration path when majors move.

Do not adopt it as a general-purpose design system for an unrelated product, and do not adopt it if you cannot accept the version cadence: v2 is unmaintained, v3 is bug-fix only, and v4 is where new work lands. If you are on v3 today, the upgrade is a real project, not a version bump, and the README's own recommendation is to follow the migration guide.

Three things to verify before you commit. First, the license, since the material here does not state one. Second, which @vibe/core major your codebase is on, because that determines whether you are buying maintenance or inheriting it. Third, whether the MCP server at packages/mcp/README.md supports the editor or agent your team actually uses, since that is the package most likely to be dead weight if it does not.

Editorial conclusion

Adopt Vibe if your React app lives inside the monday.com platform and you want the official components, tokens and icons from one vendor, or if you want an MCP server that answers component API questions for an AI coding tool. Do not adopt it as a general-purpose UI kit for a product with no monday.com relationship, because the components, tokens and versioning are shaped around that platform. Before you commit, check the license file at the repository root, confirm which @vibe/core major version your app is on, and read the migration guide at vibe.monday.com/?path=/docs/migration-guide--docs if you are still on Vibe 3.

Official sources

1. Issues
2. mondaycom/vibe on GitHub
3. Project website
4. README
5. Releases