# monday.com MCP: running the Model Context Protocol server for your work OS

> mondaycom/mcp ships a hosted MCP endpoint at https://mcp.monday.com/mcp and a local npx server that exposes monday.com boards and tools to Claude, Cursor, ChatGPT and Copilot. This is what the repository actually contains, how to wire it up, and where the hosted route is the better call.

**mondaycom/mcp** — Enable AI agents to work reliably - giving them secure access to structured data, tools to take action, and the context needed to make smart decisions.

- Repository: https://github.com/mondaycom/mcp
- Website: https://monday.com
- Stars: 427 · Forks: 101
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/mondaycom-mcp

## What monday.com MCP solves, and who it is aimed at

The repository is monday.com's own bridge between its work operating system and AI agents. The README frames the goal as letting agents "operate reliably within real workflows" with "secure access to structured data, tools to take action, and the context needed to make smart decisions." Stripped of the marketing, that means an agent can query boards, read status columns and updates, and call monday.com API operations through the Model Context Protocol instead of through hand-written GraphQL.

The audience is narrow and specific. The README addresses "AI agent developers who want to integrate with monday.com" and names three shapes of work: AI assistants, automations, and custom integrations. If you are a team lead who simply wants Claude to answer questions about your sprint board, you are a user of the hosted service rather than of this repository. The repository is for people who need to run, modify or embed the server.

Two packages sit inside it. @mondaydotcomorg/monday-api-mcp is the plug-and-play MCP server. @mondaydotcomorg/agent-toolkit is a separate set of tools for building agents against the monday.com API, and the README says it supports both OpenAI and MCP implementations. Those are different products with different entry points, and the README treats them as one repository rather than one tool.

## How the server fits between your agent and the monday.com API

The architecture is the standard MCP shape: a client (Claude Desktop, Cursor, Gemini CLI, ChatGPT, Copilot Studio) speaks the protocol to a server, and the server translates tool calls into monday.com API requests. The README describes the package as a "plug-and-play server implementation" that lets agents "interact with the monday.com API without needing to build complex integrations."

There are two deployment paths, and the difference matters more than the README's framing suggests. The hosted path is a remote MCP endpoint at https://mcp.monday.com/mcp, authenticated with OAuth and, per the README, able to limit access to specific workspaces. The local path runs the npm package as a child process of your MCP client and authenticates with a personal access token passed in an environment variable.

The hosted service holds your OAuth grant and the workspace scoping; the local server holds a long-lived token on your machine. That is the real trade-off, and the README's bullet list of hosted benefits (no local installation, automatic updates, better performance, higher reliability) is a vendor's summary of it rather than a neutral comparison. The repository itself is a Turborepo monorepo with yarn 1.22.21, a packages/ workspace directory, and a turbo build pipeline, so the local server is built from source in the same way as any other TypeScript workspace package.

## Installing the local MCP server and making a first call

The README's local guide starts with account setup, not with code. You need a monday.com account, a workspace and a board. The token comes from your avatar menu: Developers, then My access tokens, then copy the personal access token.

The fastest path is to let npx fetch the published package. This is the Claude Desktop configuration the README gives, and it is the same shape for any client that reads an mcpServers block:

```json
{
  "mcpServers": {
    "monday-api-mcp": {
      "command": "npx",
      "args": [
        "@mondaydotcomorg/monday-api-mcp@latest"
      ],
      "env": {
        "MONDAY_TOKEN": "your_monday_api_token"
      }
    }
  }
}
```

Replace the placeholder with the token you copied. After restarting the client you should see monday-api-mcp listed among the available servers, and the monday.com tools should appear in the tool list.

If you would rather use the hosted endpoint, the README's Cursor example is a single URL and no token at all, because OAuth handles the credential:

```json
{
  "mcpServers": {
    "monday-mcp": {
      "url": "https://mcp.monday.com/mcp"
    }
  }
}
```

Gemini CLI has its own route. The README documents an extension that bundles the server with a context file and custom commands, installed from the repository URL, or you can add the HTTP server directly:

```sh
gemini extensions install https://github.com/mondaycom/mcp
```

```sh
gemini mcp add -t http monday https://mcp.monday.com/mcp
```

Both commands come from the README verbatim. The extension route is the one that also teaches Gemini how to use the monday.com tools; the plain mcp add route gives you the server without that context.

## Where the local server is the wrong choice

The README is unusually direct that the hosted service is the recommended path, calling it "the fastest, most robust, and reliable way to connect." That phrasing is promotional, but the underlying point is defensible: if you run the server locally you own the token, the Node runtime and the upgrade cycle.

