Your agent needs to read boards and write items in monday.com. monday ships a hosted Platform MCP server and a GraphQL Platform API, and the obvious assumption is that the MCP is a convenient subset of the API. That assumption is wrong in both directions: the MCP exposes automation and workflow tools the public GraphQL API does not, and it ships a tool that executes arbitrary GraphQL. Meanwhile the auth model has a property most teams discover in production rather than in the docs. Here is how to pick.
Two objects are being compared, and monday actually ships three things that answer to the name "MCP." Getting the naming straight first saves a wasted afternoon.
The Platform MCP is an open-source server maintained by monday's AI team and offered as a hosted endpoint at https://mcp.monday.com/mcp. It is preinstalled on all monday.com accounts and available on every plan at no additional cost.
monday's own MCP security overview is direct about what it is: a wrapper around the Platform API. Every capability is backed by the same GraphQL endpoint, and authentication, authorization, rate limits, and data handling follow the same platform standards.
The Platform API is a single GraphQL endpoint at https://api.monday.com/v2 covering boards, items, columns, groups, docs, users, teams, workspaces, webhooks, assets, activity logs, and bulk import.
It authenticates with either a personal API token or an OAuth app token, passed in the Authorization header. There are no LLM-specific affordances: schema handling, pagination, error semantics, and rate-limit backoff are yours.
monday also ships an Apps MCP, enabled with --mode apps, for managing app versions, features, deployments, and environment variables. It does not touch boards or items. If you are building an agent that works with monday data, it is not the server you want.
The template for this series calls for a capability table. For monday a table alone misleads, because the gap is bidirectional and one tool collapses most of it. Both directions are worth naming precisely.
monday's Platform MCP tools reference documents 49 tools across boards and items, workspaces, docs, dashboards and widgets, forms, users and teams, updates and notifications, search and assets, AI agents, meetings, monday-dev sprints, low-level API access, and UI components.
Treat that number as a snapshot, not a constant. The documentation sidebar already enumerates tools the body tables have not absorbed, including view management, asset upload, automation, and workflow tools. The surface is moving.
This is the direction almost nobody expects. monday's API coverage gaps page states that the API does not currently expose mutations to create, delete, update, or list board automations, and that automations can only be managed through the UI.
The MCP tool reference lists create_automation, list_automations, and manage_automations, alongside workflow tools such as plan_workflow, create_workflow, and publish_workflow, and platform agent tools including manage_agent and agent_catalog. If your agent's job includes configuring monday automations, the MCP is currently the documented path and the API is not.
Event subscriptions are the clearest case. Webhooks are created and deleted through GraphQL mutations gated on webhooks:read and webhooks:write, covering 21 board event types with a retry policy of once a minute for 30 minutes. No webhook tool appears in the 49.
High-volume ingestion is the second. The API reference now carries a Bulk Import surface with ingest_items and backfill_items. There is no MCP equivalent, and looping create_item through tool calls is not a substitute once you understand the daily call limit.
Read this as a summary of the two subsections above, not as the argument itself.
The MCP ships all_monday_api, documented as executing any GraphQL query or mutation, paired with get_graphql_schema and get_type_details so a model can introspect the schema before composing a call. Anything reachable by GraphQL is therefore reachable through the MCP.
That closes the capability gap and opens a different one. A curated tool has a fixed input schema you can validate and log against. all_monday_api has one meaningful parameter: a GraphQL string the model wrote. For an interactive assistant that is a feature. For a pipeline where an unexpected mutation is an incident, it is the thing to disable.
Both paths run on the same monday identity model, and the auth choice is closer to orthogonal to the MCP versus API choice than most comparisons suggest. One property of that model matters more than everything else here.
monday documents the hosted MCP as using the OAuth 2.0 Authorization Code Grant with monday as the identity provider, with every tool call executing in the authenticated user's context and subject to that user's permissions. The endpoint supports Dynamic Client Registration and PKCE, which is how a client can register without a preconfigured client ID and secret.
The hosted endpoint also accepts a token directly in an Authorization header, and the local server authenticates with a personal API token and no OAuth at all. "MCP means OAuth" is a convenient simplification that does not survive contact with the configuration examples.
OAuth app tokens are scoped, drawing from 21 permission scopes spanning boards, docs, updates, users, teams, workspaces, webhooks, and more. You request only what the agent needs.
Personal API tokens are not scoped. monday's authentication doc states that app tokens have permission scopes "while personal tokens have all permission scopes." A personal token mirrors everything that user can do in the UI, with no way to narrow it. That applies equally to the local MCP server, where the only available constraint is a --read-only flag that the hosted server does not offer.
Most agent auth writing, including ours, tells you to refresh proactively rather than waiting for a 401. For monday, that advice does not apply. The OAuth documentation states that access tokens "do not expire and are valid until the user uninstalls your app" and that the flow "does not support refresh tokens."
There is no expires_in to schedule against, no refresh rotation, and no natural expiry checkpoint. What you hold instead is a long-lived bearer credential whose only documented end state is the user uninstalling your app.
For a B2B agent serving 60 users across 12 monday accounts, that is 60 non-expiring credentials, each carrying whatever the authorizing user could do. Nothing ages them out. Nothing forces reauthorization. An engineer who left eight months ago still has a working token unless something in your system explicitly kills it.
This is the offboarding failure pattern, not the refresh failure pattern. Revocation has to be an event your infrastructure fires, because monday will not fire it for you. This is exactly the scenario covered in when an employee leaves and who revokes their AI agent's access.
Both paths inherit the same platform limits, because the MCP executes as GraphQL underneath. These are the numbers that decide whether your agent survives its first real week.
The rate limits page sets the daily call limit at 1,000 for Free, Standard, and Basic plans, 10,000 as a soft limit on Pro, and 25,000 as a soft limit on Enterprise, resetting at midnight UTC.
monday states explicitly that hosted MCP tool calls count toward that limit, since each tool call executes as a GraphQL request. An agentic turn that discovers a board, reads its schema, pages items, and writes a status is four calls before anything useful happens. On a Standard plan, a few dozen users doing that a few times a day exhausts the account.
GraphQL lets you compose several operations into a single request, and a request typically deducts one call. Tool granularity gives you no such option: one tool call is one request.
Do not treat that as a free win. The same page lists high complexity queries as contributing one or more calls, so a heavily batched request can cost more than one. Complexity itself is capped at 5 million points per individual query, with a combined per-minute budget of 10 million for personal tokens, 5 million each for reads and writes with app tokens, and 1 million for trial, NGO, and free accounts.
Per-minute request limits run 5,000 on Enterprise, 2,500 on Pro, and 1,000 elsewhere. Concurrency caps at 250, 100, and 40 respectively. A single IP address is capped at 5,000 requests per 10 seconds.
Responses carry IETF-format RateLimit-Policy and RateLimit headers reporting remaining quota and reset time. Throttle on the remaining value rather than reacting to errors, because failed requests still count against your limits.
monday guarantees at least three parallel API versions, ships a new one quarterly, and keeps any version stable for at least six months. As of this writing 2026-04 is current, 2026-01 is in maintenance, and 2026-07 is the release candidate. You pin with the API-Version header.
The same header works in a hosted MCP client configuration. What neither header pins is the MCP tool surface itself. Tool schemas change when monday ships new tools, and you consume that contract without controlling its cadence. That is the narrow, real versioning distinction, and it is the one that matters for deterministic pipelines.
monday's MCP security page states that self-service export of detailed MCP or API audit logs is not currently available, and directs organizations with compliance requirements to their monday representative. monday maintains internal logging for its own operational security.
For an agent that writes to customer boards on behalf of named users, that leaves the per-call, per-user record on your side of the line. The same page assigns secure token storage, refresh handling, and revocation to the customer, and states that the MCP server does not store or log customer OAuth tokens. Building audit trails for agent auth in B2B SaaS is therefore a customer responsibility, not a platform guarantee.
Both lists below are specific to monday. Neither is generic MCP advice.
Scalekit ships both paths as connectors on the same credential layer, which means the decision above does not propagate into your auth code. Both are listed in the agent connectors directory.
The monday.com connector covers the API path with 44 prebuilt tools, including monday_webhook_create and monday_webhooks_list, which the Platform MCP does not expose. It uses OAuth 2.0 with credentials from the monday Developer Center.
The Monday MCP connector covers the MCP path. Because the hosted endpoint supports Dynamic Client Registration, there is no OAuth app to register and no client ID or secret to paste. Scalekit negotiates the client with https://mcp.monday.com/mcp on first authorization, then stores and refreshes tokens per user.
One prerequisite applies to every snippet below: the connection_name string must match the connection name configured in your Scalekit dashboard exactly. This is the most common integration error in the entire setup.
Scalekit returns native LangChain StructuredTool objects, so the agent loop carries no Scalekit-specific logic beyond initialization. For a deeper look at how LangChain tool calling works and where it stops, see the dedicated guide.
With the connected account active, retrieve the tools this user's account authorizes and run the loop.
A direct call, without a framework, uses execute_tool with the exact tool name from the connector's tool list.
The MCP connector works the same way, with mondaymcp_ tool names. Scoping the surface before the model sees it is the point of listScopedTools.
The tool result comes back through executeTool, which resolves the user's monday credential server-side. The credential never enters the model context.
Method signatures across SDK versions are documented in the Node.js and Python SDK references.
The three tool names in that filter are the point. Handing a model the full monday surface, whether 44 connector tools or 49 MCP tools, is an accuracy problem before it is a security problem: LLMs select poorly from large tool sets, producing wrong selections, hallucinated parameters, and redundant sequential calls.
It is also a cost problem. As explored in the analysis of why MCP can be significantly more expensive than CLI, roughly 200 tokens per tool means about 8,000 tokens burned before the agent does any work. Scoping to five or ten tools cuts that overhead by around 80 percent. The fix is not better prompting. It is surface reduction.
Most production monday agents are not monday-only. They read a board, check a Slack thread, and file a ticket. That is where a scoped, per-user MCP endpoint earns its place.
A standard MCP server exposes every tool it has. Virtual MCP Servers invert that: you declare which connections and which tools an agent role can see, and you get a static mcp_server_url.
Two objects drive the model. The virtual MCP server is created once per agent role. The session token is minted before each run, short-lived and bound to one specific user's connected accounts. The endpoint is static; the identity is not.
Generate the per-user URL on your backend, then hand it to the agent.
Never share one URL across users. Each is pre-authenticated for a single user, so a process-wide value runs every request as that user.
Because monday tokens do not expire, tool-level least privilege is the main lever you have. A sprint reporting agent that only ever needs getboardinfo and getboarditemspage should not be able to reach createautomation or allmondayapi, and a declared allowlist is how you guarantee that rather than hope for it.
The daily call limit reinforces the same choice. A narrower tool surface produces fewer speculative calls, and fewer speculative calls is directly fewer of your 1,000 or 10,000 daily requests. This principle applies across any single-tenant to multi-tenant tool calling transition.
Both paths give you a token per user. Neither gives you a vault, a revocation flow, or a queryable record of what the agent did. That infrastructure is yours regardless of which path you chose.
A shared personal token looks fine in a demo. In production it carries every scope its owner has, appears in audit trails as one person, and never expires. A per-user OAuth token fixes attribution and scope but keeps the expiry property: nothing ages it out.
When a user leaves, disabling their identity provider account does not invalidate a monday token issued eight months ago. The agent does not decide to keep using it. It just does. Revocation has to be an event your system fires on offboarding, tied to the connected account. Understanding who holds the token across agent tool-calling patterns is essential to designing that revocation flow correctly.
monday documents that self-service export of detailed MCP or API audit logs is not currently available. If your security reviewer asks which user authorized the tool call that moved 40 items last Tuesday, the answer has to come from your side.
Scalekit resolves the per-user credential on every tool call and logs it, so downstream tool calls carry the identity of the human who authorized them rather than a service account, with 90 days of queryable history. Credentials are resolved at request time and never enter the agent runtime or the model context.
Scalekit's monday.com and Monday MCP connectors handle the OAuth flow, per-user token storage, and revocation for both paths, so the MCP versus API decision does not change your auth infrastructure.
If your agent is interactive, user-present, and mostly reading and summarizing monday data, start with the Platform MCP. It is the only documented path to automation and workflow management, the permission model is already per-user, and you write no GraphQL.
If your agent is event-driven, ingests at volume, or runs as a deterministic pipeline where a model composing GraphQL is unacceptable, build against the Platform API directly. Webhooks and bulk import exist only there, and batching is the only real lever you have against the daily call limit.
Most production monday agents will use both: the assistant on MCP, the pipeline on the API. The credential problem is identical either way, and non-expiring tokens make it more urgent here than on most platforms. That is the part that needs production-grade infrastructure. For a broader look at secure token management for AI agents at scale, the pattern applies directly here.
Building agents on monday.com and want to compare notes on tool scoping, call limits, or revocation? Join the Scalekit Slack community, or talk to an engineer if you need help now.
Browse the Scalekit monday.com connector or read the connector docs.
