Calendly MCP logo

Integrate Calendly MCP with your AI CRM

Calendly MCP lets agents manage event types and availability, find open times, generate scheduling links, book meetings, and cancel scheduled events.

Automate your first taskSign up with Google

Explore Triggers and Actions

Availability-get user availability schedule

Use: Fetch details for one named availability schedule. When: User asks about specific schedule rules or needs rules for a named schedule. Needs: Schedule URI from `availability-list_user_availability_schedules`. Do: Read `rules` array and `timezone` for display or to inform event-type updates. Avoid: Writing to this schedule—use event-type-level update for changes. Then: Report schedule details to user or use rules for availability queries.

ActionTry it

Availability-list user availability schedules

Use: List all named availability schedules for the connected user. When: User asks about availability schedules or you need to identify one by name. Needs: User URI from `users-get_current_user`. Do: Use returned `uri` to fetch schedule details or associate with an event type. Avoid: Confusing user availability schedules with event-type-level schedules. Then: Use schedule URI in `availability-get_user_availability_schedule` for details.

ActionTry it

Availability-list user busy times

Use: List a user's busy time blocks within a date range. When: User asks when they are busy or you need to avoid conflicts before suggesting slots. Needs: User URI from `users-get_current_user` and ISO 8601 start/end range. Do: Pass user URI and date range; use returned intervals to report conflicts. Avoid: Substituting for `event_types-list_event_type_available_times`—they differ. Then: Use busy intervals to inform scheduling recommendations.

ActionTry it

Event types-create event type

Use: Create a new event type on the connected account. When: User explicitly asks to create a new event type. Needs: Host user URI from `users-get_current_user`. Do: Set name, duration, and host URI; omit optional fields unless user specified them. Avoid: Creating duplicates—call `event_types-list_event_types` first to check for existing types. Then: Confirm the new event type URI and share the scheduling URL.

ActionTry it

Event types-get event type

Use: Fetch full details for one event type by URI. When: Before updating an event type or confirming its current configuration. Needs: Event type URI. Do: Use the returned fields as the baseline for any patch payload. Avoid: Constructing update payloads without reading current state first. Then: Proceed with `event_types-update_event_type` using the returned data as base.

ActionTry it

Event types-list event type availability schedule

Use: Read the current availability schedule (rules) for an event type. When: Before calling `event_types-update_event_type_availability_schedule`. Needs: Event type URI. Do: Retain the full `rules` array verbatim—it is the required base for updates. Avoid: Calling the update endpoint without first reading the current rules. Then: Pass the rules to `event_types-update_event_type_availability_schedule` with only the needed edits.

ActionTry it

Event types-list event type available times

Use: List bookable time slots for an event type within a date range. When: User wants slots, or to confirm availability before booking. Needs: Event type URI and start/end date range (ISO 8601). Do: Pass `start_time` verbatim to subsequent tool calls; do not rewrite UTC values. Avoid: Stale data, or trusting a prior local label—re-check UTC `start_time` if questioned. Then: Pass UTC `start_time` to `meetings-create_invitee`.

ActionTry it

Event types-list event types

Use: List all event types for the connected user or org. When: Start of any event-type task, or when selecting an event type by name. Needs: User URI from `users-get_current_user`. Do: Filter by current user URI unless user explicitly asks about a different host or org. Avoid: Assuming a cached list is current—call fresh each session. Then: Carry the selected `uri` into get, update, or availability tools.

ActionTry it

Event types-update event type

Use: Update fields on an existing event type. When: User asks to change name, duration, description, or other settings. Needs: Event type URI from `event_types-list_event_types` or `event_types-get_event_type`. Do: Read current state first with `event_types-get_event_type`; patch only requested fields. Avoid: Sending fields not read from current state—partial writes may reset unset fields. Then: Confirm changes with `event_types-get_event_type`.

ActionTry it

Event types-update event type availability schedule

Use: Overwrite the availability schedule for an event type. When: User requests schedule changes (hours, days, one-off date overrides) for an event type. Needs: Event type URI and current rules from `event_types-list_event_type_availability_schedule`. Do: Must copy existing rules verbatim, modify only requested entries, send full rules array with IANA timezone. wday rules need `wday` field; date rules need `date` field (YYYY-MM-DD); `intervals` is list of `{from, to}` in HH:MM 24h. Avoid: Constructing rules from scratch or sending a partial array—this endpoint overwrites all rules. Then: Re-read schedule with `event_types-list_event_type_availability_schedule` to confirm.

