monday.com MCP: A Hosted Server and a Local Toolkit for Board Automation

The Two Packages and the Split Between Them

The repository publishes two npm packages. @mondaydotcomorg/monday-api-mcp is a server implementation for the Model Context Protocol, described in the README as plug-and-play, which lets an agent call the monday.com API without the integrator writing a bespoke client. @mondaydotcomorg/agent-toolkit is a separate set of tools and utilities for building agents against the same API, and the README states it supports both OpenAI and MCP implementations. The split matters when you pick a path: the server package is the thing you point an MCP client at, while the toolkit is the thing you import when you are writing the agent yourself. The repository is written in TypeScript and licensed MIT, and the README's badge line gives Node.js v20+ as the runtime floor for the local route.

The stated goal is to let agents operate inside real workflows rather than in a sandbox: secure access to structured data, tools that take action, and context for decisions. That framing is broad, but the concrete scope is narrower. Everything here talks to monday.com. Boards, items, status columns, updates and the rest of the work OS are the data model. If your agent needs to read or change records in some other system, this repository is not the layer for it.

Hosted Endpoint Versus Running the Server Yourself

The README is explicit that the hosted service is the recommended route, calling it the fastest and most reliable way to connect, with no local installation, automatic updates, OAuth authentication, workspace controls that limit access to specific workspaces, and what it describes as enterprise-grade uptime. Setup for Cursor is a single JSON block pointing at https://mcp.monday.com/mcp with no command and no environment variables. Nothing runs on your machine and no token is pasted into a config file.

The local route is the same protocol served by a process you control. The README lists four reasons to take it: customizing the server source, building custom agents with the toolkit, working offline, and contributing to development. Read that list carefully, because "work offline" is the weakest of the four. The local server removes the dependency on monday.com's MCP hosting, but every tool call still reaches the monday.com API over the network with your personal access token. Offline here means developing without the hosted MCP service, not operating without connectivity.

The trade is therefore not hosted versus self-contained. It is managed OAuth and workspace scoping on one side, against source-level control and a personal token on the other. Teams that need to patch tool behaviour, pin a version, or run inside a network that cannot reach a third-party MCP endpoint should take the local path and accept the token handling that comes with it.

Getting a Token and Wiring the Local Server

The README's local installation guide has three steps. Create a monday.com account if you do not have one. Generate an API token by opening your avatar in the bottom-left corner, choosing Developers, then My access tokens in the left menu, and copying the personal access token. Then configure the MCP client.

For Claude Desktop the documented configuration adds a server entry named monday-api-mcp whose command is npx with a single argument, @mondaydotcomorg/monday-api-mcp@latest, and an env block containing MONDAY_TOKEN set to your token. The @latest tag means each launch resolves the newest published version, which is convenient during evaluation and a liability if you want reproducible behaviour across a team. Pin an explicit version in that args array if you care about drift.

Gemini CLI gets its own path. The README points at an official Gemini CLI extension for monday.com that bundles the MCP server with a context file and custom commands, installed with gemini extensions install https://github.com/mondaycom/mcp. If you would rather skip the extension, the documented alternative is gemini mcp add -t http monday https://mcp.monday.com/mcp, which registers the hosted HTTP endpoint directly. Note the asymmetry: the extension installs from the GitHub repository, while the manual command targets the hosted service. These are two different backends behind one product name, and the README does not spell out how the extension's bundled server relates to the hosted one.

What the Hosted Service Does Not Document Here

Workspace controls are listed as a hosted feature, and the phrase is doing a lot of work. The README does not say how a workspace restriction is configured, whether it is set in the monday.com admin interface or during OAuth consent, or what happens to a tool call that targets a board outside the permitted scope. For an administrator deciding whether to approve the integration, that is the question that matters most and the README leaves it open. The linked support articles may cover it; the repository text does not.

