The Calendly MCP server enables AI-powered apps and developers to securely connect to Calendly using the Model Context Protocol (MCP). It translates natural-language commands (e.g., “Book a 30-minute meeting with Sam next Tuesday”) into structured Calendly API calls with no need to implement raw REST requests.

The server is fully hosted by Calendly at https://mcp.calendly.com. Self-hosting or local deployment is not supported.

Before you build — check client compatibility. Calendly MCP uses DCR (RFC 7591), so clients self-register to obtain a client_id at runtime. If your MCP client prompts you to paste in a client_id and client_secret from a developer console, it does not support DCR and will not work with Calendly MCP today.

Key benefits

• Secure, standards-based OAuth 2.1 authentication
• Full coverage of Calendly’s scheduling capabilities
• Compatible with any MCP-compliant client or agent framework
• Same scopes and permissions as Calendly’s public API

Authentication model

Calendly MCP uses Dynamic Client Registration (DCR), which means you do not need to pre-register an OAuth application or put any OAuth secrets into your MCP client configuration. After setting the server URL, the client and server navigate the auth flow automatically.

Once Calendly MCP is connected to a client, it generates an OAuth application for the session. A browser window opens for the user to grant access to their Calendly account. After pressing “Connect to Calendly” on the consent screen, the scheduling tools are available immediately.

For developers building custom MCP clients, the full DCR walkthrough is in Section 3.

At a high level:

1. The MCP endpoint is an OAuth-protected resource.
2. An unauthenticated request returns 401 with a link to the OAuth resource metadata.
3. The client fetches that metadata to discover the authorization server and required scopes.
4. The client fetches authorization server metadata to find the token, auth, and registration_endpoint.
5. The client calls registration_endpoint (DCR) to self-register and receive a client_id.
6. The client runs the Authorization Code + PKCE flow to obtain an access token.
7. The client sends the access token on all subsequent MCP calls.

Integration walkthrough

This section is for developers building their own MCP clients. If you’re new to building MCP clients, see Build an MCP client and Connect to remote MCP servers in the MCP docs.

The steps below focus on:

1. Initial handshake between your MCP client and the Calendly MCP server.
2. Discovery of the Calendly MCP protected resource.
3. Discovery of the Calendly authorization server.
4. Registration of your MCP client via DCR.

Step 0: Initial handshake

When your MCP client first tries to call the Calendly MCP server without a token, the server responds with 401 Unauthorized and tells the client where to find the protected resource metadata document, as defined in RFC 9728.

1
HTTP/1.1 401 Unauthorized
2
WWW-Authenticate: Bearer realm="mcp",
3
4
resource_metadata="https://mcp.calendly.com/.well-known/oauth-protected-resource"

This tells the client that authorization is required for the Calendly MCP server and where to get the metadata needed to kick off the discovery and DCR flow.

Step 1: Discover the Calendly MCP protected resource

Your MCP client (or the MCP framework you’re using) should first discover the MCP server’s protected resource metadata.

Request

1
GET https://mcp.calendly.com/.well-known/oauth-protected-resource
2
Accept: application/json

Successful response (example)

1
{
2
  "resource": "https://mcp.calendly.com/",
3
  "authorization_servers": ["https://calendly.com/"],
4
  "scopes_supported": [
5
    "mcp:scheduling:read",
6
    "mcp:scheduling:write"
7
  ],
8
  "bearer_methods_supported": ["header"]
9
}

Key points:

• resource is the identifier your client should use when requesting tokens for the MCP server.
• authorization_servers tells you which OAuth authorization server(s) to talk to (for Calendly MCP, this is https://calendly.com/).
• scopes_supported lists the only scopes currently issued for MCP. Calendly MCP requires both for full access.
  • mcp:scheduling:read
  • mcp:scheduling:write

Your DCR and later OAuth requests should treat this document as the source of truth for the MCP resource and scopes.

Step 2: Discover the Calendly authorization server

Next, discover the Calendly OAuth authorization server metadata. This tells you where to send DCR, authorization, and token requests.

Request

1
GET https://calendly.com/.well-known/oauth-authorization-server
2
Accept: application/json

Successful response (example)

1
{
2
  "issuer": "https://calendly.com/",
3
  "authorization_endpoint": "https://calendly.com/oauth/authorize",
4
  "token_endpoint": "https://calendly.com/oauth/token",
5
  "registration_endpoint": "https://calendly.com/oauth/register"
6
}

Key field for DCR: registration_endpoint – this is the URL you will call to dynamically register your MCP client.

Step 3: Register your MCP client via DCR

With the registration_endpoint discovered, your MCP client can register itself dynamically.

Endpoint: POST https://calendly.com/oauth/register Authentication: For MCP, a registration token is not required, however the endpoint is heavily validated and rate‑limited. Content type: application/json

3.1 Minimal valid registration request

This is the minimal JSON body your MCP client should send to register:

1
POST https://calendly.com/oauth/register
2
Content-Type: application/json

1
{
2
  "client_name": "My MCP Client",
3
  "redirect_uris": [
4
    "https://myapp.example.com/mcp/callback"
5
  ],
6
  "grant_types": ["authorization_code"],
7
  "response_types": ["code"],
8
  "token_endpoint_auth_method": "none"
9
}

Field notes

client_name — Human‑readable label shown on Calendly’s consent screen. Should clearly identify your MCP client or product.

redirect_uris — Array of one or more redirect URIs. For production:

• Must be HTTPS.
• Must be exact URIs (no wildcards like https://*.example.com/...).
• Must not contain multiple schemes in a single URI (e.g., https://http://...).
• Must not contain userinfo (e.g., https://user@evil.example/...).
• Leading/trailing spaces are rejected.
• For local development, http://localhost/... or http://127.0.0.1/... may be allowed per environment policy.

grant_types — For MCP, use: [ "authorization_code" ]. Include "refresh_token" if your client will use refresh tokens.

response_types — MCP only supports the authorization code with PKCE flow: [ "code" ] is required.

token_endpoint_auth_method — For MCP DCR, Calendly treats clients as public and requires: "none". That implies:

• No client_secret is used at the token endpoint.
• PKCE is required to protect the authorization code.

Scopes — Calendly MCP currently issues:

• mcp:scheduling:read
• mcp:scheduling:write

These are configured server‑side for MCP DCR clients. You do not need to include scope/scopes in the registration request. The server will attach the MCP scopes for you.

3.2 Successful registration response

On success, you’ll receive a JSON document describing your new client:

1
{
2
  "client_id": "auto-generated-client-id",
3
  "client_name": "My MCP Client",
4
  "redirect_uris": [
5
    "https://myapp.example.com/mcp/callback"
6
  ],
7
  "scopes": [
8
    "mcp:scheduling:read",
9
    "mcp:scheduling:write"
10
  ],
11
  "grant_types": [
12
    "authorization_code"
13
  ],
14
  "response_types": [
15
    "code"
16
  ],
17
  "token_endpoint_auth_method": "none"
18
}

Important points:

client_id — Opaque identifier your MCP client must use in all later OAuth interactions. Treat it as a stable, long‑lived identifier.

client_secret — For MCP DCR, no client secret is issued (public client). Your MCP client must rely on PKCE and token_endpoint_auth_method: "none".

scopes — Confirms the scopes assigned to this client. For MCP, expect ["mcp:scheduling:read", "mcp:scheduling:write"].

Store at least:

• client_id
• redirect_uris
• Any metadata your MCP framework expects for subsequent authorization and token requests.

3.3 Error responses and validation behavior

If the registration request is invalid, the endpoint returns an error:

1
{
2
  "error": "invalid_client_metadata",
3
  "errors": {
4
    "redirect_uri": [
5
      "must start with https in Production."
6
    ]
7
  }
8
}

Other examples you might encounter:

Invalid scopes:

1
{
2
  "error": "invalid_client_metadata",
3
  "errors": {
4
    "scopes": {
5
      "0": [
6
        "must be one of: mcp:scheduling:read, mcp:scheduling:write"
7
      ]
8
    }
9
  }
10
}

Wildcard or malformed redirect URIs, multiple schemes, or leading spaces:

1
{
2
  "error": "invalid_client_metadata",
3
  "errors": {
4
    "redirect_uri": [
5
      "must be an exact https URI without wildcards or user info."
6
    ]
7
  }
8
}

When you receive invalid_client_metadata:

1. Inspect the errors object to see which field(s) failed validation.
2. Correct the JSON body (e.g., fix redirect_uris, adjust scopes, remove wildcards).
3. Retry the POST /oauth/register request.

With these steps, your custom MCP client can perform standards‑based Dynamic Client Registration against Calendly’s authorization server, using only:

Discovery URLs:

• https://mcp.calendly.com/.well-known/oauth-protected-resource
• https://calendly.com/.well-known/oauth-authorization-server

DCR endpoint: https://calendly.com/oauth/register

Once registered, you can proceed with the standard OAuth 2.1 authorization code + PKCE flow using the discovered authorization_endpoint and token_endpoint, and the client_id returned from DCR.

Supported tools

The Calendly MCP server exposes tools mapped to Calendly’s public API v2. Each tool includes annotation metadata — a human-readable title and hints (readOnlyHint, destructiveHint, idempotentHint) — to enhance the user experience and optimize repeated calls. See the full list of Calendly MCP server tools.

Example prompts