Which integrations are available for this server?

Provides tools for managing Calendly events, including viewing upcoming events, checking availability, searching events, creating one-off scheduling links, canceling and rescheduling events, and retrieving scheduling analytics.

How do I use Calendly MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Calendly MCP Server What meetings do I have this week?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Calendly MCP Server

by NyxToolsDev

Overview Schema Related Servers Score Discussions

Python

Remote

Calendly MCP Server

An MCP (Model Context Protocol) server that connects Claude Desktop and Claude Code to your Calendly account, enabling natural-language scheduling management.

Installation

pip install calendly-mcp

Related MCP server: leximo-ai-call-assistant-mcp-server

Getting a Calendly Personal Access Token

Log in to Calendly
Go to Settings > Integrations & Apps
Scroll to API & Connectors and click API
Click Get a token now (or Generate New Token)
Give the token a name (e.g., "Claude MCP") and click Create Token
Copy the token immediately -- it will not be shown again

Configuration

Claude Desktop

Add the following to your claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "calendly": {
      "command": "calendly-mcp",
      "env": {
        "CALENDLY_ACCESS_TOKEN": "your-token-here",
        "LICENSE_KEY": "optional-premium-key"
      }
    }
  }
}

Claude Code

Set the environment variable before starting Claude Code:

export CALENDLY_ACCESS_TOKEN="your-token-here"
export LICENSE_KEY="optional-premium-key"   # only if you have a premium license

Then add the MCP server:

claude mcp add calendly -- calendly-mcp

Or add it to your project's .mcp.json:

{
  "mcpServers": {
    "calendly": {
      "command": "calendly-mcp",
      "env": {
        "CALENDLY_ACCESS_TOKEN": "your-token-here"
      }
    }
  }
}

Environment Variables

Variable	Required	Description
`CALENDLY_ACCESS_TOKEN`	Yes	Calendly Personal Access Token or OAuth2 token
`LICENSE_KEY`	No	Lemon Squeezy premium license key
`LOG_LEVEL`	No	Logging level: `DEBUG`, `INFO`, `WARNING`, `ERROR` (default: `INFO`)
`CALENDLY_BASE_URL`	No	Override the Calendly API base URL (for testing)

Tools

Free Tier (7 tools)

Tool	Description	Required Parameters
`list_upcoming_events`	List upcoming scheduled events with optional filters	None (optional: `count`, `min_start_time`, `max_start_time`, `status`)
`get_event_details`	Get full details of a specific event including invitees and location	`event_uuid`
`search_events`	Search events by invitee name or email (case-insensitive partial match)	`query` (optional: `min_start_time`, `max_start_time`)
`check_availability`	Check available time slots from your availability schedules	`date_range_start`, `date_range_end`
`get_busy_times`	Get busy/unavailable time periods for a date range	`start_time`, `end_time`
`list_event_types`	List all configured event types with name, duration, and status	None
`get_event_type_details`	Get detailed configuration of a specific event type	`event_type_uuid`

Premium Tier (5 additional tools)

Tool	Description	Required Parameters
`create_one_off_event`	Create a single-use scheduling link for a meeting	`event_type_uuid`, `invitee_email`, `invitee_name`, `start_time`
`cancel_event`	Cancel an existing scheduled event (invitees are notified)	`event_uuid` (optional: `reason`)
`reschedule_event`	Reschedule an event to a new time	`event_uuid`, `new_start_time`
`get_scheduling_stats`	Get scheduling analytics: total meetings, avg duration, popular times	`min_start_time`, `max_start_time`
`get_invitee_insights`	Analyze meeting patterns with a specific contact	`invitee_email`

Free vs Premium

Feature	Free	Premium
View upcoming events	Yes	Yes
Get event details	Yes	Yes
Search events by invitee	Yes	Yes
Check availability	Yes	Yes
View busy times	Yes	Yes
List event types	Yes	Yes
Get event type details	Yes	Yes
Create scheduling links	--	Yes
Cancel events	--	Yes
Reschedule events	--	Yes
Scheduling analytics	--	Yes
Invitee insights	--	Yes
Price	Free	$12/month