The token is the sharpest edge. A personal access token in an env block is a long-lived credential sitting in a client config file on a developer machine. The hosted path uses OAuth and, per the README, workspace controls that limit access to specific workspaces. If your concern is blast radius when a laptop is lost, the hosted route is the one with the smaller blast radius, and the local route is the one you should treat as a developer-only convenience.

Version drift is the second issue. The local config pins @latest, which means every client restart can pull a different build. The README lists automatic updates as a hosted benefit precisely because the local path does not have them. If you need reproducible behaviour across a team, pin an explicit version rather than @latest, and accept that you now own the upgrade.

The README does not document rollback, a version compatibility matrix between the server and the monday.com API, or what happens when a token is revoked mid-session. Treat those as open questions to test in your own environment rather than as documented guarantees.

## Hosted endpoint versus the agent toolkit

The obvious alternative to this repository is not a third-party MCP server. It is calling the monday.com API directly, and the repository itself supplies that alternative in the form of @mondaydotcomorg/agent-toolkit.

The difference in approach is who owns the tool definitions. With @mondaydotcomorg/monday-api-mcp, the tools are fixed by the server; your agent discovers them over MCP and you configure access. With @mondaydotcomorg/agent-toolkit, you get "a powerful set of tools and utilities" for building agents, with support for both OpenAI and MCP implementations. In the first case the server decides what the agent can do. In the second, you compose the agent and choose which monday.com operations it exposes.

That makes the toolkit the right pick when your agent has a narrow job, such as triaging incoming items into a specific board, and the full MCP tool surface would be noise. It makes the MCP server the right pick when you want a general assistant that can answer arbitrary questions about boards without you writing tool schemas.

Neither is a drop-in replacement for the other, and the README does not compare them head to head. It lists them side by side under "What's Inside" and leaves the choice to you.

## Licence, maintenance and upgrade cost

The repository is MIT licensed, and the LICENSE file sits at the top level alongside the package.json, which also declares "license": "MIT". MIT is permissive: you can modify the server, ship it inside a product, and keep your changes closed. The one obligation MIT imposes is preserving the copyright notice and permission text in copies or substantial portions. That is a general description of the licence, not legal advice for your situation.

Maintenance is the part worth reading carefully. The repository is not archived, and the last push was on 2026-09-10, which is recent enough that the project is being worked on. That push date is the only maintenance signal available here; there are no release notes in the repository, so there is no changelog to read for breaking changes.

Upgrade cost splits by path. On the hosted endpoint, upgrades are the vendor's problem and your cost is zero until a tool's behaviour changes. On the local path, the config uses @latest, so your cost is whatever it takes to notice and absorb a change in the tool surface. Pin the version if that cost matters to you. The monorepo runs on yarn 1.22.21 with a turbo pipeline, and the README states Node.js v20 or newer, so building from source means matching that toolchain.

## Conclusion

Adopt monday.com MCP if your agents need to read and act on monday.com boards and you would rather not hand-build GraphQL calls against the platform API. Use the hosted endpoint at https://mcp.monday.com/mcp unless you need to modify the server source, build custom agents on @mondaydotcomorg/agent-toolkit, or develop without internet access. Skip it if you have no monday.com account, since every path in the README starts with creating one and generating a personal access token. Before you commit, verify two things: that the workspace controls on the hosted service can be scoped to the workspaces you actually want exposed, and that the local server at @mondaydotcomorg/monday-api-mcp@latest resolves on your Node runtime, which the repository requires to be v20 or newer.

## FAQ

### Does monday.com have an MCP server?

Yes. This repository publishes @mondaydotcomorg/monday-api-mcp, a Model Context Protocol server that lets AI agents interact with the monday.com API, and monday.com also runs a hosted endpoint at https://mcp.monday.com/mcp.

### How do I set up monday.com MCP?

The README recommends the hosted endpoint first: add https://mcp.monday.com/mcp as an MCP server URL in your client, which authenticates over OAuth. For a local run, create a monday.com account, generate a personal access token under Developers then My access tokens, and add an mcpServers entry that runs npx @mondaydotcomorg/monday-api-mcp@latest with MONDAY_TOKEN set.

### What is monday.com MCP?

It is monday.com's open framework for connecting AI agents into its work operating system, giving them access to structured data and tools to take action. It ships as an MCP server package plus an agent toolkit for OpenAI and MCP implementations.

## Sources

- [Issues](https://github.com/mondaycom/mcp/issues)
- [License: MIT](https://github.com/mondaycom/mcp/blob/master/LICENSE)
- [mondaycom/mcp on GitHub](https://github.com/mondaycom/mcp)
- [Project website](https://monday.com)
- [README](https://github.com/mondaycom/mcp/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mondaycom-mcp