A personal API token or an OAuth app is enough for personal use, internal tools, and testing. To let other monday.com accounts connect your MCP client — as a product feature, a custom integration, or a partner integration — register it with a Client ID Metadata Document (CIMD) or through dynamic client registration (DCR).

Any developer can use this path. Customers add your connection through dynamic connectors: their account admin approves the connection and its redirect URIs before the connection is created.

The hosted MCP permission enables a separate set of pre-approved third-party agents, including Claude, ChatGPT, and the other compatible MCP clients. Those agents use the standard authorization screen.

Step 1: Register your client

Publicly available MCP clients don't use a pre-created monday.com app. The MCP authorization specification defines two ways for a client to identify itself, and monday.com supports both. After registration, the client runs the standard authorization code + PKCE flow.

Option A: Client ID Metadata Document (CIMD) (recommended)

monday.com supports Client ID Metadata Documents as defined in the MCP authorization specification, which recommends them over DCR. Your client_id is the HTTPS URL of a metadata document you host, so there is no registration call. monday.com advertises support with client_id_metadata_document_supported: true in its authorization server metadata.

monday.com accepts only public clients: the document must support the none token endpoint auth method (in token_endpoint_auth_methods_supported if the document lists it) and contain no secret, and the client must use PKCE with S256. The client_id URL must use the default HTTPS port and have no query string.

Option B: Dynamic client registration (DCR)

With OAuth 2.0 Dynamic Client Registration, the client registers itself with the MCP server's registration endpoint and receives a client_id.

Discovery

The server publishes its OAuth metadata through standard discovery documents, so MCP-compliant clients handle registration and authorization automatically:

If you're building on an MCP SDK or framework that follows the MCP authorization specification, no additional OAuth setup is required — point your client at https://mcp.monday.com/mcp and the discovery, registration, and authorization flow happens automatically.

Step 2: User authorization (OAuth consent)

When a user connects your MCP client to monday.com, your client opens the monday.com OAuth authorization screen.

Whether you use CIMD or DCR, for an additional connection the screen shows Admin approval required instead of completing the connection. The user requests approval, and an account admin approves the connector and its redirect URIs for that account. Nothing is connected while the request is pending. After approval, the user starts the connection again and selects Authorize. Follow Dynamic connectors for the approval steps, admin review, and early-access limitations.

When the user is connecting a pre-approved third-party agent, or an admin has already approved the connector, the user reviews the connection and clicks Authorize to grant access.

The consent screen shows your client name, a short description of the connection, and that the client inherits the user's existing monday.com permissions.

After the user authorizes:

1. monday.com redirects back to your client with an authorization code
2. Your client exchanges the code for an access token (and refresh token, if issued) via the token endpoint
3. Your client includes the access token in the Authorization header of subsequent MCP requests:

Authorization: Bearer YOUR_ACCESS_TOKEN

All MCP tool calls then run as that user, scoped to their monday.com permissions and any MCP access limits set by the account admin — for example, restricting MCP to specific workspaces only.

Related resources:

• Dynamic connectors
• Integrate with the monday MCP server
• Authenticate with an API token
• Control MCP access with your own OAuth app
• Compatible MCP clients
• MCP security overview
• OAuth documentation