Upgrade at nyxtools.lemonsqueezy.com/checkout

Usage Examples

Once connected, talk to Claude naturally:

Viewing Your Schedule

"What meetings do I have this week?"
"Show me my schedule for tomorrow"
"List my next 5 meetings"
"What canceled meetings did I have this month?"

Event Details

"Tell me more about my 3pm meeting"
"Who's invited to the design review?"
"What's the Zoom link for my next call?"

Searching Events

"Do I have any meetings with john@example.com?"
"Find all meetings with Sarah"
"When did I last meet with the Acme team?"

Checking Availability

"Am I free Thursday afternoon?"
"What does my availability look like next week?"
"What times am I busy tomorrow?"

Event Types

"What event types do I have set up?"
"Show me the details of my 30-minute meeting type"

Scheduling (Premium)

"Schedule a 30-minute call with john@example.com for Tuesday at 2pm"
"Set up a meeting with Jane Smith next Wednesday"

Canceling and Rescheduling (Premium)

"Cancel my 3pm meeting tomorrow"
"Cancel the call with John -- I have a conflict"
"Move my 2pm meeting to Thursday at 4pm"
"Reschedule the call with Sarah to next Monday morning"

Analytics (Premium)

"How many meetings did I have this month?"
"What's my average meeting length?"
"How much time have I spent in meetings with John?"

Development

Setup

git clone https://github.com/nyxtools/calendly-mcp-server.git
cd calendly-mcp-server
python -m venv venv
source venv/bin/activate   # or venv\Scripts\activate on Windows
pip install -e ".[dev]"

Running Tests

pytest
pytest --cov=calendly_mcp    # with coverage

Linting

ruff check src/ tests/
ruff format src/ tests/
mypy src/

Troubleshooting

"CALENDLY_ACCESS_TOKEN is required"

You have not set the CALENDLY_ACCESS_TOKEN environment variable. Make sure it is configured in your claude_desktop_config.json (under env) or exported in your shell before running Claude Code.

401 Unauthorized errors

Your Calendly Personal Access Token is invalid or has been revoked. Generate a new token at Settings > Integrations & Apps > API in Calendly and update your configuration.

429 Rate limit errors

The Calendly API enforces rate limits. The MCP server automatically retries with exponential backoff, but if you see persistent rate limit errors, reduce the frequency of requests or wait a few minutes.

Connection errors

Verify you have internet connectivity
Check that api.calendly.com is reachable from your network
If behind a proxy, ensure httpx can reach the Calendly API

Premium tools not appearing

Verify your LICENSE_KEY is set correctly in the environment
Check the server logs for license validation errors (LOG_LEVEL=DEBUG)
Ensure your premium subscription is active at nyxtools.lemonsqueezy.com

Server not starting in Claude Desktop

Verify the command path is correct (calendly-mcp must be on your PATH)
Try running calendly-mcp directly in a terminal to check for errors
On Windows, you may need to use the full path to the executable

License

MIT -- see LICENSE for details.

Available Tools

7 tools

check_availabilityC

Check available time slots from your Calendly availability schedules and show busy periods for a date range.

ParametersJSON Schema

Name	Required	Description	Default
`date_range_start`	Yes	ISO 8601 start of the date range
`date_range_end`	Yes	ISO 8601 end of the date range

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose any behavioral traits beyond the basic function. It does not mention side effects, authentication needs, or data source.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single, clear sentence that conveys the main function efficiently. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks information about output format, return type, or any behavioral constraints. Given no output schema and no annotations, the description should provide more context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The description adds the context of 'date range' but does not significantly enhance the parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool checks availability and shows busy periods for a date range (specific verb+resource). However, it does not differentiate from the sibling tool 'get_busy_times'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like 'get_busy_times'. The description does not mention any conditions or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_busy_timesB

Get busy/unavailable time periods for a date range. Shows all times when you are not available for meetings.

ParametersJSON Schema