ActionTry it

List calendly skills

List or search available Calendly skill guides. Each skill gives domain-specific context, recommended tool usage, and best practices for working with Calendly MCP tools. Call this when the user's goal has no obvious single tool (e.g. reschedule or move a meeting). Load a matching skill before using related workflow tools. Use `keywords` to search by name or description (any keyword may match), and `include_header=true` to include each skill's description and related skills.

ActionTry it

Load calendly skill

Load a Calendly skill guide that provides domain-specific context, recommended queries, and best practices for working with Calendly tools. Required after listing when a skill matches; do not guess multi-step flows from tool names alone. Use `list_calendly_skills` to discover available skills, or load directly by name. Set `header_only=true` to preview a skill's description and related skills without loading full content.

ActionTry it

Locations-list user meeting locations

Use: List allowed meeting location kinds for a user. When: Before creating bookings that need a `location` payload. Needs: User URI from `users-get_current_user`. Do: Read supported location `kind` values; choose one compatible with the event type. Avoid: Submitting a location kind not configured for the host or event type. Then: Use chosen kind in `meetings-create_invitee` location payload.

ActionTry it

Meetings-cancel event

Use: Cancel a scheduled meeting on behalf of the connected host When: User confirms they want to cancel a specific meeting. Needs: Meeting URI from `meetings-list_events` or `meetings-get_event`. Do: Pass meeting URI and optional cancellation reason. Avoid: Canceling without confirmation; this notifies all invitees. For reschedule, surface `reschedule_url` instead. Then: Inform user the meeting is canceled and optionally list remaining meetings.

ActionTry it

Meetings-create invitee

Use: Book a meeting slot for an invitee on a Calendly event type. When: User provides invitee name, email, and a confirmed available time slot. Needs: Event type URI, `start_time` from `event_types-list_event_type_available_times`, invitee name and email. Include `location` if the event type has configured locations. Do: Set invitee name/email as the person being booked; host is the connected user from `users-get_current_user`. Never swap host and invitee fields. Avoid: Booking without confirming slot availability first, or omitting `location` when event type requires it. Then: Confirm booking with invitee details and meeting URI.

ActionTry it

Meetings-create invitee no show

Use: Mark an invitee as a no-show for a past meeting. When: User reports an invitee did not attend. Needs: Invitee URI from `meetings-list_event_invitees`. Do: Pass invitee URI; operation is idempotent. Avoid: Marking no-show before the meeting end time. Then: Confirm no-show is recorded and carry forward the no-show URI.

ActionTry it

Meetings-delete invitee no show

Use: Remove a no-show mark from an invitee. When: User asks to undo a no-show marking. Needs: No-show URI from `meetings-create_invitee_no_show`. Do: Pass no-show URI; operation is idempotent. Avoid: Calling without confirming a no-show record exists. Then: Confirm no-show has been removed.

ActionTry it

Meetings-get event

Use: Fetch details for a single scheduled meeting. When: User asks about a specific meeting or before canceling/examining invitees. Needs: Meeting URI from `meetings-list_events`. Do: Use returned `event_type`, `start_time`, `end_time`, and `location` for display or next actions. Avoid: Calling this without a known meeting URI. list meetings first. Then: Use meeting URI in `meetings-list_event_invitees` or `meetings-cancel_event`.

ActionTry it

Meetings-get event invitee

Use: Fetch details for a single meeting invitee. When: User asks about a specific attendee's booking details. Needs: Meeting URI from `meetings-list_events` and Invitee URI from `meetings-list_event_invitees`. Do: Use returned fields for display or no-show status. Reschedule: surface `reschedule_url`. Avoid: Calling without known meeting and invitee URIs. Then: Use invitee URI in no-show tools if needed.

ActionTry it

Meetings-get invitee no show

Use: Fetch the no-show record for a meeting invitee. When: User asks whether a no-show was recorded for an invitee. Needs: No-show URI from `meetings-create_invitee_no_show`. Do: Check returned record for no-show status and timestamp. Avoid: Calling if no no-show has been recorded—returns 404. Then: Report no-show status to user.

