Calendly

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.

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.

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.

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.

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.

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.

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: start_time is UTC; convert to user's local TZ (handle DST); show conversion when ambiguous. 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.

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.

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.

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.

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.

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; confirm with user before calling. Avoid: Canceling without user confirmation. This notifies all invitees. Then: Inform user the meeting is canceled and optionally list remaining meetings.

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.

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.

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.

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.

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 to determine no-show status. Avoid: Calling without known meeting and invitee URIs. Then: Use invitee URI in no-show tools if needed.

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.

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.

Use: List scheduled meetings for the connected user or org. When: User asks to see upcoming or past meetings or to find one by date/type. Needs: User or org URI from users-get_current_user. Do: Filter by status (active/canceled) and date range as needed; carry returned uri forward. Avoid: Fetching unfiltered when the user has a specific date or type in mind. Then: Use returned meeting uri in meetings-get_event or meetings-cancel_event.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 uri and timezone for event-type or availability lookups scoped to that user.