1Open Slashspace and go to Settings, then Connectors.
2On Discover, search for Calendly MCP and click Connect.
3Sign in to Calendly MCP in your browser. Slashspace updates when the account is connected.
Then ask for what you need in any Agent mode chat. Calendly MCP is on in every chat unless you switch it off.
What your chats can do
36 tools from Calendly MCP.
Availability-get user availability scheduleUse: 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.
Availability-list user availability schedulesUse: 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.
Availability-list user busy timesUse: 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.
Event types-create event typeUse: 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.
Event types-get event typeUse: 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.
Event types-list event type availability scheduleUse: 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.
Event types-list event type available timesUse: 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`.
Event types-list event typesUse: 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.
Event types-update event typeUse: 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`.
Event types-update event type availability scheduleUse: 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.
List calendly skillsList 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.
Load calendly skillLoad 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.
Locations-list user meeting locationsUse: 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.
Meetings-cancel eventUse: 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.
Meetings-create inviteeUse: 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.
Meetings-create invitee no showUse: 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.
Meetings-delete invitee no showUse: 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.
Meetings-get eventUse: 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`.
Meetings-get event inviteeUse: 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.
Meetings-get invitee no showUse: 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.
Meetings-list event inviteesUse: 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`.
Meetings-list eventsUse: 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`.
Organizations-create organization invitationUse: 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.
Organizations-get organizationUse: 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`.
Organizations-get organization membershipUse: 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.
Organizations-list organization invitationsUse: 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.
Organizations-list organization membershipsUse: 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`.
Organizations-revoke organization invitationUse: 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.
Routing forms-get routing formUse: 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.
Routing forms-get routing form submissionUse: 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.
Routing forms-list routing formsUse: 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`.
Routing forms-list routing form submissionsUse: 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`.
Scheduling links-create single use scheduling linkUse: 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.
Shares-create shareUse: 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.
Users-get current userUse: 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.
Users-get userUse: 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.