ActionTry it

Meetings-list event invitees

Use: List all invitees for a scheduled meeting. When: User asks who is attending a meeting or you need invitee URIs. Needs: Meeting URI from `meetings-list_events`. Do: Use returned invitee `uri` for no-show marking or detail lookups. Avoid: Calling without a meeting URI. list meetings first. Then: Use invitee URI in `meetings-get_event_invitee` or `meetings-create_invitee_no_show`. For reschedule, surface each invitee's `reschedule_url`.

ActionTry it

Meetings-list events

Use: List scheduled meetings for user/org. When: Upcoming/past meetings or to find meetings by date. Needs: User/org URI via `users-get_current_user`. Do: Filter status (active/canceled), date range; carry `uri`. Avoid: Fetching unfiltered when the user has a specific date. Then: Enrich via `meetings-list_event_invitees` before listing/naming meetings, unless asked for only a count; then `uri` in `meetings-get_event`/`meetings-cancel_event`.

ActionTry it

Organizations-create organization invitation

Use: Invite a user to the organization by email. When: User asks to add a new member. Needs: Org URI and invitee email address. Do: Check `organizations-list_organization_invitations` first to avoid duplicate invites. Avoid: Calling without confirming no pending invite exists for this email. Then: Confirm invitation sent and optionally show pending invitations.

ActionTry it

Organizations-get organization

Use: Fetch details for the connected user's organization. When: User asks about the org or you need the org URI for org-scoped list tools. Needs: Org URI from `users-get_current_user` (`resource.current_organization`). Do: Use returned `uri` for org-scoped event type or membership queries. Avoid: Calling without an org URI. Then: Use org URI in `organizations-list_organization_memberships`.

ActionTry it

Organizations-get organization membership

Use: Fetch details for a single org membership. When: You need role or status for a specific member. Needs: Membership URI from `organizations-list_organization_memberships`. Do: Check `role` and `status` fields for permissions context. Avoid: Calling without a known membership URI. Then: Use membership data to confirm before invite or removal actions.

ActionTry it

Organizations-list organization invitations

Use: List pending invitations for the organization. When: User asks to see pending invites or check if someone was already invited. Needs: Org URI from `users-get_current_user`. Do: Check returned list before sending a new invite to avoid duplicates. Avoid: Sending a new invitation without checking for existing pending ones. Then: Use invitation URI in `organizations-revoke_organization_invitation` if needed.

ActionTry it

Organizations-list organization memberships

Use: List all members of an organization. When: User asks who is in the org or you need to find a member's user URI. Needs: Org URI from `users-get_current_user`. Do: Use returned `user.uri` for per-user event-type or availability queries. Avoid: Fetching the full list when you only need the connected user—use `users-get_current_user` instead. Then: Use member URI in user-scoped tools or `organizations-get_organization_membership`.

ActionTry it

Organizations-revoke organization invitation

Use: Revoke a pending organization invitation. When: User asks to cancel a pending invite. Needs: Organization URI from `users-get_current_user` and Invitation URI from `organizations-list_organization_invitations`. Do: Confirm with user before revoking; this cannot be undone. Avoid: Revoking without confirming the invite is still pending. Then: Confirm revocation and optionally refresh invitations list.

ActionTry it

Routing forms-get routing form

Use: Fetch details for a single routing form. When: User asks about a specific form or its questions. Needs: Routing form URI from `routing_forms-list_routing_forms`. Do: Use returned question IDs for submission filtering. Avoid: Calling without a known form URI. Then: Use form details to answer user questions or list submissions.

ActionTry it

Routing forms-get routing form submission

Use: Fetch details for a single routing form submission. When: User asks about a specific submission or response. Needs: Submission URI from `routing_forms-list_routing_form_submissions`. Do: Read `questions_and_answers` for the submitted values. Avoid: Calling without a known submission URI. Then: Report submission details to user.

ActionTry it

Routing forms-list routing form submissions