Name	Required	Description	Default
`start_time`	Yes	ISO 8601 start of the date range
`end_time`	Yes	ISO 8601 end of the date range

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states the tool shows unavailable times, which is adequate but lacks details on behavior like response format, empty results, or time zone handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with verb and scope, no redundant words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficient for a simple tool but lacks output schema guidance and detail on busy time interpretation, leaving gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with ISO 8601 descriptions. The description adds no extra meaning beyond the schema, achieving baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Get busy/unavailable time periods' and specifies the resource 'for a date range' and the scope 'all times when you are not available for meetings.' While distinct from sibling tools, it does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like check_availability. The description does not mention use cases, prerequisites, or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_event_detailsA

Get full details of a specific Calendly event including invitees, location, conferencing details, and cancellation info.

ParametersJSON Schema

Name	Required	Description	Default
`event_uuid`	Yes	UUID of the event to retrieve

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions the tool gets details but does not state that it is a read-only operation, potential side effects, authentication needs, or rate limits. The description is minimal and lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the main purpose and lists the types of details included. No wasted words; efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool with one parameter and no output schema, the description adequately covers what the tool returns (invitees, location, etc.). It lacks some context (e.g., whether the response is paginated, format), but overall is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'event_uuid' is documented in the schema with a description. The tool description adds no extra semantic meaning beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves full details of a specific Calendly event, listing key content (invitees, location, conferencing, cancellation info). It distinguishes from siblings like list_upcoming_events or search_events by focusing on a single event with UUID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for a specific event via UUID but offers no explicit guidance on when to use alternatives (e.g., search_events for querying by criteria) or when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_event_type_detailsA

Get detailed configuration of a specific Calendly event type including description, booking URL, custom questions, and visibility.

ParametersJSON Schema

Name	Required	Description	Default
`event_type_uuid`	Yes	UUID of the event type to retrieve

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must convey behavior. It mentions the returned fields but omits details on authentication requirements, rate limits, side effects, or error cases. For a simple read, it is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence that front-loads the key action and result. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple nature (one required parameter, no output schema), the description covers the basics but lacks details on return format, error handling, or operational context. Could be more complete for a richer understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (the only parameter 'event_type_uuid' has a description). The description adds context about the tool's purpose but does not elaborate on parameter usage beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'get' and the resource 'detailed configuration of a specific Calendly event type', listing specific fields (description, booking URL, custom questions, visibility). This differentiates it from siblings like 'list_event_types' and 'get_event_details'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool over alternatives like 'get_event_details' or 'list_event_types'. The description does not specify context or prerequisites for invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_event_typesA