Authentication granularity has the same gap. Hosted uses OAuth, local uses a personal access token. A personal token in the local configuration carries the permissions of the user who created it, and the README's setup steps do not describe scoping that token down or rotating it. Anyone running the local server should treat MONDAY_TOKEN as a credential with the creating user's reach, and store it accordingly rather than committing it into a shared MCP settings file.

There is also a versioning question the material cannot answer. No releases were retrieved for this repository, so there is no changelog to check for breaking changes to tool names or arguments. The README's @latest example implies the package moves, but the rate and the compatibility policy are not visible from what is here.

Where This Is the Wrong Tool

If your agent needs to reason over data that is not in monday.com, this repository adds a hop without adding capability. The server exposes monday.com's API surface; it is not a general integration layer, and the agent toolkit's value depends on the target API being monday.com. A team that wants one MCP server fronting several SaaS systems will end up running several servers, and this is one of them.

A second wrong fit is the offline requirement taken literally. The README lists working offline as a reason to run locally, but the local server's tool calls are API calls. Air-gapped environments cannot use either path, hosted or local, because both terminate at monday.com.

Third, the hosted route is the wrong choice when your MCP client expects a stdio server. The hosted configuration is a url entry with no command, which is a different transport from the npx-based local configuration. The Gemini CLI example shows the same distinction, with -t http for the hosted endpoint. Clients that only speak stdio need the local package, regardless of which path the README recommends.

Alternatives and the Actual Difference in Approach

The obvious alternative is to skip MCP and call the monday.com API directly from your own code using the agent toolkit package, which the README says supports OpenAI as well as MCP. The difference is who owns the tool schema. With an MCP server, the tool definitions live in the server and your agent discovers them at runtime through the protocol, so adding or changing a tool is a server-side change. With the toolkit, you write the function definitions and the call handling in your own application, which means more code but full control over naming, argument validation and error surfaces.

A second alternative, for teams already standardized on one assistant vendor, is the vendor's own integration path. The README links separate setup guides for Claude, Cursor, ChatGPT, MS Copilot Studio and Mistral's le Chat. Those guides all point at the same monday.com MCP service, so the choice is not between competing monday.com integrations. It is between using the MCP endpoint and writing direct API calls. The MCP route buys you a shared tool surface across clients; the direct route buys you a smaller dependency graph. Neither is universally better, and the README's own list of reasons to use the repository (customize, build custom agents, contribute) is essentially a list of reasons the direct or forked route exists.

Maintenance Cost and Licence Position

The repository is MIT-licensed, which permits modification and redistribution with the licence and copyright notice retained. That is the permissive end of the spectrum and it is consistent with the README's invitation to modify the server source and contribute. It is not legal advice, and anyone embedding the package in a commercial product should read the LICENSE file at the repository root rather than the badge.

Maintenance cost splits along the same hosted/local line. Hosted shifts the update burden to monday.com and the README promises automatic updates, which is real operational savings but leaves you with no version to pin and no release notes in this repository to read before a behaviour change lands. Local gives you a pinnable dependency, at the cost of tracking upstream changes yourself and re-testing your MCP client configuration when you bump the version. The last push to the default branch is dated 2026-09-10, so the project is active, but with no releases retrieved there is no published changelog to plan upgrades against.

The practical rule: choose hosted unless you have a specific reason from the README's four-item list, and if you choose local, replace @latest in the args array with an explicit version so that a routine npx cache miss does not silently change the server your agent is talking to.

Editorial conclusion

Adopt the hosted endpoint at https://mcp.monday.com/mcp if you want monday.com boards reachable from Claude, Cursor, ChatGPT, Copilot Studio or Mistral with OAuth and no local process. Do not adopt this repository if you need a self-contained deployment with no outbound dependency on monday.com infrastructure, because the local server still calls the same monday.com API with a personal token. Verify first that your client supports the MCP transport you intend to use, and that a personal access token from Developers > My access tokens is acceptable for your workspace's data.

Official sources

1. Issues
2. License: MIT
3. mondaycom/mcp on GitHub
4. Project website
5. README