Use: List submissions for a routing form. When: User asks to see form responses or analyze routing data. Needs: Routing form URI from `routing_forms-list_routing_forms`. Do: Use pagination params for large result sets. Avoid: Fetching all submissions without date/count filters on high-volume forms. Then: Use submission URI in `routing_forms-get_routing_form_submission`.

ActionTry it

Routing forms-list routing forms

Use: List routing forms for the org. When: User asks about routing forms or you need to find a form by name. Needs: Org URI from `users-get_current_user`. Do: Use returned `uri` to fetch form details. Avoid: Assuming form names without listing first. Then: Use form URI in `routing_forms-get_routing_form`.

ActionTry it

Scheduling links-create single use scheduling link

Use: Create a single-use scheduling link using the event type's settings unchanged. When: User wants a one-time link with no overrides. For per-link customization (duration, scheduling window, location, availability), use `shares-create_share` instead. Needs: Event type URI from `event_types-list_event_types`. Do: Each call creates a new link; store the returned `booking_url`. Avoid: Using when any override is requested — this endpoint cannot customize the link. Don't create more links than needed; each call creates a distinct non-reusable link. Then: Share `booking_url` with the intended invitee.

ActionTry it

Shares-create share

Use: Create a single-use share link for a one-on-one event type with per-link overrides When: User wants a single-use link with any customization (duration, scheduling window, location, or availability). Needs: Event type URI from `event_types-list_event_types`. Do: Set only fields to override; omitted fields inherit from event type. Avoid: Group event types (one-on-one only). This overrides event-type fields, not invitee prefill values. Then: Share the returned `booking_url` with the recipient.

ActionTry it

Users-get current user

Use: Resolve the connected host account and canonical user URI. When: Start any scheduling, booking, event-type, or availability workflow. Needs: No inputs. Do: Call once and keep `resource.uri`, `timezone`, and `scheduling_url` for downstream calls. Avoid: Skipping this and guessing host identity. Then: Use `resource.uri` in list/get tools unless the user explicitly names another host.

ActionTry it

Users-get user

Use: Fetch profile for a specific user by URI. When: User asks about another person's account or you hold a user URI from org/membership data. Needs: User URI. Do: Pass the user URI from org/membership data; do not use this to look up the connected user. Avoid: Calling this without a known URI - use `users-get_current_user` for the connected user. Then: Use returned `resource.uri` and `resource.timezone` for event-type or availability lookups scoped to that user.

ActionTry it

How the Calendly MCP integration works

The Calendly MCP integration connects your Dench AI CRM directly to Calendly MCP, so agents can read and act on your Calendly MCP data as part of everyday work — answering questions in chat, keeping your CRM in sync, and running automations without anyone copying data between tools.

36 actions are available for agents to invoke on your behalf. Every call runs through Calendly MCP's own authorization, scoped to the account you connect.

Set up Calendly MCP in Dench

  1. 1

    Sign in to your Dench workspace and open Integrations.

  2. 2

    Find Calendly MCP and click Connect — you'll authorize access through Calendly MCP's own sign-in flow. No API keys or code required.

  3. 3

    Ask an agent to use Calendly MCP in chat, or call it from an automation.

  4. 4

    Manage or disconnect the connection any time from workspace settings.

Frequently asked questions

How does the Calendly MCP integration work with Dench?

The Dench Calendly MCP integration connects your AI CRM to Calendly MCP, so AI agents can work with your Calendly MCP data as part of chats, automations, and CRM workflows. You connect your account once, and every agent in your workspace can use it — governed by your workspace permissions.

What actions can AI agents perform with Calendly MCP via Dench?

The Calendly MCP integration currently exposes 36 actions, including Availability-get user availability schedule, Availability-list user availability schedules, Availability-list user busy times, Event types-create event type, Event types-get event type, and Event types-list event type availability schedule. Agents invoke them on your behalf from chat or from automations.

Do I need to write code to connect Calendly MCP to Dench?

No. You connect Calendly MCP from your Dench workspace using Calendly MCP's own sign-in and authorization flow — no API keys to copy, no glue code to maintain.

Is the Calendly MCP integration secure?

Connections are authorized through Calendly MCP's own authentication flow, and Dench stores only the authorization needed to act on your behalf. You can review and disconnect the Calendly MCP connection from your workspace settings at any time.

Calendly MCP | Dench AI CRM