List all configured Calendly event types with name, duration, slug, and availability status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It does not mention authentication, rate limits, side effects, or scope (e.g., user-specific vs organization-wide). A simple list operation is implied, but more context would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the verb and resource, lists the returned fields, and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and no annotations, the description provides the bare minimum: what the tool returns. It lacks details on ordering, pagination, and scope (e.g., all event types in the organization or just the authenticated user's). For a simple list, it is somewhat complete but could be more explicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is 100%. Per guidelines, 0 parameters yields a baseline of 4. The description does not add parameter info, which is acceptable since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'all configured Calendly event types', and specifies the fields returned (name, duration, slug, availability status). It distinguishes itself from siblings like get_event_type_details (single type) and list_upcoming_events (events).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus its siblings. For example, it does not explain why one would use list_event_types instead of get_event_type_details or search_events.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_upcoming_eventsB

List upcoming scheduled Calendly events. Returns event name, time, invitees, location, and status.

ParametersJSON Schema

Name	Required	Description
`count`	No	Number of events to return (1-100)
`min_start_time`	No	ISO 8601 lower bound for event start time (defaults to now)
`max_start_time`	No	ISO 8601 upper bound for event start time
`status`	No	Filter by status

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only lists returned fields but does not disclose behavioral traits like sorting order, pagination behavior, or authorization requirements. With no annotations, the description carries the full burden and falls short.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that immediately states the tool's purpose. It is concise and front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given four parameters and no output schema, the description provides enough to understand the basic functionality. However, it lacks details on default behavior (e.g., ordering, default min_start_time) and pagination. It is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with good parameter descriptions. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists upcoming scheduled Calendly events and mentions the returned fields. It is specific to upcoming events, differentiating it from siblings like search_events, but does not explicitly exclude other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as search_events or get_busy_times. The description implies it is for upcoming events but does not specify scenarios or constraints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_eventsB

Search Calendly events by invitee name or email address. Performs a case-insensitive partial match.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Name or email to search for
`min_start_time`	No	ISO 8601 lower bound for event start time
`max_start_time`	No	ISO 8601 upper bound for event start time

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses case-insensitive partial match behavior, but lacks details on limits, pagination, ordering, or side effects. Minimal but honest disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, efficient and front-loaded with the core purpose, no unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and description does not explain what the search returns (e.g., list of events, IDs, details). Missing information on pagination or result limits, which are important for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds one behavioral detail for the query parameter (case-insensitive partial match), which is useful but not extensive. No additional value for time parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (search), resource (events), and criteria (invitee name or email) with additional detail on case-insensitive partial match. It distinguishes from sibling tools that serve different purposes (e.g., get details, list all).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like list_upcoming_events or get_event_details. The description does not mention when not to use or provide context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.1May 27, 2026
- First observedcheck_availability
- First observedget_busy_times
- First observedget_event_details
- First observedget_event_type_details
- First observedlist_event_types
- First observedlist_upcoming_events
- First observedsearch_events

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: availability checking vs. busy times, event details vs. event type details, listing vs. searching. No two tools could be easily confused.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (check_availability, get_busy_times, list_event_types, etc.), making the tool surface predictable and easy to navigate.

Tool Count5/5

Seven tools cover the core Calendly interactions (listing, searching, details, availability) without redundancy. The number is well-scoped for a focused MCP server.

Completeness3/5

The set lacks create, update, or delete operations for events or event types, which are common needs. It is read-only and search-focused, leaving significant lifecycle gaps for many use cases.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
cliniko A
io.usefulapi
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Biology & Medicine Calendar Management CRM
172
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2

Related MCP Servers

Google Calendar MCP Server
Calendar Management App Automation
takumi0706
A
license
A
quality
A
maintenance
A Model Context Protocol server that integrates Google Calendar with Claude Desktop, enabling users to manage calendar events (view, create, update, delete) through natural language.
Updated 19 days ago (2026-08-18 03:51 UTC)
5
114
58
MIT
leximo-ai-call-assistant-mcpofficial
Communication AI & Machine Learning
Leximo-AI
A
license
A
quality
F
maintenance
An MCP server that lets you schedule AI phone calls and manage Leximo assignments directly from Claude Desktop or Claude Code.
Updated 7 months ago (2026-02-18 10:13 UTC)
13
67
2
MIT
calendar-pa
Calendar Management Communication
Richardilemon
F
license
Not graded
quality
C
maintenance
Google Calendar MCP server with natural language scheduling, conflict detection, smart slot finding, complex recurring events, and a Telegram bot interface. Self-hosted, works with Claude Desktop and any MCP-compatible client.
Updated 3 months ago (2026-06-04 17:21 UTC)
1
-
Calendar MCP Server
Calendar Management Workplace & Productivity
cskwork
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server for Google Calendar integration in Claude Desktop, enabling AI assistants to manage Google Calendar events through natural language interactions.
Updated 2 years ago (2025-01-09 15:24 UTC)
18
1
ISC

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NyxToolsDev/calendly-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Calendly MCP Server

Installation

Getting a Calendly Personal Access Token

Configuration

Claude Desktop

Claude Code

Environment Variables

Tools

Free Tier (7 tools)

Premium Tier (5 additional tools)

Free vs Premium

Usage Examples

Viewing Your Schedule

Event Details

Searching Events

Checking Availability

Event Types

Scheduling (Premium)

Canceling and Rescheduling (Premium)

Analytics (Premium)

Development

Setup

Running Tests

Linting

Troubleshooting

"CALENDLY_ACCESS_TOKEN is required"

401 Unauthorized errors

429 Rate limit errors

Connection errors

Premium tools not appearing

Server not starting in Claude Desktop

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

leximo-ai-call-assistant-mcpofficial

Latest Blog Posts

MCP directory API