What can you do with this server?

A Calendly MCP server/CLI exposing 66 tools (44 reads, 22 confirmation-guarded writes) for scheduling, contacts, recaps, organizations and webhooks. * Users & identity: read the current user or any user by UUID to get canonical URIs. * Scheduled events: list/get events, list invitees, get a single invitee, cancel an event, and create invitees to book real meetings. * No-shows: create, get and delete invitee no-show records. * Event types: list, get, create, update, create one-off event types, and list event type hosts. * Availability: read user schedules, event-type schedules and busy times; list available slots; update event-type availability rules (replaces all rules). * Scheduling links & shares: create single-use scheduling links and customized share links for one-on-one event types. * Contacts: list, get, create, update and delete contacts, including typed custom field values. * Custom fields: list and get contact custom field definitions. * Meeting recaps (Notetaker): list, get, update and delete recaps, plus retrieve transcripts — read-only, no recording or generation. * Organizations: get organization, memberships, invitations, teams; invite, revoke invitations and remove members. * Groups: list and get groups and group relationships. * Routing forms: list forms and submissions, get individual forms/submissions. * Webhooks: create, list, get and delete subscriptions; fetch sample webhook payloads. * Activity & communications: list activity log entries and outgoing communications (Enterprise-level features). * Data compliance: request invitee or scheduled-event data deletion. * Local helper: list_accounts lists named private credential labels without any network call. * Safe by default: every write needs explicit confirmation, with read-only/destructive blocking, per-account credentials and bounded pagination.

Which integrations are available for this server?

Provides tools for interacting with the Calendly API v2 (66 tools: 44 reads and 22 confirmed writes), enabling AI agents to look up the current user and event types, check event-type availability, book invitees, read and manage contacts and contact custom field definitions, access Notetaker meeting recaps and transcripts, and inspect organizations, memberships, groups, routing submissions, availability rules and webhook subscriptions. It supports private scoped Personal Access Tokens and REST OAuth grants, named accounts, pagination and quota handling, and requires explicit confirmation for every write operation.

How do I use Calendly MCP Server?

1. Click on "Deploy 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 find available times for my 30-min intro call 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 thenavidm

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Calendly MCP Server & CLI

npm License YouTube LinkedIn

Calendly MCP server and CLI for Claude Code, Codex and AI agents. 66 tools: 44 reads and 22 confirmed writes for scheduling, contacts, custom fields, Notetaker recaps, transcripts, availability, organizations and webhooks.

One package provides local MCP, the same operations as task CLI commands, and a bundled Claude Desktop .mcpb extension.

Built and maintained by Navid Moazzez. Built on Slipway, which turns one definition of each tool into the MCP server and the CLI. Complete installation and private account setup are in INSTALL.md.

The terminal illustrates shipped scheduling tools with sample data; it is not a verified live account booking.

You need a privately configured scoped PAT or authorized REST OAuth grant. Account roles, paid features and quotas apply. The wrapper preserves AGPL-3.0-or-later; Calendly service charges remain separate. This is a community product.

Calendly already offers an official hosted MCP and a community CLI exists. Our current API coverage and tradeoffs are compared below, without unsupported coverage or efficiency claims.

Two ways to use it

Command line

npm install -g @thenavidm/calendly-mcp-cli@latest
calendly-cli
calendly-cli list-events --help
calendly-cli schema create-invitee
calendly-cli get-current-user --agent

Configure private credentials before account calls. Every write requires --confirm; --yes and --agent do not authorize changes.

MCP server, for your AI app

codex mcp add calendly -- npx -y @thenavidm/calendly-mcp-cli@latest

Then ask: Find available slots for the event type I choose, and wait for my booking details. All declared client/OS routes are in INSTALL.md.

Which one

Where you work	Surface
Claude Code, Codex, Cursor or another shell agent	MCP, CLI or both
Claude Desktop chat	Local MCP or desktop bundle
Scripts/CI	CLI or an MCP client
Remote-URL-only clients with DCR support	Official hosted Calendly MCP

Related MCP server: Cal.com MCP Server

Features

Capability	CLI	MCP
Identity and events	get-current-user / list-events	get_current_user / list_events
Availability and booking	list-event-type-available-times / create-invitee	Same underscore names
Contacts/custom fields	list-contacts / list-contact-custom-field-definitions	Same shared schemas
Recaps/transcripts	list-recaps / get-transcript	Same account permissions
Organizations and webhooks	list-organization-memberships / list-webhooks	Same guarded writes
Private account labels	list-accounts	list_accounts
Setup diagnosis	doctor / login	CLI utilities

Number	Section	Covers
1	What you can ask it	Prompts and coverage
2	Quick install	CLI, MCP and desktop
3	Set up Calendly access	PAT, OAuth, scopes and quotas
4	Connect your client	All declared clients/OS
5	Check it works	Doctor and first read
6	Output, flags and exit codes	Arguments, JSON and scripting
7	MCP or CLI and token cost	Actual usage comparison
8	Every tool and argument	Every operation and argument
9	Scheduling, contacts and recap workflows	Booking, contacts, recaps and webhooks
10	Pagination, quotas and accepted operations	Opaque tokens and pending requests
11	Several private accounts	Named private grants
12	Writing safely	Confirmation and audit
13	How it works	Shared architecture and maintenance
14	Your data	Privacy and credentials
15	Environment variables	Credential, safety and tuning
16	Updates and removal	Upgrade and revoke
17	Troubleshooting	Symptoms and remedies
18	API coverage and comparisons	Official/community evidence
19	Versions	Versions and migration
20	FAQ	Accordion questions

1. What you can ask it

Show my current user and the event types I can access.
Find available slots for the selected event type and time zone.
Book the specific slot and invitee I approved.
Read that booking before a requested cancellation.
Find a contact and inspect its custom field definitions before changing it.
Read an authorized meeting recap or transcript, and keep its contents private.
Inspect existing availability rules before the requested replacement.
List organization members, groups, routing submissions and webhook subscriptions.

The current API v2 snapshot has 65 operations. With the local account-label helper, this package exposes 66 tools: 44 reads and 22 confirmed writes. One source serves local MCP, task CLI and the bundled desktop extension. Booking sends normal calendar invites, notifications and workflows. A generated scheduling link is not a booked event.

The official hosted MCP is a strong scheduling option. This package adds local CLI use, private PAT/REST OAuth grants, named accounts, current Contacts/Notetaker operations, schema-derived help and controlled output. Coverage differences are based on reviewed documentation, not a competitor handshake or a measured superiority claim. Live account outcomes and GUI installation remain separately unverified.

2. Quick install

npm install -g @thenavidm/calendly-mcp-cli@latest
calendly-cli --version
calendly-cli login
calendly-cli doctor
calendly-cli tools

Manual CLI/local MCP requires Node 22 or newer. Discovery and schemas work without credentials; account reads need private access. The versioned desktop archive bundles production dependencies for a compatible Claude Desktop host. See INSTALL.md for every declared client and OS.

After private configuration:

codex mcp add calendly -- npx -y @thenavidm/calendly-mcp-cli@latest
codex mcp list

3. Set up Calendly access

Personal Access Token for your own account

Sign in to the intended Calendly account.
Open Integrations > API and webhooks, or the token page.
Create a named Personal Access Token with the scopes your workflow requires. Copy it once into private storage.
Set CALENDLY_API_TOKEN in private local client/shell settings, or CALENDLY_TOKEN_FILE to an absolute token-only file outside repositories.
Run calendly-cli doctor, then calendly-cli doctor --network to check a user read.

See current PAT setup. The token is a Bearer credential, not your Calendly password or browser cookie. Revocation is done in Calendly. GUI clients may not inherit terminal variables; this package does not load .env automatically. On POSIX, a credential file must be owner-only, such as mode 0600; on Windows protect the file and its directory with user-only ACLs. Readers refuse symlinks and files larger than 64 KB. A PAT file takes precedence over the environment PAT, and is cached until restart.

Existing REST OAuth grant

Use your own authorized REST OAuth application when acting for users who consent to your application. This local package does not create an OAuth app, open a browser, host a callback or exchange the first authorization code. login prints setup instructions. Put an existing access token in CALENDLY_ACCESS_TOKEN, or the full grant in a private file selected by CALENDLY_TOKENS_FILE. Do not mix PAT and OAuth settings for the same account.

The token file is a JSON object containing access_token, and optionally refresh_token, client_id, client_secret, created_at (Unix seconds) and expires_in (seconds). Keep all actual values outside model context and repositories. A file is required for automatic refresh; an environment-only access token is never refreshed. The file is read on each request, allowing separate processes to observe a saved rotation. Without valid expiry metadata, one GET 401 can trigger one configured refresh; writes never retry after a 401.

Calendly's single-use refresh-token rule took effect by August 31, 2026. This package refreshes against https://calendly.com/oauth/token, uses Basic client authentication for confidential clients or a body client_id without a secret, and atomically replaces both returned tokens in mode 0600 storage. Concurrent in-process refreshes share one promise, and a per-file .refresh.lock prevents another process from consuming the same token. An existing lock produces a configuration error instead of a second refresh. A crashed process can leave a lock; stop all users of that grant and verify its state before manually removing a stale lock. Never remove an active lock.

A refresh HTTP failure, unknown timeout, incomplete response or failed save requires reauthorization/private storage repair and a restart. No automatic refresh retry occurs. The old refresh token is not deliberately reused after an uncertain result. OAuth access tokens last two hours according to the current token reference; actual expiry metadata governs proactive refresh. Token rotation fixtures are verified; live grants remain unverified.

Scopes, roles and plans

API operation descriptions list their required scopes. :write grants include the family's read access. Start with users:read for doctor, then select only needed scheduling, availability, contacts, meeting_recaps, organization, routing, group or webhook scopes. Webhooks need webhooks:write plus the corresponding event family's read scope. Reauthorize or replace the token if scopes change; an installed command cannot raise permissions.

Direct booking through create_invitee requires a paid Standard-or-higher account. Routing Forms require Teams or higher; Activity Log, outgoing communications and data-compliance deletion require Enterprise and suitable organization permissions. Notetaker endpoints require a paid plan; Contacts/Notetaker data exists only where the account and associated feature provide it. API access does not create transcripts or bypass recording/consent policy. Administrative operations depend on your actual role. See authorization scopes and the current endpoint reference before choosing a plan.

Current request limits

The quota reference documents 50 requests per user/minute on Free and 500 on paid plans. Booking has tighter limits: trial 5/day; paid non-Enterprise 10/minute, 50/hour and 100/day; Enterprise 500/minute. OAuth token requests are limited to 8/user/minute. These are shared provider limits, not allowances reserved for this process.

Default local pacing is 1,300 ms per account/process; multiple account labels for one user and other integrations share that user's quota. GET 429 handling respects Retry-After or X-RateLimit-Reset when the wait is at most ten seconds. Longer waits surface exit 7 so a script can pause explicitly, rather than retry too early. Writes and OAuth refresh requests have zero automatic retries. Every page and retried read consumes quota.

Official hosted MCP is a separate connection

Calendly's official MCP is hosted at https://mcp.calendly.com. It uses OAuth 2.1, PKCE S256, resource discovery and Dynamic Client Registration. It does not accept a PAT or a manually provisioned console client_id/client_secret connection. A client prompting only for static OAuth credentials is incompatible with that documented flow. The documentation search MCP at https://developer.calendly.com/_mcp/server reads docs; it does not operate your account. Keep all three entries distinct.

4. Connect your client

INSTALL.md covers Claude Code, Codex, Claude Desktop extension/manual config, Cursor, VS Code/Copilot, Windsurf, Zed, Gemini CLI, Cline, Docker and other stdio clients on macOS, Windows and Linux. Use npx -y @thenavidm/calendly-mcp-cli@latest as the local server command, with private environment settings. MCP and CLI are two ways to reach the same operations; installing both is optional.

A remote-URL-only client needs a hosted connector such as Calendly's official https://mcp.calendly.com, with DCR OAuth support. This package does not expose a public HTTP relay. Installing a local server does not connect it to a browser-only app. Place SKILL.md in the agent's supported skills folder if using shell commands; npm does not register it automatically. Ask the agent to inspect current help/schemas and assist with private setup without asking you to paste credentials into chat.

5. Check it works

calendly-cli --version
calendly-cli doctor
calendly-cli doctor --network
calendly-cli list-accounts --agent
calendly-cli get-current-user --agent

The local doctor checks configuration. Network doctor reads /users/me and reports success without printing user details; it does not book, cancel or invite anyone. A successful read proves that read's access, not every endpoint/plan permission. Full discovery has 66 tools; read-only has 44. Use the returned canonical user and organization URIs in subsequent filters, rather than substituting a bare UUID.

6. Output, flags and exit codes

Tool names become dashed commands; underscores are accepted too. Path parameter names follow the discovered schema, such as event_uuid → --event-uuid. Body tools accept individual top-level flags, complete --payload JSON, or --payload-file pointing to a regular JSON body file up to 5 MB. Do not mix those body routes. Path/query flags remain separate. Nested objects take JSON and array flags repeat once per item; a whole array is not a single item.

calendly-cli get-event --help
calendly-cli schema create-invitee
calendly-cli list-events --user https://api.calendly.com/users/USER_UUID --count 10 --agent
calendly-cli list-contacts --email user@example.com --count 5 --agent

UUIDs and URIs are illustrative; use resources discovered in your own account. Nullable fields require an actual JSON null inside payload; --field null is a string. Nested request properties follow the current schema; unknown top-level body fields are refused. Body-required fields are validated during execution even when the wrapper schema allows an alternative payload route. Operations whose upstream request body is required need body flags or an explicit payload; a deliberately supplied empty object is sent as JSON, never omitted.

Flag	Behavior
--help / schema COMMAND	Current argument help / full JSON Schema
--json	Structured JSON
--compact	One-line JSON
--agent	Compact JSON and no prompts; never confirms a write
--select a,b.c	Keep selected fields, including nested objects/arrays
--no-color / --no-input	Noninteractive house flags
--yes	Never replaces write confirmation
--confirm	Confirm only the requested mutation
--account NAME	Select private local credentials
--payload JSON / --payload-file PATH	Complete request body, mutually exclusive with body flags

Exit	Meaning
0	Success
1	Unexpected error
2	Invalid arguments or refused write, an unknown command or a hidden write
3	Resource not found
4	Authentication/permission failure
5	API/transport failure
7	Rate limit
10	Missing or invalid private configuration

Results go to stdout, errors as JSON to stderr. Selection changes local output, not the original API response or quota charge. API success is not proof of notification delivery or a completed export.

7. MCP or CLI and token cost

MCP and CLI are built by Slipway from each tool's one definition, so they share schemas, validation and HTTP handlers; there is no second API implementation.

Measured on 2026-10-05 against 2.0.1, the same day, with Claude Code 2.1.286 on Claude Opus 5.5 (one short prompt with and without the server connected, the difference read from the API's own usage figures) and Codex 0.159.3 on gpt-6.1-sol:

Cost	2.0.1	3.0.0
Claude Code, every tool loaded, every message	47,642	39,979
Claude Code's default, tool search, every message	1,169	1,169
`SKILL.md`, read once	1,382	1,444
Codex over the CLI, one task, median of five	83,991	83,073
Codex over MCP, the same task, median of five	48,565	48,780

The task was "find the command that cancels a scheduled event, and the flags it requires". Every tool loaded costs less because each write's body appeared twice, as its own fields and inside payload, and 3.0.0 writes each repeated part once under $defs. Over the CLI, every 3.0.0 run asked which (255 characters) where 2.0.1's read the full command list (4,745). Over MCP, Codex prints its own TypeScript rendering of the tool list, cut to about 10,000 tokens, and that rendering is longer on 3.0.0, 31,126 tokens against 29,830: Codex leaves the argument descriptions out of a tool whose schema is large, and sharing the repeats brought create_contact and update_contact under that size, so Codex now shows their descriptions. SKILL.md costs 62 more because it now says how approval works over MCP and lists every exit code.

API quota and service costs remain separate, and no other offering was measured.

8. Every tool and argument

All 65 API operations come from the pinned current official OpenAPI. list_accounts is local. Each tool is the same dashed CLI command. Top-level flags and nested request fields are shown below; schema COMMAND returns complete unions, enums and conditional rules. Body requirements apply whether you use individual flags or payload/payload_file.

Tool	REST operation	Mode	Required scope
`list_activity_log`	`GET /activity_log_entries`	Read	`activity_log:read`
`get_availability_schedule`	`GET /user_availability_schedules/{uuid}`	Read	`availability:read`
`list_event_type_availability_schedules`	`GET /event_type_availability_schedules`	Read	`availability:read`
`update_event_type_availability_schedules`	`PATCH /event_type_availability_schedules`	Write, confirms	`availability:write`
`list_availability_schedules`	`GET /user_availability_schedules`	Read	`availability:read`
`list_user_busy_times`	`GET /user_busy_times`	Read	`availability:read`
`create_contact`	`POST /contacts`	Write, confirms	`contacts:write`
`list_contacts`	`GET /contacts`	Read	`contacts:read`
`delete_contact`	`DELETE /contacts/{uuid}`	Write, confirms	`contacts:write`
`get_contact`	`GET /contacts/{uuid}`	Read	`contacts:read`
`update_contact`	`PATCH /contacts/{uuid}`	Write, confirms	`contacts:write`
`get_contact_custom_field_definition`	`GET /contacts/custom_field_definitions/{uuid}`	Read	`contacts:read`
`list_contact_custom_field_definitions`	`GET /contacts/custom_field_definitions`	Read	`contacts:read`
`delete_invitee_data`	`POST /data_compliance/deletion/invitees`	Write, confirms	`data_compliance:write`
`delete_scheduled_event_data`	`POST /data_compliance/deletion/events`	Write, confirms	`data_compliance:write`
`create_event_type`	`POST /event_types`	Write, confirms	`event_types:write`
`list_event_types`	`GET /event_types`	Read	`event_types:read`
`create_one_off_event_type`	`POST /one_off_event_types`	Write, confirms	`event_types:write`
`get_event_type`	`GET /event_types/{uuid}`	Read	`event_types:read`
`update_event_type`	`PATCH /event_types/{uuid}`	Write, confirms	`event_types:write`
`list_event_type_available_times`	`GET /event_type_available_times`	Read	`availability:read`
`list_event_type_hosts`	`GET /event_type_memberships`	Read	`event_types:read`
`get_group`	`GET /groups/{uuid}`	Read	`groups:read`
`get_group_relationship`	`GET /group_relationships/{uuid}`	Read	`groups:read`
`list_group_relationships`	`GET /group_relationships`	Read	`groups:read`
`list_groups`	`GET /groups`	Read	`groups:read`
`list_user_locations`	`GET /locations`	Read	`locations:read`
`delete_recap`	`DELETE /meeting_recaps/{uuid}`	Write, confirms	`meeting_recaps:write`
`get_recap`	`GET /meeting_recaps/{uuid}`	Read	`meeting_recaps:read`
`update_recap`	`PATCH /meeting_recaps/{uuid}`	Write, confirms	`meeting_recaps:write`
`get_transcript`	`GET /meeting_recaps/{uuid}/transcript`	Read	`meeting_recaps:read`
`list_recaps`	`GET /meeting_recaps`	Read	`meeting_recaps:read`
`get_organization`	`GET /organizations/{uuid}`	Read	`organizations:read`
`get_organization_invitation`	`GET /organizations/{org_uuid}/invitations/{uuid}`	Read	`organizations:read`
`revoke_organization_invitation`	`DELETE /organizations/{org_uuid}/invitations/{uuid}`	Write, confirms	`organizations:write`
`get_organization_membership`	`GET /organization_memberships/{uuid}`	Read	`organizations:read`
`remove_from_organization`	`DELETE /organization_memberships/{uuid}`	Write, confirms	`organizations:write`
`get_team`	`GET /teams/{team_uuid}`	Read	`organizations:read`
`invite_to_organization`	`POST /organizations/{uuid}/invitations`	Write, confirms	`organizations:write`
`list_organization_invitations`	`GET /organizations/{uuid}/invitations`	Read	`organizations:read`
`list_organization_memberships`	`GET /organization_memberships`	Read	`organizations:read`
`list_teams`	`GET /teams`	Read	`organizations:read`
`list_outgoing_communications`	`GET /outgoing_communications`	Read	`outgoing_communications:read`
`get_routing_form`	`GET /routing_forms/{uuid}`	Read	`routing_forms:read`
`get_routing_form_submission`	`GET /routing_form_submissions/{uuid}`	Read	`routing_forms:read`
`list_routing_form_submissions`	`GET /routing_form_submissions`	Read	`routing_forms:read`
`list_routing_forms`	`GET /routing_forms`	Read	`routing_forms:read`
`cancel_event`	`POST /scheduled_events/{uuid}/cancellation`	Write, confirms	`scheduled_events:write`
`create_invitee`	`POST /invitees`	Write, confirms	`scheduled_events:write`
`create_no_show`	`POST /invitee_no_shows`	Write, confirms	`scheduled_events:write`
`delete_no_show`	`DELETE /invitee_no_shows/{uuid}`	Write, confirms	`scheduled_events:write`
`get_no_show`	`GET /invitee_no_shows/{uuid}`	Read	`scheduled_events:read`
`get_event`	`GET /scheduled_events/{uuid}`	Read	`scheduled_events:read`
`get_event_invitee`	`GET /scheduled_events/{event_uuid}/invitees/{invitee_uuid}`	Read	`scheduled_events:read`
`list_event_invitees`	`GET /scheduled_events/{uuid}/invitees`	Read	`scheduled_events:read`
`list_events`	`GET /scheduled_events`	Read	`scheduled_events:read`
`create_scheduling_link`	`POST /scheduling_links`	Write, confirms	`scheduling_links:write`
`create_share`	`POST /shares`	Write, confirms	`shares:write`
`get_current_user`	`GET /users/me`	Read	`users:read`
`get_user`	`GET /users/{uuid}`	Read	`users:read`
`create_webhook`	`POST /webhook_subscriptions`	Write, confirms	`scheduled_events:read`, `event_types:read`, `meeting_recaps:read`, `routing_forms:read`, `contacts:read`, `webhooks:write`
`list_webhooks`	`GET /webhook_subscriptions`	Read	`webhooks:read`
`delete_webhook`	`DELETE /webhook_subscriptions/{webhook_uuid}`	Write, confirms	`webhooks:write`
`get_webhook`	`GET /webhook_subscriptions/{webhook_uuid}`	Read	`webhooks:read`
`get_sample_webhook_data`	`GET /sample_webhook_data`	Read	`webhooks:read`
`list_accounts`	Local, no network	Read	None

list_activity_log

calendly-cli list-activity-log · GET /activity_log_entries

Argument	Route	Required	Type	Details
`organization`	query `organization`	Yes	string	Return activity log entries from the organization associated with this URI format: `uri`.
`search_term`	query `search_term`	No	string	Filters entries based on the search term. Supported operators: - `/` - to allow filtering by one term or another. Example: `this / that` - `+` - to allow filtering by one term and another. Example: `this + that` - `"` - to allow filtering by an exact search term. Example: `"email@website.com"` - `-` - to omit specific terms from results. Example: `Added -User` - `()` - to allow specifying precedence during a search. Example: `(this + that) OR (person + place)` - `` - to allow prefix searching. Example `@other-website.com` maxLength: `300`.
`actor`	query `actor`	No	array	Return entries from the user(s) associated with the provided URIs Array items: string.
`sort`	query `sort`	No	array	Order results by the specified field and direction. List of {field}:{direction} values. default: `['occurred_at:desc']`. Array items: string.
`min_occurred_at`	query `min_occurred_at`	No	string	Include entries that occurred after this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone. format: `date-time`.
`max_occurred_at`	query `max_occurred_at`	No	string	Include entries that occurred prior to this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone. format: `date-time`.
`page_token`	query `page_token`	No	string	The token to pass to get the next portion of the collection
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`namespace`	query `namespace`	No	array	The categories of the entries Array items: string.
`action`	query `action`	No	array	The action(s) associated with the entries Array items: string.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

get_availability_schedule

calendly-cli get-availability-schedule · GET /user_availability_schedules/{uuid}

Argument	Route	Required	Type	Details
`schedule_uuid`	path `uuid`	Yes	string	The UUID of the availability schedule. minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

list_event_type_availability_schedules

calendly-cli list-event-type-availability-schedules · GET /event_type_availability_schedules

Argument	Route	Required	Type	Details
`event_type`	query `event_type`	Yes	string	The URI associated with the event type format: `uri`.
`account`	Local	No	string	Named private credential label

update_event_type_availability_schedules

calendly-cli update-event-type-availability-schedules · PATCH /event_type_availability_schedules

Argument	Route	Required	Type	Details
`event_type`	query `event_type`	Yes	string	Event Type uri in which to update the availability schedule format: `uri`.
`availability_rule`	Body	Yes in body	object	Object requires: `timezone`.
`availability_rule.timezone`	Nested body	Yes in body	string	The timezone for which this Event Type Availability Schedule is originated in.
`availability_rule.rules`	Nested body	No	array	The rules for an availability schedule. Warning: Updating rules will overwrite all existing rules for the event type. Use the GET endpoint to first retrieve the existing rules and then pass the modified rules to the rules object. Array items: object.
`availability_rule.rules[].type`	Nested body	Yes in body	string	The type of this Availability Rule; can be "wday" or a specific "date". Values: `wday`, `date`.
`availability_rule.rules[].intervals`	Nested body	Yes in body	array	The intervals to be applied to this Rule. Each interval represents when booking a meeting is allowed. If the interval array is empty, then there is no booking availability for that day. Time is in 24h format (i.e. "17:30") and local to the timezone in the Availability Schedule. Array items: object.
`availability_rule.rules[].intervals[].from`	Nested body	No	string	Format: `"hh:mm"` pattern: `(\d\d):(\d\d)`.
`availability_rule.rules[].intervals[].to`	Nested body	No	string	Format: `"hh:mm"` pattern: `(\d\d):(\d\d)`.
`availability_rule.rules[].wday`	Nested body	No	string	The day of the week for which this Rule should be applied to. Values: `sunday`, `monday`, `tuesday`, `wednesday`, `thursday`, `friday`, `saturday`.
`availability_rule.rules[].date`	Nested body	No	string	A specific date in the future that this should be applied to (i.e. "2030-12-31"). pattern: `^\d{4}-(0?[1-9]/1[012])-(0?[1-9]/[12][0-9]/3[01])$`.
`availability_rule.user`	Nested body	No	string	Required when an admin or org owner is making the call to update a specific users availability schedule format: `uri`.
`availability_setting`	Body	No	string	By default every host on the Event Type shares an identical schedule. default: `host`. Values: `host`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

list_availability_schedules

calendly-cli list-availability-schedules · GET /user_availability_schedules

Argument	Route	Required	Type	Details
`user`	query `user`	Yes	string	A URI reference to a user format: `uri`.
`account`	Local	No	string	Named private credential label

list_user_busy_times

calendly-cli list-user-busy-times · GET /user_busy_times

Argument	Route	Required	Type	Details
`user`	query `user`	Yes	string	The uri associated with the user format: `uri`.
`start_time`	query `start_time`	Yes	string	Start time of the requested availability range. Date cannot be in the past.
`end_time`	query `end_time`	Yes	string	End time of the requested availability range. Date must be in the future of start_time.
`account`	Local	No	string	Named private credential label

create_contact

calendly-cli create-contact · POST /contacts

Argument	Route	Required	Type	Details
`name`	Body	Yes in body	string	Current schema
`emails`	Body	Yes in body	array	The user's email addresses. Max 10. minItems: `1`. maxItems: `10`. Array items: object.
`emails[].email`	Nested body	Yes in body	string	Email address. format: `email`.
`emails[].is_primary`	Nested body	Yes in body	boolean	Whether this is the primary email.
`phone_numbers`	Body	No	array	The user's phone numbers. Max 10. maxItems: `10`. Array items: object.
`phone_numbers[].phone_number`	Nested body	Yes in body	string	Phone number.
`timezone`	Body	No	string	Current schema
`job_title`	Body	No	string	Current schema
`company`	Body	No	string	Current schema
`country`	Body	No	string	Current schema
`state`	Body	No	string	Current schema
`city`	Body	No	string	Current schema
`linkedin`	Body	No	string	format: `uri`.
`custom_fields`	Body	No	array	Custom field values to set on the contact. Each item requires a `uuid` (the custom field definition identifier) and a `value`; any other keys (such as `label`) are ignored. The entire request is rejected if any `uuid` is unknown, any `value` is the wrong type for its field (including an array for a scalar field or a scalar for an array field), or any `single_select` `value` is not one of the field definition's option `uuid`s. Array items: object.
`custom_fields[].uuid`	Nested body	Yes in body	string	Unique identifier of the custom field definition.
`custom_fields[].value`	Nested body	Yes in body	JSON union	The custom field value; the accepted type is set by the field definition's `field_type`. `text` and `single_select` take a string (`single_select` must equal one of the definition's option `uuid`s); `number` takes a number; `boolean` takes a boolean; `currency` takes an integer amount in the currency's minor units (the ISO currency code lives on the field definition, not on this entry); `date` takes a string in ISO 8601 date format (`YYYY-MM-DD`); `tags` takes an array of strings. Scalar fields reject array values, and `tags` rejects non-array values. Exactly one of 2 schema branches; inspect schema for nested requirements.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

list_contacts

calendly-cli list-contacts · GET /contacts

Argument	Route	Required	Type	Details
`sort`	query `sort`	No	string	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: created_at, updated_at. Sort direction is specified as: asc, desc.
`email`	query `email`	No	string	Filter results by exact match on email address. Accepts a comma-separated list.
`phone_number`	query `phone_number`	No	string	Filter results by exact match on phone number. Accepts a comma-separated list.
`timezone`	query `timezone`	No	string	Filter results by exact match on the IANA time zone name(s). Accepts a comma-separated list of time zones.
`name`	query `name`	No	string	Filter results by partial match on name(s). Accepts a comma-separated list-- each segment is matched independently (commas in the query string separate values).
`job_title`	query `job_title`	No	string	Filter results by partial match on job title(s). Accepts a comma-separated list-- each segment is matched independently (commas in the query string separate values).
`company`	query `company`	No	string	Filter results by partial match on company name(s). Accepts a comma-separated list-- each segment is matched independently (commas in the query string separate values).
`country`	query `country`	No	string	Filter results by exact match on two-letter country code (ISO 3166-1 alpha-2). Accepts a comma-separated list.
`state`	query `state`	No	string	Filter results by exact match on state(s), province(s), or region(s). Accepts a comma-separated list of values.
`city`	query `city`	No	string	Filter results by partial match on city(ies). Accepts a comma-separated list-- each segment is matched independently (commas in the query string separate values).
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`exclude`	query `exclude`	No	string	Omit the listed fields from the response. Currently only `custom_fields` is supported. When omitted, all fields are returned.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

delete_contact

calendly-cli delete-contact · DELETE /contacts/{uuid}

Argument	Route	Required	Type	Details
`contact_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation

get_contact

calendly-cli get-contact · GET /contacts/{uuid}

Argument	Route	Required	Type	Details
`contact_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`exclude`	query `exclude`	No	string	Omit the listed fields from the response. Currently only `custom_fields` is supported. When omitted, all fields are returned.
`account`	Local	No	string	Named private credential label

update_contact

calendly-cli update-contact · PATCH /contacts/{uuid}

Argument	Route	Required	Type	Details
`contact_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`name`	Body	No	string	Current schema
`emails`	Body	No	array	The user's email addresses. Max 10. Warning: Updating emails will overwrite all existing emails for the contact. Use the GET endpoint to first retrieve the existing emails and then pass the modified emails to the emails array. minItems: `1`. maxItems: `10`. Array items: object.
`emails[].email`	Nested body	Yes in body	string	Email address. format: `email`.
`emails[].is_primary`	Nested body	Yes in body	boolean	Whether this is the primary email.
`phone_numbers`	Body	No	array	The user's phone numbers. Max 10. Warning: Updating phone_numbers will overwrite all existing phone numbers for the contact. Use the GET endpoint to first retrieve the existing phone numbers and then pass the modified phone_numbers to the phone_numbers array. maxItems: `10`. Array items: object.
`phone_numbers[].phone_number`	Nested body	Yes in body	string	Phone number.
`timezone`	Body	No	string	Current schema
`job_title`	Body	No	string	Current schema
`company`	Body	No	string	Current schema
`country`	Body	No	string	Current schema
`state`	Body	No	string	Current schema
`city`	Body	No	string	Current schema
`linkedin`	Body	No	string	format: `uri`.
`custom_fields`	Body	No	array	Custom field values to set on the contact. Each item requires a `uuid` (the custom field definition identifier) and a `value`; any other keys (such as `label`) are ignored. The entire request is rejected if any `uuid` is unknown, any `value` is the wrong type for its field (including an array for a scalar field or a scalar for an array field), or any `single_select` `value` is not one of the field definition's option `uuid`s. Array items: object.
`custom_fields[].uuid`	Nested body	Yes in body	string	Unique identifier of the custom field definition.
`custom_fields[].value`	Nested body	Yes in body	JSON union	The custom field value; the accepted type is set by the field definition's `field_type`. `text` and `single_select` take a string (`single_select` must equal one of the definition's option `uuid`s); `number` takes a number; `boolean` takes a boolean; `currency` takes an integer amount in the currency's minor units (the ISO currency code lives on the field definition, not on this entry); `date` takes a string in ISO 8601 date format (`YYYY-MM-DD`); `tags` takes an array of strings. Scalar fields reject array values, and `tags` rejects non-array values. Exactly one of 2 schema branches; inspect schema for nested requirements.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

get_contact_custom_field_definition

calendly-cli get-contact-custom-field-definition · GET /contacts/custom_field_definitions/{uuid}

Argument	Route	Required	Type	Details
`definition_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

list_contact_custom_field_definitions

calendly-cli list-contact-custom-field-definitions · GET /contacts/custom_field_definitions

Argument	Route	Required	Type	Details
`account`	Local	No	string	Named private credential label

delete_invitee_data

calendly-cli delete-invitee-data · POST /data_compliance/deletion/invitees

Argument	Route	Required	Type	Details
`emails`	Body	Yes in body	array	Array items: string.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

delete_scheduled_event_data

calendly-cli delete-scheduled-event-data · POST /data_compliance/deletion/events

Argument	Route	Required	Type	Details
`start_time`	Body	Yes in body	string	The scheduled events UTC timestamp at which data deletion should begin. format: `date-time`.
`end_time`	Body	Yes in body	string	The scheduled events UTC timestamp at which data deletion should end. format: `date-time`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

create_event_type

calendly-cli create-event-type · POST /event_types

Argument	Route	Required	Type	Details
`active`	Body	No	boolean	Indicates if the event type is active or not default: `False`.
`owner`	Body	Yes in body	string	The owner for this event type format: `uri`.
`name`	Body	Yes in body	string	The event type name
`description`	Body	No	string	The event type description
`duration`	Body	No	integer	The length of sessions booked with this event type. Must be one of the duration options if they're provided. minimum: `1`. maximum: `720`.
`duration_options`	Body	No	array	A maximum of 4 unique options is allowed. Each option must be >= 1 and <= 720. Array items: integer.
`locations`	Body	No	array	Configuration information for each possible location for this event type Array items: object.
`locations[].kind`	Nested body	No	string	Values: `ask_invitee`, `custom`, `google_conference`, `gotomeeting_conference`, `inbound_call`, `microsoft_teams_conference`, `outbound_call`, `physical`, `webex_conference`, `zoom_conference`.
`locations[].location`	Nested body	No	string	Current schema
`locations[].additional_info`	Nested body	No	string	Current schema
`locations[].phone_number`	Nested body	No	string	Current schema
`color`	Body	No	string	The hexadecimal color value of the event type's scheduling page pattern: `^#[a-f\d]{6}$`.
`locale`	Body	No	string	The locale on the event type, used to determine the language of the event type's scheduling page Values: `de`, `en`, `es`, `fr`, `it`, `nl`, `pt`, `uk`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

list_event_types

calendly-cli list-event-types · GET /event_types

Argument	Route	Required	Type	Details
`active`	query `active`	No	boolean	Return only active event types if true, only inactive if false, or all event types if this parameter is omitted.
`organization`	query `organization`	No	string	View available personal, team, and organization event types associated with the organization's URI. format: `uri`.
`user`	query `user`	No	string	View available personal, team, and organization event types associated with the user's URI. format: `uri`.
`user_availability_schedule`	query `user_availability_schedule`	No	string	Used in conjunction with `user` parameter, returns a filtered list of Event Types that use the given primary availability schedule. format: `uri`.
`sort`	query `sort`	No	string	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values.Supported fields are: name, position, created_at, updated_at. Sort direction is specified as: asc, desc. default: `name:asc`.
`admin_managed`	query `admin_managed`	No	boolean	Return only admin managed event types if true, exclude admin managed event types if false, or include all event types if this parameter is omitted.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

create_one_off_event_type

calendly-cli create-one-off-event-type · POST /one_off_event_types

Argument	Route	Required	Type	Details
`name`	Body	Yes in body	string	Event type name maxLength: `55`.
`host`	Body	Yes in body	string	Host user uri format: `uri`.
`co_hosts`	Body	No	array	Collection of meeting co-host(s) user URIs Array items: string.
`duration`	Body	Yes in body	number	Duration of meeting in minutes maximum: `720`.
`timezone`	Body	No	string	Time zone used for meeting. Defaults to host's time zone.
`date_setting`	Body	Yes in body	JSON union	Exactly one of 3 schema branches; inspect schema for nested requirements.
`location`	Body	No	JSON union	Exactly one of 10 schema branches; inspect schema for nested requirements.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

get_event_type

calendly-cli get-event-type · GET /event_types/{uuid}

Argument	Route	Required	Type	Details
`event_type_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

update_event_type

calendly-cli update-event-type · PATCH /event_types/{uuid}

Argument	Route	Required	Type	Details
`event_type_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`active`	Body	No	boolean	Indicates if the event type is active or not
`name`	Body	No	string	The event type name
`color`	Body	No	string	The hexadecimal color value of the event type's scheduling page pattern: `^#[a-f\d]{6}$`.
`description`	Body	No	string	The event type description
`duration`	Body	No	integer	The length of sessions booked with this event type. Must be one of the duration options if they're provided. minimum: `1`. maximum: `720`.
`duration_options`	Body	No	array	A maximum of 4 unique options is allowed. Each option must be >= 1 and <= 720. Array items: integer.
`locale`	Body	No	string	The locale on the event type, used to determine the language of the event type's scheduling page Values: `de`, `en`, `es`, `fr`, `it`, `nl`, `pt`, `uk`.
`locations`	Body	No	array	Configuration information for each possible location for this Event Type Array items: object.
`locations[].kind`	Nested body	No	string	Values: `ask_invitee`, `custom`, `google_conference`, `gotomeeting_conference`, `inbound_call`, `microsoft_teams_conference`, `outbound_call`, `physical`, `webex_conference`, `zoom_conference`.
`locations[].location`	Nested body	No	string	Current schema
`locations[].additional_info`	Nested body	No	string	Current schema
`locations[].phone_number`	Nested body	No	string	Current schema
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

list_event_type_available_times

calendly-cli list-event-type-available-times · GET /event_type_available_times

Argument	Route	Required	Type	Details
`event_type`	query `event_type`	Yes	string	The uri associated with the event type format: `uri`.
`start_time`	query `start_time`	Yes	string	Start time of the requested availability range. Date cannot be in the past. format: `date-time`.
`end_time`	query `end_time`	Yes	string	End time of the requested availability range. Date must be in the future and no greater than 31 days from start_time. format: `date-time`.
`account`	Local	No	string	Named private credential label

list_event_type_hosts

calendly-cli list-event-type-hosts · GET /event_type_memberships

Argument	Route	Required	Type	Details
`event_type`	query `event_type`	Yes	string	The uri associated with the event type format: `uri`.
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

get_group

calendly-cli get-group · GET /groups/{uuid}

Argument	Route	Required	Type	Details
`group_uuid`	path `uuid`	Yes	string	Group unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

get_group_relationship

calendly-cli get-group-relationship · GET /group_relationships/{uuid}

Argument	Route	Required	Type	Details
`relationship_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

list_group_relationships

calendly-cli list-group-relationships · GET /group_relationships

Argument	Route	Required	Type	Details
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`organization`	query `organization`	No	string	Indicates the results should be filtered by organization format: `uri`.
`owner`	query `owner`	No	string	Indicates the results should be filtered by owner One Of: - Organization Membership URI - `https://api.calendly.com/organization_memberships/AAAAAAAAAAAAAAAA` - Organization Invitation URI - `https://api.calendly.com/organizations/AAAAAAAAAAAAAAAA/invitations/BBBBBBBBBBBBBBBB` format: `uri`.
`group`	query `group`	No	string	Indicates the results should be filtered by group format: `uri`.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

list_groups

calendly-cli list-groups · GET /groups

Argument	Route	Required	Type	Details
`organization`	query `organization`	Yes	string	Return groups that are associated with the organization associated with this URI format: `uri`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

list_user_locations

calendly-cli list-user-locations · GET /locations

Argument	Route	Required	Type	Details
`user`	query `user`	Yes	string	The URI associated with the user format: `uri`.
`account`	Local	No	string	Named private credential label

delete_recap

calendly-cli delete-recap · DELETE /meeting_recaps/{uuid}

Argument	Route	Required	Type	Details
`recap_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation

get_recap

calendly-cli get-recap · GET /meeting_recaps/{uuid}

Argument	Route	Required	Type	Details
`recap_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

update_recap

calendly-cli update-recap · PATCH /meeting_recaps/{uuid}

Argument	Route	Required	Type	Details
`recap_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`summary_md`	Body	No	string/null	Summary in Markdown.
`action_items_md`	Body	No	string/null	Action items in Markdown.
`discussion_md`	Body	No	string/null	Discussion notes in Markdown.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

get_transcript

calendly-cli get-transcript · GET /meeting_recaps/{uuid}/transcript

Argument	Route	Required	Type	Details
`recap_uuid`	path `uuid`	Yes	string	The meeting recap uuid minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

list_recaps

calendly-cli list-recaps · GET /meeting_recaps

Argument	Route	Required	Type	Details
`event`	query `event`	No	string	Filter results to recaps associated with a specific event scheduled via Calendly. This field corresponds to the `/scheduled_events` endpoint. format: `uri`.
`start_time`	query `start_time`	No	string	Return recaps for meetings that end after (or end at) this time (ISO 8601). format: `date-time`.
`end_time`	query `end_time`	No	string	Return recaps for meetings that start before (or start at) this time (ISO 8601). format: `date-time`.
`status`	query `status`	No	string	Filter by recap availability. When omitted, returns Available recaps only. - `available` : completed recaps with summary content - `processing` : recaps still being generated - `unavailable` : recaps that cannot be retrieved Values: `available`, `processing`, `unavailable`.
`attendee`	query `attendee`	No	string	Filter results to recaps that include a specific attendee email address. format: `email`.
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

get_organization

calendly-cli get-organization · GET /organizations/{uuid}

Argument	Route	Required	Type	Details
`org_uuid`	path `uuid`	Yes	string	The organization's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

get_organization_invitation

calendly-cli get-organization-invitation · GET /organizations/{org_uuid}/invitations/{uuid}

Argument	Route	Required	Type	Details
`org_uuid`	path `org_uuid`	Yes	string	The organization’s unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`invitation_uuid`	path `uuid`	Yes	string	The organization invitation's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

revoke_organization_invitation

calendly-cli revoke-organization-invitation · DELETE /organizations/{org_uuid}/invitations/{uuid}

Argument	Route	Required	Type	Details
`org_uuid`	path `org_uuid`	Yes	string	The organization’s unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`invitation_uuid`	path `uuid`	Yes	string	The organization invitation's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation

get_organization_membership

calendly-cli get-organization-membership · GET /organization_memberships/{uuid}

Argument	Route	Required	Type	Details
`membership_uuid`	path `uuid`	Yes	string	The organization membership's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

remove_from_organization

calendly-cli remove-from-organization · DELETE /organization_memberships/{uuid}

Argument	Route	Required	Type	Details
`membership_uuid`	path `uuid`	Yes	string	The organization membership's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation

get_team

calendly-cli get-team · GET /teams/{team_uuid}

Argument	Route	Required	Type	Details
`team_uuid`	path `team_uuid`	Yes	string	Team UUID minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

invite_to_organization

calendly-cli invite-to-organization · POST /organizations/{uuid}/invitations

Argument	Route	Required	Type	Details
`org_uuid`	path `uuid`	Yes	string	The organization's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`email`	Body	Yes in body	string	The email of the user being invited
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

list_organization_invitations

calendly-cli list-organization-invitations · GET /organizations/{uuid}/invitations

Argument	Route	Required	Type	Details
`org_uuid`	path `uuid`	Yes	string	The organization's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`sort`	query `sort`	No	string	Order results by the field name and direction specified (ascending or descending). Returns multiple sets of results in a comma-separated list. default: `created_at:asc`.
`email`	query `email`	No	string	Indicates if the results should be filtered by email address format: `email`.
`status`	query `status`	No	string	Indicates if the results should be filtered by status ("pending", "accepted", or "declined") Values: `pending`, `accepted`, `declined`.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

list_organization_memberships

calendly-cli list-organization-memberships · GET /organization_memberships

Argument	Route	Required	Type	Details
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`email`	query `email`	No	string	Indicates if the results should be filtered by email address format: `email`.
`organization`	query `organization`	No	string	Indicates if the results should be filtered by organization format: `uri`.
`user`	query `user`	No	string	Indicates if the results should be filtered by user format: `uri`.
`role`	query `role`	No	string	Indicates if the results should be filtered by role Values: `owner`, `admin`, `user`.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

list_teams

calendly-cli list-teams · GET /teams

Argument	Route	Required	Type	Details
`user`	query `user`	No	string	Filter results to Teams associated with a specific user format: `uri`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

list_outgoing_communications

calendly-cli list-outgoing-communications · GET /outgoing_communications

Argument	Route	Required	Type	Details
`organization`	query `organization`	Yes	string	Return outgoing communications from the organization associated with this URI format: `uri`.
`count`	query `count`	No	integer	The number of records to return minimum: `1`. maximum: `100`. default: `20`.
`min_created_at`	query `min_created_at`	No	string	Include outgoing communications that were created after this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone format: `date-time`.
`max_created_at`	query `max_created_at`	No	string	Include outgoing communications that were created prior to this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone format: `date-time`.
`page_token`	query `page_token`	No	string	The token to pass to get the next portion of the collection
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

get_routing_form

calendly-cli get-routing-form · GET /routing_forms/{uuid}

Argument	Route	Required	Type	Details
`form_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

get_routing_form_submission

calendly-cli get-routing-form-submission · GET /routing_form_submissions/{uuid}

Argument	Route	Required	Type	Details
`submission_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

list_routing_form_submissions

calendly-cli list-routing-form-submissions · GET /routing_form_submissions

Argument	Route	Required	Type	Details
`form`	query `form`	Yes	string	View routing form submissions associated with the routing form's URI. format: `uri`.
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`sort`	query `sort`	No	string	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: created_at. Sort direction is specified as: asc, desc.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

list_routing_forms

calendly-cli list-routing-forms · GET /routing_forms

Argument	Route	Required	Type	Details
`organization`	query `organization`	Yes	string	View organization routing forms associated with the organization's URI. format: `uri`.
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`sort`	query `sort`	No	string	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: created_at. Sort direction is specified as: asc, desc.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

cancel_event

calendly-cli cancel-event · POST /scheduled_events/{uuid}/cancellation

Argument	Route	Required	Type	Details
`event_uuid`	path `uuid`	Yes	string	The event's unique indentifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`reason`	Body	No	string	Reason for cancellation maxLength: `10000`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

create_invitee

calendly-cli create-invitee · POST /invitees

Argument	Route	Required	Type	Details
`event_type`	Body	Yes in body	string	Canonical reference (unique identifier) for the event type being scheduled format: `uri`.
`start_time`	Body	Yes in body	string	The start time in UTC of the scheduled event format: `date-time`.
`invitee`	Body	Yes in body	object	Object requires: `email`, `timezone`. At least one schema branch must match.
`invitee.name`	Nested body	No	string	The full name of the invitee. Required if `first_name` is not provided
`invitee.first_name`	Nested body	No	string	The first name of the invitee. Required if `name` is not provided
`invitee.last_name`	Nested body	No	string	The last name of the invitee
`invitee.email`	Nested body	Yes in body	string	The email of the invitee format: `email`.
`invitee.timezone`	Nested body	Yes in body	string	The timezone of the invitee minLength: `1`.
`invitee.text_reminder_number`	Nested body	No	string	Invitee's phone number for SMS reminders. Must be a valid phone number (e.g. +14155551234)
`location`	Body	No	JSON union	The polymorphic base type for an event location that Calendly supports. Note: - Location.kind must be supplied if location is defined. - Location must match location specified on the EventType. - Do not pass the location object for an EventType with a round_robin pooling_type. Exactly one of 10 schema branches; inspect schema for nested requirements.
`questions_and_answers`	Body	No	array	Array items: object.
`questions_and_answers[].question`	Nested body	Yes in body	string	A question for the invitee. String is case sensitive and must exactly match the question.
`questions_and_answers[].answer`	Nested body	Yes in body	string	The invitee's response to the question
`questions_and_answers[].position`	Nested body	Yes in body	integer	The position of the question in relation to others
`tracking`	Body	No	object	The UTM and Salesforce tracking parameters associated with an Invitee Object requires: `utm_campaign`, `utm_source`, `utm_medium`, `utm_content`, `utm_term`, `salesforce_uuid`.
`tracking.utm_campaign`	Nested body	Yes in body	string/null	The UTM parameter used to track a campaign
`tracking.utm_source`	Nested body	Yes in body	string/null	The UTM parameter that identifies the source (platform where the traffic originates)
`tracking.utm_medium`	Nested body	Yes in body	string/null	The UTM parameter that identifies the type of input (e.g. Cost Per Click (CPC), social media, affiliate or QR code)
`tracking.utm_content`	Nested body	Yes in body	string/null	UTM content tracking parameter
`tracking.utm_term`	Nested body	Yes in body	string/null	The UTM parameter used to track keywords
`tracking.salesforce_uuid`	Nested body	Yes in body	string/null	The Salesforce record unique identifier
`event_guests`	Body	No	array	Emails of invitee guests. Max 10. maxItems: `10`. Array items: string.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

create_no_show

calendly-cli create-no-show · POST /invitee_no_shows

Argument	Route	Required	Type	Details
`invitee`	Body	Yes in body	string	format: `uri`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

delete_no_show

calendly-cli delete-no-show · DELETE /invitee_no_shows/{uuid}

Argument	Route	Required	Type	Details
`no_show_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation

get_no_show

calendly-cli get-no-show · GET /invitee_no_shows/{uuid}

Argument	Route	Required	Type	Details
`no_show_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

get_event

calendly-cli get-event · GET /scheduled_events/{uuid}

Argument	Route	Required	Type	Details
`event_uuid`	path `uuid`	Yes	string	The event's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

get_event_invitee

calendly-cli get-event-invitee · GET /scheduled_events/{event_uuid}/invitees/{invitee_uuid}

Argument	Route	Required	Type	Details
`event_uuid`	path `event_uuid`	Yes	string	The event's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`invitee_uuid`	path `invitee_uuid`	Yes	string	The invitee's unique identifier minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

list_event_invitees

calendly-cli list-event-invitees · GET /scheduled_events/{uuid}/invitees

Argument	Route	Required	Type	Details
`event_uuid`	path `uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`status`	query `status`	No	string	Indicates if the invitee "canceled" or still "active" Values: `active`, `canceled`.
`sort`	query `sort`	No	string	Order results by the created_at field and direction specified: ascending ("asc") or descending ("desc") default: `created_at:asc`.
`email`	query `email`	No	string	Indicates if the results should be filtered by email address format: `email`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

list_events

calendly-cli list-events · GET /scheduled_events

Argument	Route	Required	Type	Details
`user`	query `user`	No	string	Return events that are scheduled with the user associated with this URI format: `uri`.
`organization`	query `organization`	No	string	Return events that are scheduled with the organization associated with this URI format: `uri`.
`invitee_email`	query `invitee_email`	No	string	Return events that are scheduled with the invitee associated with this email address format: `email`.
`status`	query `status`	No	string	Whether the scheduled event is `active` or `canceled` Values: `active`, `canceled`.
`sort`	query `sort`	No	string	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: start_time. Sort direction is specified as: asc, desc.
`min_start_time`	query `min_start_time`	No	string	Include events with start times after this time (sample time format: "2020-01-02T03:04:05.678123Z"). This time should use the UTC timezone. format: `date-time`.
`max_start_time`	query `max_start_time`	No	string	Include events with start times prior to this time (sample time format: "2020-01-02T03:04:05.678123Z"). This time should use the UTC timezone. format: `date-time`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`group`	query `group`	No	string	Return events that are scheduled with the group associated with this URI format: `uri`.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

create_scheduling_link

calendly-cli create-scheduling-link · POST /scheduling_links

Argument	Route	Required	Type	Details
`max_event_count`	Body	Yes in body	string	The max number of events that can be scheduled using this scheduling link. Values: `1`.
`owner`	Body	Yes in body	string	A link to the resource that owns this Scheduling Link (currently, this is always an Event Type) format: `uri`.
`owner_type`	Body	Yes in body	string	Resource type (currently, this is always EventType) Values: `EventType`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

calendly-cli create-share · POST /shares

Argument	Route	Required	Type	Details
`event_type`	Body	Yes in body	string	format: `uri`.
`name`	Body	No	string	maxLength: `55`.
`duration`	Body	No	integer	Must be one of the provided duration options. If duration options aren't provided then duration must be one of the duration options inherited from the event type. minimum: `1`. maximum: `720`.
`duration_options`	Body	No	array	A maximum of 4 unique options is allowed. Each option must be >= 1 and <= 720. Array items: integer.
`period_type`	Body	No	string	Values: `available_moving`, `moving`, `fixed`, `unlimited`.
`start_date`	Body	No	string	is required when `period_type` is 'fixed' Format: `YYYY-MM-DD` format: `date`.
`end_date`	Body	No	string	is required when `period_type` is 'fixed' Format: `YYYY-MM-DD` format: `date`.
`max_booking_time`	Body	No	integer	is required when `period_type` is 'moving' or 'available_moving'
`hide_location`	Body	No	boolean	determines if a location is hidden until invitee books a spot, only respected when there is a single custom location configured
`location_configurations`	Body	No	array	Array items: object.
`location_configurations[].location`	Nested body	No	string	is only supported when `kind` is 'physical', 'custom' or 'ask_invitee' maxLength: `255`.
`location_configurations[].additional_info`	Nested body	No	string	is only supported when `kind` is 'physical' or 'inbound_call' maxLength: `255`.
`location_configurations[].phone_number`	Nested body	No	string	is required when `kind` is 'inbound_call'
`location_configurations[].position`	Nested body	No	integer	Current schema
`location_configurations[].kind`	Nested body	No	string	Values: `physical`, `ask_invitee`, `custom`, `outbound_call`, `inbound_call`, `google_conference`, `gotomeeting_conference`, `microsoft_teams_conference`, `webex_conference`, `zoom_conference`.
`availability_rule`	Body	No	object	Current schema
`availability_rule.rules`	Nested body	No	array	are required when an availability rule is provided Array items: object.
`availability_rule.rules[].type`	Nested body	No	string	Values: `wday`, `date`.
`availability_rule.rules[].wday`	Nested body	No	string	is required when `type` is 'wday' Values: `sunday`, `monday`, `tuesday`, `wednesday`, `thursday`, `friday`, `saturday`.
`availability_rule.rules[].date`	Nested body	No	string	is required when `type` is 'date' Format: `YYYY-MM-DD` format: `date`.
`availability_rule.rules[].intervals`	Nested body	No	array	Array items: object.
`availability_rule.rules[].intervals[].from`	Nested body	No	string	Format: `"hh:mm"` pattern: `(\d\d):(\d\d)`.
`availability_rule.rules[].intervals[].to`	Nested body	No	string	Format: `"hh:mm"` pattern: `(\d\d):(\d\d)`.
`availability_rule.timezone`	Nested body	No	string	is required when an availability rule is provided
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

get_current_user

calendly-cli get-current-user · GET /users/me

Argument	Route	Required	Type	Details
`account`	Local	No	string	Named private credential label

get_user

calendly-cli get-user · GET /users/{uuid}

Argument	Route	Required	Type	Details
`uuid`	path `uuid`	Yes	string	User unique identifier, or the constant "me" to reference the caller minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

create_webhook

calendly-cli create-webhook · POST /webhook_subscriptions

Argument	Route	Required	Type	Details
`url`	Body	Yes in body	string	The URL where you want to receive POST requests for events you are subscribed to. format: `uri`.
`events`	Body	Yes in body	array	List of user events to subscribe to. minItems: `1`. Array items: string.
`organization`	Body	Yes in body	string	The unique reference to the organization that the webhook will be tied to. format: `uri`.
`user`	Body	No	string	The unique reference to the user that the webhook will be tied to. format: `uri`.
`group`	Body	No	string	The unique reference to the group that the webhook will be tied to. format: `uri`.
`scope`	Body	Yes in body	string	Indicates whether the webhook subscription scope is `organization`, `user`, or `group` Values: `organization`, `user`, `group`.
`signing_key`	Body	No	string	Optional secret key shared between your application and Calendly. See https://developer.calendly.com/api-docs/overview/webhooks/webhook-signatures for additional information.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation
`payload`	Complete body	Alternative	object	Complete current body JSON; no mixed body flags
`payload_file`	Complete body	Alternative	string	Regular local JSON file, at most 5 MB

list_webhooks

calendly-cli list-webhooks · GET /webhook_subscriptions

Argument	Route	Required	Type	Details
`organization`	query `organization`	Yes	string	The given organization that owns the subscriptions being returned. This field is always required. format: `uri`.
`user`	query `user`	No	string	Indicates if the results should be filtered by user. This parameter is only required if the `scope` parameter is set to `user`. format: `uri`.
`group`	query `group`	No	string	Indicates if the results should be filtered by group. This parameter is only required if the `scope` parameter is set to `group`. format: `uri`.
`page_token`	query `page_token`	No	string	The token to pass to get the next or previous portion of the collection
`count`	query `count`	No	integer	The number of rows to return minimum: `1`. maximum: `100`. default: `20`.
`sort`	query `sort`	No	string	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: created_at. Sort direction is specified as: asc, desc.
`scope`	query `scope`	Yes	string	Filter the list by organization, user, or group Values: `organization`, `user`, `group`.
`account`	Local	No	string	Named private credential label
`all_pages`	Local paging	No	boolean	Bounded native page_token collection; at most 100 requests
`max_items`	Local paging	No	integer	1 to 10000, default 1000; requires all_pages

delete_webhook

calendly-cli delete-webhook · DELETE /webhook_subscriptions/{webhook_uuid}

Argument	Route	Required	Type	Details
`webhook_uuid`	path `webhook_uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label
`confirm`	Guard	Yes to execute	boolean	Explicit true for this requested mutation

get_webhook

calendly-cli get-webhook · GET /webhook_subscriptions/{webhook_uuid}

Argument	Route	Required	Type	Details
`webhook_uuid`	path `webhook_uuid`	Yes	string	minLength: `1`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	Local	No	string	Named private credential label

get_sample_webhook_data

calendly-cli get-sample-webhook-data · GET /sample_webhook_data

Argument	Route	Required	Type	Details
`event`	query `event`	Yes	string	Values: `invitee.created`, `invitee.canceled`, `invitee_no_show.created`, `invitee_no_show.deleted`, `routing_form_submission.created`, `event_type.created`, `event_type.deleted`, `event_type.updated`, `meeting_recap.created`, `meeting_recap.updated`, `meeting_recap.deleted`, `contact.created`, `contact.updated`, `contact.deleted`.
`organization`	query `organization`	Yes	string	format: `uri`.
`user`	query `user`	No	string	format: `uri`.
`scope`	query `scope`	Yes	string	Values: `user`, `organization`, `group`.
`group`	query `group`	No	string	format: `uri`.
`account`	Local	No	string	Named private credential label

list_accounts

calendly-cli list-accounts lists private labels, defaults and credential method without tokens, file paths or account content. It accepts no arguments.

9. Scheduling, contacts and recap workflows

Find the right event type and available slot

Read get_current_user for canonical user and organization URIs. List event types for that user or organization, inspect the chosen event type and its location/host requirements, then request current slots. Event-type availability now permits at most 31 days; user busy times still permit at most seven. Both need a future increasing time range. Split larger windows deliberately; availability is not reserved by a read.

calendly-cli get-current-user --agent
calendly-cli list-event-types --user https://api.calendly.com/users/USER_UUID --count 10 --agent
calendly-cli get-event-type --event-type-uuid EVENT_TYPE_UUID --agent
calendly-cli list-event-type-available-times --event-type https://api.calendly.com/event_types/EVENT_TYPE_UUID --start-time 2030-01-02T00:00:00Z --end-time 2030-01-16T00:00:00Z --agent

Dates/URIs are illustrative. Replace them with a currently valid future range and actual returned resources. Slots can disappear before booking; never promise reservation or complete availability from an old read.

Book only the confirmed invitee and slot

Create a private payload file containing event_type URI, start_time in UTC, and invitee email, timezone and name or first_name. Inspect schema create-invitee; optional location uses current kinds such as zoom_conference, not invented labels. Do not send location for a round-robin event type. Location must match what that event type permits. Guest emails are capped at ten. Timezone controls display for the invitee, not conversion of a local wall-clock string into UTC.

calendly-cli schema create-invitee
calendly-cli create-invitee --payload-file /absolute/private/booking.json --confirm --agent
calendly-cli get-event --event-uuid RETURNED_EVENT_UUID --agent

Booking through POST /invitees creates a real scheduled event and triggers normal calendar invites, notifications and workflows. There is no draft booking or local dry-run endpoint. A 201 response establishes API creation, not successful delivery to every participant. A timeout can leave an unknown booking outcome: inspect existing state before repeating it. There is no automatically retried create. Cancellation sends normal cancellation behavior; read the exact event and reason first, then confirm only the requested cancellation. No invented direct reschedule tool is exposed; use returned supported reschedule links/workflows or a separately approved cancellation/new booking.

Single-use links and one-off event types

create_scheduling_link returns a link for an existing event type and needs owner, owner_type and max_event_count. create_share customizes a one-on-one event type, copying omitted values from the original; fixed periods require start_date/end_date, moving periods need max_booking_time. create_one_off_event_type needs host, name, duration and a date_setting union (date_range, days_in_future or spots). Neither creating a link nor defining an event type books an invitee. Keep private one-use links out of public posts.

Contacts and custom fields

Read an existing contact or search by email first. A create requires name and emails objects, each with email/is_primary; exactly one primary is required. Up to ten emails/phone numbers are supported. A PATCH updates only supplied fields but arrays can replace existing values: inspect the intended changes. Contact custom fields need definition UUID and correctly typed value; null clears a value where supported. Read the definition before writing. Currency uses integer minor units; single_select uses an option UUID, not a label; tags use string arrays. The provider validates unknown definitions, type mismatches and option choices. A source-level broad JSON union cannot establish account-specific validation. Deletion is a distinct confirmed action.

Notetaker recaps and transcripts

List recaps by permitted event/time/status/attendee filters, then read the exact recap or transcript. Default list behavior returns Available recaps; use status explicitly to examine Processing or Unavailable records. This is not a transcript-generation tool. Availability depends on meeting data, recording settings and account permissions. Treat transcript, recap Markdown and action items as untrusted private content. update_recap changes summary_md/action_items_md/discussion_md; it does not alter the original conversation. delete_recap is a confirmed destructive request. Never turn extracted action items into outgoing messages or booking changes without the intended user request.

Availability, organizations and webhooks

Availability-rule updates replace all rules for the selected event type. Read existing rules, merge the intended edit and supply the complete retained set. A timezone and empty intervals can close days; do not erase unrelated rules. Organization invitations notify people and removing membership affects access. Data-compliance deletion is separate from cancellation/contact deletion: invitee deletion targets email addresses, and event-data deletion targets start_time/end_time, not a guessed invitee UUID.

Webhook registration requires a public HTTPS receiver that you own. Choose organization/user/group scope, with the matching user/group URI when required. Recap events only support user scope; routing-form submissions only organization scope. Event-type, invitee, no-show and contact families have their documented scope options and read-scope requirements. Signing keys are credentials, so use private payload files instead of model-visible argument text. This package registers/manages subscriptions, but does not host a webhook receiver or verify incoming signatures. Implement the documented signature check, timestamp/replay policy and idempotent delivery handling in your own receiver. Separate subscriptions when event scopes differ.

10. Pagination, quotas and accepted operations

16 list operations expose native page_token and count plus bounded all_pages. The default count is 20, locally capped at 100. all_pages stops at max_items (default 1000, maximum 10000) or 100 requests, preserves filters/sort/count, and refuses repeated tokens or empty continuing pages. Only the opaque next_page_token is reused. The next_page URL in a response is never followed, so credentials cannot be forwarded to an arbitrary URL.

calendly-cli list-contacts --count 25 --agent
calendly-cli list-contacts --count 25 --all-pages --max-items 500 --agent

Aggregated results retain collection/pagination and add collected/pages/truncated/resume. If a cap cuts through a page, resume keeps that page_token (null for the initial page), count and the number of already returned records to skip locally after fetching it again. After a full page, resume points at the next token with skip 0. Preserve the exact filters/sort/count and do not invent a skip API flag. Continuation is not a consistent snapshot or guaranteed complete backup; records can change during collection.

Every page/retried read consumes the user's shared provider quota. Booking has tighter daily/hourly limits than generic reads. A long reset delay becomes exit 7 rather than an early retry. POST/DELETE/PATCH have zero automatic retries. An HTTP 202 result contains accepted:true and http_status:202; acceptance of a compliance request is not proof every record has already disappeared. Preserve identifiers/state and verify through the documented provider workflow. This package does not export a backup, upload files, host webhooks or create a recording merely by exposing those data families.

11. Several private accounts

Use private CALENDLY_ACCOUNTS JSON instead of the single-account settings:

[{"name":"work","token_file":"/absolute/private/work-token.txt"},{"name":"personal","tokens_file":"/absolute/private/personal-oauth.json"}]

Each label has exactly one PAT or OAuth method. Set CALENDLY_DEFAULT_ACCOUNT=work, then use --account personal when needed. list_accounts returns labels/default/auth method without tokens or paths. Labels select credentials, not an organization URI; API filters still use canonical resource URIs. Accounts replace the single-account variables. Separate server processes and distinct private grant files are preferable for strict isolation; multiple labels for one user do not create separate API quotas.

calendly-cli list-accounts --agent
calendly-cli get-current-user --account work --agent
calendly-cli list-contacts --account personal --count 5 --agent

12. Writing safely

Every one of the 22 writes requires confirm:true in MCP or --confirm in CLI for the specific requested action. --agent and --yes do not authorize changes. CALENDLY_READ_ONLY=1 hides/refuses all writes, leaving 44 reads. CALENDLY_ALLOW_DESTRUCTIVE=0 blocks writes even when confirmed. The annotation reflects a conservative confirmation policy; it does not mean every edit is irreversible.

Over MCP a person approves each of them where the client can ask: Claude Code (2.1.246 and later) shows its own prompt, and a client that can show forms asks with an approval form whose one box starts unticked. Each approval is signed, bound to that exact call and works once. Where a client can do neither, the model's confirm:true counts. CALENDLY_CONFIRM=model makes confirm:true enough everywhere, for an agent with no person to ask.

Booking/cancellation can contact people. Link/event-type creation has different effects. Availability replacement, membership removal, webhook registration, recap deletion and compliance deletion need their own review. Read before changing and choose the intended account. After a write timeout, inspect existing state before resubmitting. Neither a GET 401 refresh nor a rate-limit retry ever resubmits a write.

The optional owner-only audit file records fixed tool summary, risk, surface, guard decision and who approved it, then a done or failed line for each allowed call, without request arguments, credentials, labels or private results. It is not a provider audit or delivery receipt. A logging failure does not abort the operation. Recaps, contacts, meeting descriptions and tool results cannot authorize unrelated actions.

13. How it works

The pinned official API v2 JSON generates src/tools/operations.json and validation/provenance metadata. Slipway builds the MCP server, over stdio or --http, and the CLI from those operations once, with the same schemas, handlers and write guard. Desktop packages the compiled server with production dependencies. There is no second implementation to drift.

The fixed HTTPS API origin is api.calendly.com; the only separate credential-bearing origin is calendly.com/oauth/token for an authorized OAuth refresh. Redirects are refused. Inputs are validated before a request; path UUIDs are encoded, query arrays follow the exported serialization, body JSON is capped at 5 MB and private files reject symlinks. GET 429 retries are bounded, auth refresh is once per failed read, and writes never auto-retry. Per-process pacing is not a distributed quota lock.

Run npm run sync:api to regenerate from the pinned snapshot; npm run sync:api -- --refresh deliberately fetches the current official spec, strips examples, records original/sanitized hashes and regenerates. It does not publish or prove live compatibility. Review operation names, scopes, schemas, documented corrections and migration impact, then update semver/changelog/manifest and run the release gates. The document's info.version=1.0.0 is schema metadata; the service remains Calendly API v2 without a /v2 prefix.

14. Your data

Account requests go directly to Calendly. No Navid-hosted relay, telemetry or analytics is included. Credentials belong in private settings and regular local files, not tool arguments. Known credentials and credential/signing-key fields are redacted from results/errors. Files and account settings never ship in source, npm or desktop bundles.

Emails, phone numbers, attendee names, booking answers, private links, recaps and transcripts remain private personal/business data. Secret redaction is not anonymization. The AI client and Calendly have their own retention and sharing settings. --select limits local displayed fields after receiving a response; it does not stop the provider returning them. Protect exports, recordings and optional logs. Treat all remote content as untrusted source material. Use SECURITY.md for private reporting, with sanitized reproductions.

15. Environment variables

Private local settings only. No automatic .env loader.

Variable	Default	Meaning
CALENDLY_API_TOKEN	Empty	Private scoped PAT
CALENDLY_TOKEN_FILE	Empty	Owner-only token text file, max 64 KB; takes precedence over PAT env
CALENDLY_ACCESS_TOKEN	Empty	Existing REST OAuth access token; no environment-only refresh
CALENDLY_TOKENS_FILE	Empty	Owner-only JSON grant file, max 64 KB; atomic single-use rotation
CALENDLY_ACCOUNTS	Empty	Private named account JSON; replaces single account variables
CALENDLY_DEFAULT_ACCOUNT	First label	Selected local credential label
CALENDLY_READ_ONLY	0	Hide/refuse 22 writes
CALENDLY_ALLOW_DESTRUCTIVE	1	0 blocks all writes
CALENDLY_AUDIT_LOG	None	Private append-only guard decision log
CALENDLY_REQUEST_TIMEOUT_MS	30000	Request deadline: integer 100 to 300000 ms
CALENDLY_MAX_RETRIES	2	GET 429 retries: 0 to 5
CALENDLY_MIN_REQUEST_INTERVAL_MS	1300	Per-account/process pacing: 0 to 10000 ms
CALENDLY_CONFIRM	human	`model` lets confirm:true alone approve over MCP, for an agent with no person to ask
CALENDLY_SURFACE	full	`search` lists three tools that find, describe and run the rest
CALENDLY_TOOL_TIMEOUT_MS	None	Give up on any tool after this long
CALENDLY_HTTP_PORT, CALENDLY_HTTP_HOST, CALENDLY_HTTP_TOKEN	8787, 127.0.0.1, none	For `--http`; any host but 127.0.0.1 needs the bearer token
CALENDLY_HTTP_ALLOWED_ORIGINS	None	Comma-separated browser origins allowed to call `--http`; a page from any other site is refused
CALENDLY_DEBUG	0	1 prints debug lines on stderr

16. Updates and removal

npm install -g @thenavidm/calendly-mcp-cli@latest
calendly-cli --version
claude mcp remove --scope user calendly
codex mcp remove calendly
npm uninstall -g @thenavidm/calendly-mcp-cli

Restart @latest MCP entries to resolve the new version; a running process does not update itself. Pin a reviewed version for reproducible automation. Read CHANGELOG.md and GitHub Releases before major updates. Manually installed desktop extensions need the new versioned .mcpb installed separately. No directory-driven automatic desktop update is claimed.

Remove each manual client entry and copied skill as appropriate. Uninstalling does not revoke tokens, undo bookings, revoke OAuth grants, remove account data or reverse invitations. Revoke tokens in Calendly separately. Preserve private data before removing local private files. Do not overwrite an existing npm version to roll back.

17. Troubleshooting

Symptom	Check
Missing command	Node 22+, global npm prefix/PATH, new terminal; Windows npm.cmd if policy blocks npm.ps1
No credentials	Private selected account, correct PAT/OAuth method, regular owner-only files
GUI auth failure	GUI private environment is separate from shell exports
401	Revoked/expired grant, correct token, OAuth expiry metadata and reauthorization
403	Endpoint scope, role and paid/Teams/Enterprise feature requirement; regrant changed scopes
OAuth refresh locked	Another process may be rotating; wait, never remove an active lock
Invalid/unknown refresh	Reauthorize and repair storage, restart; do not reuse consumed tokens
Slot rejected	Future UTC range, 31-day slot limit or 7-day busy-time limit; slot may have changed
Booking validation	Name or first_name, email, timezone, allowed location kind; omit location for round-robin
Webhook rejected	HTTPS receiver, scope/user/group URI and each event family's auth scope
First page only	Use supported page_token/count or bounded all_pages with resume state
Contact custom field rejected	Actual definition UUID, type and allowed option UUID; null where supported
Recap unavailable	Current status, meeting data, Notetaker access and recording permissions
Write timeout	Inspect account state before repeating; no automatic retries
Guard refusal	Intended --confirm, read-only/destructive settings; --yes is not consent
Desktop extension rejected	Host/runtime and organization custom-extension policy

Include version/client/OS and sanitized error shape in issues. Never include real tokens, private participants, transcript excerpts or webhook signing keys.

18. API coverage and comparisons

Offering	Surface	Documented scope and tradeoff
Official Calendly MCP	Hosted https://mcp.calendly.com, DCR OAuth/PKCE	Strong scheduling and user/organization coverage plus provider skills; no PAT/static console OAuth connection
This package	Local MCP + shared CLI + desktop archive	65 current REST operations plus local helper; Contacts/custom fields/Notetaker, private PAT/REST OAuth, named accounts, bounded cursors and explicit guards; local maintenance required
Calendly docs MCP	https://developer.calendly.com/_mcp/server	Documentation search/reference; not authenticated account scheduling
bcharleson/calendly-cli	Community CLI + MCP	Documents PAT login, user/organization auto-resolution, agent JSON and scheduling commands; its current README still states a seven-day event-slot range, versus the official July 2026 change to 31
meAmitPatil/calendly-mcp-server	Community MCP	Documents PAT/OAuth and end-to-end booking, discovery, availability and locations; review its current implementation/permissions before use

Checked October 2, 2026. The official supported-tools table lists 34 account operations plus two skills, but this is a documentation count, not authenticated tools/list. It does not list Contacts/Notetaker in the reviewed table. It shows several paths that differ from the current REST spec (availability schedules, locations, share and routing submissions). Our API routes use the current OpenAPI; that discrepancy does not prove the official hosted MCP fails. Neither tool counts nor schema size establish task success or token savings.

No dedicated Calendly-published task CLI was identified in the reviewed official developer pages. A community CLI does exist, so we do not claim the CLI category is empty. Community scope observations are documentation/source reviews, not competitor handshakes or live booking tests. See COMPARISON.md for evidence scope and the pending matched task comparison.

Current primary sources: API reference, OpenAPI, scopes, quota, release notes and MCP tools. Original/sanitized hashes and reviewed schema corrections are in src/tools/api-source.json.

19. Versions

Component	Current baseline	Meaning
Package / desktop manifest	3.0.1	Shared MCP/CLI, current API and guarded workflows
Calendly service	API v2	Fixed api.calendly.com, no /v2 URL prefix
OpenAPI info.version	1.0.0	Document metadata, not service version
Slipway	0.1.17	The MCP server and the CLI from one definition of each tool
MCP TypeScript SDK, through Slipway	2.3.0	The protocol and its transports
Node	22+	CLI/manual MCP and compatible desktop runtime
Legacy source	1.0.0 / 38 declared tools	Manually assembled MCP-only implementation

Many old tool names remain, but use current schema arguments and routes. Path identifiers use meaningful *_uuid flags; filters use canonical full URIs. Availability updates use PATCH /event_type_availability_schedules with event_type query URI; user locations use /locations, customized links /shares, and form submissions the global resource with form filter. New Contacts/Notetaker families and current webhook scope/event rules are included. API v1 ended March 31, 2025. The July 2026 event-slot limit is 31 days; the user busy-time limit stays seven. OAuth refresh tokens have rotated once since the August 2026 deadline.

See CHANGELOG.md for exact legacy-name migration and current corrections. Preserve AGPL-3.0-or-later. Build/typecheck, 36 tests and actual discovery are distinct from live account outcomes and GUI installation, which remain unverified; section 7 has the measured token costs.

20. FAQ

A local stdio server exposing Calendly operations to an AI client through structured tool schemas.

calendly-cli runs the same operations through the actual shared MCP implementation. Shell agents and scripts can use it.

Yes, hosted at https://mcp.calendly.com, using DCR OAuth 2.1 and PKCE. It is a strong scheduling option.

Local CLI use, PAT/REST OAuth grants, named accounts, Contacts/Notetaker operations, bounded pagination and explicit guards. No overall superiority or efficiency percentage is claimed.

Yes. The reviewed bcharleson/calendly-cli repository offers a community CLI and MCP. No dedicated provider-published task CLI was identified in the official pages reviewed.

The wrapper preserves AGPL-3.0-or-later. Calendly plan charges, permissions and quotas remain separate.

In your intended Calendly account, open Integrations > API and webhooks, generate a scoped token and store it privately.

Use private local settings or owner-only files outside repositories. Never put tokens or signing keys in chats, issues or shared project configs.

No, it prints setup instructions. Bring your own authorized REST grant; the official hosted MCP separately handles DCR OAuth in a compatible client.

A private JSON token file is required. Rotation is locked, single-use and atomically saved. Failed or unknown rotations require reauthorization/repair and restart, rather than repeated token use.

The versioned .mcpb bundles production dependencies and supports private sensitive PAT/file settings. Compatible host/runtime and custom-extension policy apply; GUI installation is separately unverified.

It needs local stdio. For remote URL clients, check the official hosted MCP and DCR compatibility.

It creates a real booking with normal calendar invites, notifications and workflows. There is no draft booking; explicit confirmation is required.

No invented reschedule endpoint is exposed. Use supported returned links/workflows or a separately approved cancellation/new booking.

Event-type available slots now allow up to 31 days; user busy-time queries remain capped at seven. Both need future increasing ranges.

Supported native page_token lists have bounded all_pages, max_items and a 100-request cap. Every page uses quota, and continuation is not a snapshot.

The result cap cut through a page. Fetch the same token with identical filters/count and skip that many records locally. There is no skip API flag.

It reads existing Notetaker transcript/recap data where your account provides it. It does not record a meeting or bypass access/consent requirements.

No. Inspect state after an unknown booking or edit outcome before repeating it. GET retries and auth refresh do not resubmit writes.

It depends on the client and the task. In Claude Code the CLI costs nothing until it is used, plus about 1,400 tokens for SKILL.md once, where the server costs about 1,200 tokens a message with tool search and 40,000 with every tool loaded. In Codex, finding the command that cancels an event took a median of 83,073 input tokens over the CLI and 48,780 over MCP. Section 7 has how each was measured.

Questions

Open a sanitized issue with version/client/OS. Use SECURITY.md for private reports.

About the author

Navid Moazzez is a leading AI business strategist, and the host of the AI Creator Summit, watched by 100,000+ creators. He helps creators and founders master AI and build their own AI Operating System (AI OS) to automate their business and life. He creates useful free tools, MCP servers and CLIs that creators and founders can use in their own workflows.

Links

Personal website: navid.me
Link in bio: navid.bio
Navid Media: navid.media
YouTube: @thenavidm and @thenavidai
X: @thenavidm
Instagram: @thenavidm
LinkedIn: thenavidm

Dependencies

Dependency	Version range	Used for
`@thenavidm/slipway`	`^0.1.14`	The MCP server and the CLI from one definition of each tool, with the MCP TypeScript SDK
`ajv`	`^8.17.1`	JSON Schema input validation
`ajv-formats`	`^3.0.1`	JSON Schema input validation

Full third-party attribution is in THIRD_PARTY_NOTICES.md. Development tooling and its audit limitations are documented in SECURITY.md.

License

AGPL-3.0-or-later, preserving the existing license. See LICENSE, full AGPL text and THIRD_PARTY_NOTICES.md. Calendly service/documentation terms remain separate.

Available Tools

66 tools

cancel_eventCancel EventA

Destructive

Cancel Event. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: scheduled_events:write.

ParametersJSON Schema

Name	Required	Description
`reason`	No	Reason for cancellation
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`event_uuid`	Yes	The event's unique indentifier
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is known. The description adds material context beyond that: it mutates Calendly state and requires the scheduled_events:write scope, which is auth information not present in the structured fields.

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?

Three short sentences, front-loaded with the action and followed by the precondition and scope. No filler, though the leading 'Cancel Event' repeats the title verbatim rather than adding information.

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 destructive, non-idempotent mutation with no output schema, the description covers the key gaps an agent needs: it changes Calendly state, it needs confirmation, and it requires a write scope. It stops short of describing side effects such as invitee notifications or post-cancellation state, but the annotations carry the destructive signal.

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 all six parameters (including confirm, account, payload, and payload_file) are already documented in the schema. The description only restates the confirm=true requirement, adding no syntax or interaction detail beyond what the schema provides. Baseline 3 applies.

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?

Names a specific verb (Cancel) and resource (Event), so the operation is unambiguous. It does not differentiate itself from the nearby delete_scheduled_event_data or delete_invitee_data siblings, which an agent might reasonably confuse with a cancellation.

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 states a precondition (confirm=true must accompany the specific requested action) and the required OAuth scope, which tells the agent how to invoke it correctly. It gives no guidance on when to prefer cancel_event over the deletion siblings or what conditions make cancellation the right choice.

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

create_contactCreate ContactC

Destructive

Create Contact. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: contacts:write.

ParametersJSON Schema

Name	Required	Description
`city`	No
`name`	No
`state`	No
`emails`	No	The user's email addresses. Max 10.
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`company`	No
`confirm`	No	Must be true for the specific user-requested write.
`country`	No
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`linkedin`	No
`timezone`	No
`job_title`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`custom_fields`	No	Custom field values to set on the contact. Each item requires a `uuid` (the custom field definition identifier) and a `value`; any other keys (such as `label`) are ignored. The entire request is rejected if any `uuid` is unknown, any `value` is the wrong type for its field (including an array for a scalar field or a scalar for an array field), or any `single_select` `value` is not one of the field definition's option `uuid`s.
`phone_numbers`	No	The user's phone numbers. Max 10.

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false, covering the safety profile. The description adds that it 'Changes Calendly state', requires confirm=true, and lists required scopes. This provides useful behavioral context beyond annotations, but it lacks details on rate limits or side effects. With annotations covering the safety profile, a 3 is appropriate—the description adds some value but not rich behavioral context.

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

Conciseness3/5

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

The description is brief—three short sentences. It is front-loaded with the action, then adds the confirmation requirement and scopes. However, it could be more structured and informative without being verbose. It is adequately sized but lacks detail.

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?

Given the complexity of the tool (15 parameters, nested objects, no output schema) and the low schema description coverage (47%), the description is incomplete. It does not explain the payload structure, the difference between body flags and payload, or the required scopes in context. It mentions required scopes but not how to obtain them. Contextual completeness is low.

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

Parameters2/5

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

Schema description coverage is 47%, meaning many parameters are undocumented in both the schema and the description. The description adds no information about any parameters besides mentioning confirm=true, which is already described in the schema. With low coverage, the description should compensate but fails to do so.

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 states a specific verb+resource combination ('Create Contact') that clearly identifies the operation. However, it does not differentiate from sibling tools like create_invitee or provide any additional context beyond what the title already conveys. It's clear but lacks sibling differentiation.

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?

The description provides no guidance on when to use this tool versus alternatives such as create_invitee or update_contact. It mentions a required confirmation but does not explain the context or prerequisites for invocation. No explicit when/when-not/alternatives are given.

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

create_event_typeCreate Event TypeB

Destructive

Create Event Type. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: event_types:write.

ParametersJSON Schema

Name	Required	Description
`name`	No	The event type name
`color`	No	The hexadecimal color value of the event type's scheduling page
`owner`	No	The owner for this event type
`active`	No	Indicates if the event type is active or not
`locale`	No	The locale on the event type, used to determine the language of the event type's scheduling page
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`duration`	No	The length of sessions booked with this event type. Must be one of the duration options if they're provided.
`locations`	No	Configuration information for each possible location for this event type
`description`	No	The event type description
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`duration_options`	No	A maximum of 4 unique options is allowed. Each option must be >= 1 and <= 720.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond annotations: the required 'event_types:write' scope and the confirm=true gate for the specific requested action, which the agent needs before invoking.

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?

Three short sentences, front-loaded with the action, then the confirm requirement and scope. No wasted text, though it is terse to the point of omitting usable guidance.

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?

For a 13-parameter non-idempotent write with nested objects, the description covers the confirm gate and required scope, which are the key invocation gates. It omits any differentiation from create_one_off_event_type and gives no hint about the required owner/name inside the payload, though the schema itself documents those.

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 all 13 parameters (including the nested payload object and the payload/payload_file/body-flag exclusivity) are already documented in the schema. The description adds nothing parameter-level beyond restating the confirm=true requirement, so the baseline 3 applies.

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?

States a specific verb and resource ('Create Event Type'), so the agent knows this is a creation operation. However, it does not differentiate from the sibling create_one_off_event_type, which is a closely related creation tool, so the agent gets no help distinguishing the two.

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?

The description states a hard prerequisite (confirm=true) but gives no when-to-use guidance and never mentions the sibling create_one_off_event_type as an alternative. The agent must infer from context which event-type creation tool to pick.

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

create_inviteeCreate Event Invitee (Scheduling API)B

Destructive

Create Event Invitee (Scheduling API). Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: scheduled_events:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`invitee`	No
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`location`	No	The polymorphic base type for an event location that Calendly supports. Note: - Location.kind must be supplied if location is defined. - Location must match location specified on the EventType. - Do not pass the location object for an EventType with a round_robin pooling_type.
`tracking`	No	The UTM and Salesforce tracking parameters associated with an Invitee
`event_type`	No	Canonical reference (unique identifier) for the event type being scheduled
`start_time`	No	The start time in UTC of the scheduled event
`event_guests`	No	Emails of invitee guests. Max 10.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`questions_and_answers`	No

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description meaningfully adds the confirm=true gate and the scheduled_events:write scope requirement, both operational facts the agent must satisfy before invoking. It does not explain side effects on the referenced event or response behavior, keeping it short of a 5.

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?

Two sentences, no filler, and the mutation/confirm constraint is front-loaded. It is appropriately terse, though the title restatement in sentence one is near-redundant with the name.

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?

This is a high-complexity tool: 11 parameters, deeply nested polymorphic objects, mutually exclusive payload/payload_file/body-flag paths, and no output schema. A two-sentence description covering only confirm and scope leaves the agent without guidance on which input mode to use or how the required-but-empty top-level schema fits together.

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 82%, well above the 80% threshold, so the schema already documents the nested invitee, location, tracking, and payload fields. The description adds no parameter-level guidance (it never mentions payload vs. top-level fields, payload_file exclusivity, or account selection), so the baseline 3 applies.

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

Purpose3/5

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

The first sentence is essentially the title restated ('Create Event Invitee (Scheduling API)'), which alone would be tautological. The second sentence adds that this mutates Calendly state, which clarifies the nature of the operation, but nothing distinguishes it from nearby writers like create_no_show or create_contact.

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?

It states a hard precondition (confirm=true) and the required scope (scheduled_events:write), which is actionable guidance for calling it. However, it offers no when-to-use vs. alternatives routing among the many sibling write tools, so usage is only partially implied.

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

create_no_showCreate Invitee No ShowB

Destructive

Create Invitee No Show. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: scheduled_events:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`invitee`	No
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, non-idempotent and open-world, so the safety profile is covered. The description adds two genuinely non-annotated facts: that the operation changes Calendly state and that it requires the scheduled_events:write scope, plus the confirm=true requirement. It stops short of saying whether the change is reversible or what the response contains.

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?

Two tight sentences, no filler, and the state-change warning is front-loaded before the scope requirement. Slightly redundant with the confirm parameter's own schema description, but nothing wasteful enough to penalize further.

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?

A destructive 5-parameter mutation with a nested payload object and no output schema needs more explanation than this. Scope, confirm, and state-change are covered, but the meaning of the no-show entity, the invitee identifier's role, and the payload-vs-body-flags alternative are all left to the schema.

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 80%, so the schema largely documents account, confirm, payload and payload_file on its own. The description's only parameter-related content (confirm=true) duplicates the schema wording, adding no new syntax or interaction detail. Baseline 3 applies.

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

Purpose3/5

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

The description states a verb and resource ("Create Invitee No Show") but essentially restates the name/title without explaining what marking a no-show means or how the resulting record relates to an invitee. It does not differentiate against close siblings like get_no_show or delete_no_show. Understandable but vague on actual effect.

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 when-to-use guidance and no routing to alternatives (get_no_show, delete_no_show are never mentioned). The only usage constraint given is the confirm=true gate, which is a precondition rather than situational guidance. An agent must infer context entirely.

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

create_one_off_event_typeCreate One-Off Event TypeB

Destructive

Create One-Off Event Type. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: event_types:write.

ParametersJSON Schema

Name	Required	Description
`host`	No	Host user uri
`name`	No	Event type name
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`co_hosts`	No	Collection of meeting co-host(s) user URIs
`duration`	No	Duration of meeting in minutes
`location`	No
`timezone`	No	Time zone used for meeting. Defaults to host's time zone.
`date_setting`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the risk profile is partly covered. The description adds genuinely new context beyond annotations: the explicit state-change warning, the confirm=true safety gate, and the required event_types:write scope, which an agent needs before invoking.

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?

Three short, front-loaded sentences with no wasted filler; the purpose leads and the behavioral constraints follow. It is efficient, though the scope line could be folded more tightly.

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?

For a tool with 11 parameters, nested objects, no required fields, and no output schema, this description is too thin. It leaves the central 'one-off' concept undefined and gives no help distinguishing payload, payload_file, or the body flags, which is exactly what an agent needs to invoke this 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 description coverage is high (82%), so the schema already documents parameters well, establishing a baseline of 3. The description only echoes the confirm requirement, which is already in the schema, and adds nothing about the payload vs payload_file vs body-flag alternatives for this 11-parameter tool.

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

Purpose3/5

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

The first sentence 'Create One-Off Event Type' essentially restates the title and the verb+resource, so an agent knows it creates an event type. However, it never explains what 'one-off' means or how this differs from the sibling create_event_type, leaving the core distinguishing concept undefined.

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?

The description states that confirm=true is required for the write, which is a usage precondition. But it gives no guidance on when to choose this over create_event_type or other creation siblings, and no exclusion criteria, so the selection decision is left to inference.

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

create_scheduling_linkCreate Single-Use Scheduling LinkA

Destructive

Create Single-Use Scheduling Link. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: scheduling_links:write.

ParametersJSON Schema

Name	Required	Description
`owner`	No	A link to the resource that owns this Scheduling Link (currently, this is always an Event Type)
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`owner_type`	No	Resource type (currently, this is always EventType)
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`max_event_count`	No	The max number of events that can be scheduled using this scheduling link.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the mutation profile is known. The description adds genuinely useful non-annotation context: it states the call changes Calendly state, requires confirm=true for the specific user-requested action, and names the required OAuth scope scheduling_links:write.

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?

Three short sentences, front-loaded with the action and then the confirmation and scope constraints. No filler, though the first sentence is largely redundant with the title.

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 destructive write with no output schema, the description covers the state change, the confirmation gate, and the authorization scope. The complex nested payload and its file/flag alternatives are fully documented in the schema, so nothing critical is missing, though return behavior and idempotency consequences are left implicit.

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 the schema documents owner, account, payload, payload_file and the flags with enums and mutual-exclusion notes. The description only echoes the confirm requirement, adding no detail about the payload vs body-flag vs payload_file alternatives, so the baseline 3 applies.

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 names a specific verb (Create) and resource (Single-Use Scheduling Link), matching the title closely. No sibling tool covers scheduling links, so no disambiguation is needed, but the description never explains what a single-use scheduling link is or why one would be created beyond the name itself.

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?

There is no statement of when to create a scheduling link, no prerequisites beyond the confirm flag, and no alternatives named. The only usage-adjacent content is the mechanical confirm=true requirement, which is a gate rather than guidance on choosing this tool.

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

create_shareCreate ShareC

Destructive

Create Share. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: shares:write.

ParametersJSON Schema

Name	Required	Description
`name`	No
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`duration`	No	Must be one of the provided duration options. If duration options aren't provided then duration must be one of the duration options inherited from the event type.
`end_date`	No	is required when `period_type` is 'fixed' Format: `YYYY-MM-DD`
`event_type`	No
`start_date`	No	is required when `period_type` is 'fixed' Format: `YYYY-MM-DD`
`period_type`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`hide_location`	No	determines if a location is hidden until invitee books a spot, only respected when there is a single custom location configured
`duration_options`	No	A maximum of 4 unique options is allowed. Each option must be >= 1 and <= 720.
`max_booking_time`	No	is required when `period_type` is 'moving' or 'available_moving'
`availability_rule`	No
`location_configurations`	No

TDQS

C2.8/5.0

Behavior4/5

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

Annotations already declare the safety profile (destructiveHint=true, openWorldHint=true, non-idempotent), so the bar is lower. The description still adds genuine behavioral context beyond them: a confirm=true guardrail gating the write, a mandatory shares:write scope, and confirmation that this mutates Calendly state. It does not describe consequences for existing data, but the annotation coverage reduces that burden.

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?

Three short sentences, front-loaded, with no padding. The only waste is the opening "Create Share," which duplicates the title rather than advancing the description.

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?

For a 15-parameter destructive mutation with nested objects and no output schema, the description is thin. It says nothing about the mutually exclusive body-input modes (payload vs payload_file vs flat flags), what a share consists of, or the availability/location configuration required for a usable call — content an agent would need that goes beyond the raw schema.

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 67%, above the baseline threshold, so the schema carries most parameter meaning. The description's only parameter reference (confirm=true) duplicates the schema's own description of confirm, adding no new semantics about the 15-param payload/flat-flag surface.

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

Purpose2/5

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

"Create Share" simply restates the tool name and title, and "Changes Calendly state" is a generic mutation phrase. The description never explains what a share is or what resource it produces, so an agent learns nothing about the operation beyond its verb.

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?

There is no when-to-use guidance, no exclusion criteria, and no alternatives named. The mention of a required scope (shares:write) hints at prerequisites but does not help the agent decide when this tool is the right choice.

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

create_webhookCreate Webhook SubscriptionB

Destructive

Create Webhook Subscription. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: scheduled_events:read, event_types:read, meeting_recaps:read, routing_forms:read, contacts:read, webhooks:write.

ParametersJSON Schema

Name	Required	Description
`url`	No	The URL where you want to receive POST requests for events you are subscribed to.
`user`	No	The unique reference to the user that the webhook will be tied to.
`group`	No	The unique reference to the group that the webhook will be tied to.
`scope`	No	Indicates whether the webhook subscription scope is `organization`, `user`, or `group`
`events`	No	List of user events to subscribe to.
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`signing_key`	No	Optional secret key shared between your application and Calendly. See https://developer.calendly.com/api-docs/overview/webhooks/webhook-signatures for additional information.
`organization`	No	The unique reference to the organization that the webhook will be tied to.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds real value beyond them: it states that the call mutates Calendly state, that confirm=true is mandatory, and it enumerates the six required OAuth scopes, which are not present in the schema or annotations.

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?

Three short sentences with the purpose front-loaded and the safety/auth constraints immediately after. The scope list is dense but earns its place. Minor redundancy in restating the title as the first sentence.

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?

For an 11-parameter, nested-body tool with no output schema, the description covers the safety and auth profile well but omits the significant structural choice among body flags, payload, and payload_file (including that payload_file cannot be mixed with the others). That complexity is left to the schema alone.

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 every parameter already carries its own documentation (including confirm, payload, and payload_file). The description adds no parameter-level syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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 opening sentence names a specific verb and resource (create + webhook subscription), which distinguishes it from the delete_webhook, get_webhook, and list_webhooks siblings. However, the first sentence is a verbatim restatement of the title, and the description never explicitly contrasts it with those siblings.

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 when-to-use guidance, no prerequisites, and no alternatives named. An agent cannot tell from the description when creating a webhook subscription is appropriate versus reading (get_webhook) or removing (delete_webhook) one.

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

delete_contactDelete ContactA

Destructive

Delete Contact. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: contacts:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`contact_uuid`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, so the safety profile is partly covered. The description adds real value beyond that: it discloses the required scope (contacts:write) and the mandatory confirm=true gate, which an agent needs before invoking. It stops short of describing cascading effects or irreversibility details.

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?

Three short sentences, front-loaded with the action and followed by the two hard constraints (state change, confirm gate, scope). The first sentence duplicates the title, which is mild waste, but nothing else is padded.

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 destructive mutation with no output schema, the description covers the critical invocation requirements: state mutation, the confirmation gate, and the required scope. It omits what exactly gets deleted or whether the operation is recoverable, which would fully close the gap.

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 67%; the schema already documents 'account' and 'confirm'. The description reinforces the confirm requirement and adds the contacts:write scope, but adds nothing about contact_uuid semantics or the account-vs-organization distinction beyond the schema's own text. Baseline 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 states a specific verb and resource ('Delete Contact') and clarifies that it mutates Calendly state, making it distinguishable from create_contact, update_contact, and get_contact in the sibling list. It does not, however, explicitly name those siblings or scope what kind of contact record is affected.

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?

The description notes that confirm=true is required for the action but gives no when-to-use guidance relative to the many sibling tools, no prerequisites for obtaining a contact_uuid, and no statement of when deletion is inappropriate (e.g. contacts tied to scheduled events).

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

delete_invitee_dataDelete Invitee DataB

Destructive

Delete Invitee Data. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: data_compliance:write.

ParametersJSON Schema

Name	Required	Description
`emails`	No
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=false and openWorld=true, but the description adds genuine context beyond them: it states the action changes Calendly state, requires an explicit confirm=true gate, and needs the data_compliance:write scope. The auth/confirmation requirements are exactly the kind of behavioral detail annotations cannot express.

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?

Three brief sentences, front-loaded with purpose and followed by the confirmation gate and scope requirement. There is essentially no filler, though the opening restatement of the title is near-redundant.

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 destructive, no-output-schema tool, the definition covers the mutation effect, the confirmation requirement and the required scope, while annotations carry the irreversibility signal. It omits detail on what exactly gets deleted (email-scoped invitee records) and permanence, but nothing critical is missing for correct invocation.

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 80%, so the schema already documents the parameters (account, confirm, payload, payload_file). The description only echoes the confirm=true requirement that the schema itself states, adding no syntax or format detail beyond it. Baseline 3 is appropriate.

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

Purpose3/5

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

The description's first sentence is the title restated verbatim ('Delete Invitee Data'), so it conveys the verb+resource but adds no elaboration. It does make clear this is a delete operation on invitee data, but does nothing to distinguish it from close siblings like delete_scheduled_event_data or delete_contact.

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 context is given for when to use this tool versus the other delete tools (delete_contact, delete_recap, delete_scheduled_event_data). The confirm and scope mentions are prerequisites, not usage guidance, so an agent gets no routing help.

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

delete_no_showDelete Invitee No ShowC

Destructive

Delete Invitee No Show. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: scheduled_events:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`no_show_uuid`	Yes

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the confirm=true requirement for the specific write and the required OAuth scope (scheduled_events:write). It stops short of describing irreversibility or side effects on related invitee/event data.

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?

Three short, front-loaded sentences with no filler, and the confirm and scope requirements are stated directly. Minor waste in the opening sentence, which duplicates the name/title, but overall efficient.

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?

For a destructive mutation with no output schema, the description covers the confirm gate and required scope, which is the essential operational context. It leaves gaps an agent would care about: irreversibility, what happens to the related invitee/event records, and what (if anything) is returned. Adequate but not thorough.

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 67%: the schema already documents account and confirm, and the description's confirm=true restatement adds little beyond it. The required no_show_uuid parameter has no description in either the schema or the description, and the description does not explain what a no-show UUID refers to or where it comes from. Baseline 3 for mid coverage with no compensating detail.

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

Purpose2/5

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

The first sentence, "Delete Invitee No Show," simply restates the tool name and title without adding scope, target, or distinguishing detail. "Changes Calendly state" is vague and does not clarify what is destroyed or how this differs from siblings like create_no_show, get_no_show, or delete_invitee_data.

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 when-to-use guidance, no exclusions, and no routing to alternatives despite having close siblings (get_no_show, create_no_show, delete_invitee_data). The only precondition given is the confirm=true gate, which is a mechanical requirement rather than usage guidance.

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

delete_recapDelete RecapB

Destructive

Delete Recap. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: meeting_recaps:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`recap_uuid`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, openWorldHint=true. The description adds a useful confirmation requirement ('requires confirm=true') and a required scope ('meeting_recaps:write'), which annotations don't capture. It doesn't describe irreversibility or what happens to associated data, so it's a small net addition.

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?

Two compact sentences front-load the action and the required confirm flag. No wasted words, though the scope sentence is a bit parenthetical.

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?

For a destructive, non-idempotent mutation tool with no output schema, the description should at least say what is deleted and whether the deletion can be undone. It covers confirmation and scope but leaves gaps in impact/irreversibility.

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 67% (recap_uuid lacks a description; account and confirm are documented). The description restates the confirm requirement but adds no new syntax/format detail beyond the schema. Baseline 3 for moderate schema coverage.

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?

States a specific verb+resource ('Delete Recap'), and the resource is clear from the name. It does not differentiate itself from sibling update_recap/get_recap/list_recaps, though the destructive nature is conveyed by 'Delete'. Adequate but no sibling differentiation.

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 when-to-use guidance. It does not say when to delete vs archive/update, nor preconditions for the operation. The only hint is the required confirm flag, but no user-facing context is given.

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

delete_scheduled_event_dataDelete Scheduled Event DataA

Destructive

Delete Scheduled Event Data. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: data_compliance:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`end_time`	No	The scheduled events UTC timestamp at which data deletion should end.
`start_time`	No	The scheduled events UTC timestamp at which data deletion should begin.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds genuinely new context the annotations lack: the required OAuth scope (data_compliance:write) and the confirm=true guard for the specific requested action.

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?

Three terse sentences, front-loaded with the destructive action before the preconditions. Slight redundancy in restating the title, but there is no padding or throat-clearing.

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 destructive, zero-required-parameter tool with no output schema, the description covers the key call-time essentials: confirmation flag and required scope. It leaves the payload/payload_file/body-flag relationship and the time-window semantics to the schema, which is acceptable at 100% coverage.

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 all six parameters (account, confirm, payload, start/end time, payload_file) are already documented in the schema, including the mutual-exclusion between payload and payload_file. The description only echoes confirm=true, adding nothing beyond the schema. Baseline 3 applies.

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 states a specific verb+resource, 'Delete Scheduled Event Data', so the operation is unambiguous. It does not, however, distinguish itself from the very similar sibling delete_invitee_data, which an agent choosing among data-compliance deletions would want clarified.

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?

It supplies operational preconditions (confirm=true, scope data_compliance:write) but gives no when-to-use vs. alternatives guidance, e.g. when to reach for this rather than delete_invitee_data or cancel_event. Usage is implied rather than directed.

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

delete_webhookDelete Webhook SubscriptionA

Destructive

Delete Webhook Subscription. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: webhooks:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`webhook_uuid`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so safety is covered. The description usefully adds the required scope (webhooks:write) and the confirm=true gate, which are behavioral facts the annotations do not carry.

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?

Three short sentences, no padding, and the mutation is front-loaded. The opening sentence duplicates the title verbatim, which is minor redundancy rather than bloat.

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 destructive, no-output-schema tool, the description covers the essential preconditions: scope requirement and explicit confirmation. It does not say whether the deletion is recoverable or what happens to in-flight webhook deliveries, but the core invocation facts are present.

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 67%, and the schema already documents account and the confirm gate. The description restates that confirm must be true but adds no format or meaning beyond what the schema says, so it sits at the baseline for partially documented params.

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?

States a specific verb+resource ('Delete Webhook Subscription') that is immediately distinguishable from the sibling webhook tools create_webhook, list_webhooks, and get_webhook. An agent can identify the operation without opening the schema.

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?

The description never says when to reach for this tool versus alternatives such as get_webhook or list_webhooks, nor does it state any exclusions. The confirm=true precondition is a call-time requirement, not usage guidance, so routing remains unaddressed.

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

get_availability_scheduleGet User Availability ScheduleC

Read-onlyIdempotent

Get User Availability Schedule. Reads Calendly data. Required scopes: availability:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`schedule_uuid`	Yes	The UUID of the availability schedule.

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description is not the primary source there. It does add the required OAuth scope (availability:read), which is genuinely useful auth context beyond the structured fields, but says nothing about return format or behavior.

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?

Three short fragments, front-loaded with the operation and immediately followed by the scope requirement. Efficient, though the telegraphic style sacrifices some clarity for brevity.

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?

For a single-resource read tool with full schema coverage and annotations covering safety, the definition is minimally sufficient. It omits any description of what the schedule object contains, though with no output schema this is a minor gap for a straightforward get.

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 the schema already documents both parameters, including the account-vs-organization distinction. The description adds no parameter meaning beyond that, making the baseline of 3 appropriate.

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

Purpose3/5

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

The description states a verb (Get) and resource (User Availability Schedule), matching the title and name almost verbatim. It gives no differentiation from the close sibling list_availability_schedules, so an agent must infer whether this fetches one schedule or many. Adequate but not distinctive.

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?

There is no when-to-use guidance, no mention of alternatives like list_availability_schedules, and no preconditions. The only clue that it operates on a single schedule comes from the required schedule_uuid in the schema, not the description.

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

get_contactGet ContactC

Read-onlyIdempotent

Get Contact. Reads Calendly data. Required scopes: contacts:read.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`exclude`	No	Omit the listed fields from the response. Currently only `custom_fields` is supported. When omitted, all fields are returned.
`contact_uuid`	Yes

TDQS

C2.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact - the required 'contacts:read' scope - but says nothing about not-found/error behavior or what the response contains.

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?

Three short fragments, scope constraint placed up front, no filler sentences. It is efficient, though the leading 'Get Contact.' duplicates the title and consumes space that could have carried real content.

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?

For a single-record read with rich annotations and no output schema, the bar is low, and the scope statement covers the main behavioral need. However, the undocumented required contact_uuid and the absence of any usage context leave clear gaps.

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

Parameters2/5

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

Schema coverage is only 67%: 'account' and 'exclude' are documented in the schema, but 'contact_uuid' has no description at all. The description adds zero parameter meaning and does not compensate for the undocumented required parameter (where the UUID comes from, its format).

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

Purpose2/5

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

The description opens by restating the title verbatim ('Get Contact'), which is a tautology. 'Reads Calendly data' only identifies the domain, not what a contact record is or how this differs from siblings like get_contact_custom_field_definition or list_contacts.

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?

There is no when-to-use guidance, no mention of alternatives such as list_contacts for browsing or get_contact_custom_field_definition for field metadata, and no stated prerequisite beyond the scope. An agent must infer selection from the name alone.

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

get_contact_custom_field_definitionGet Contact Custom Field DefinitionC

Read-onlyIdempotent

Get Contact Custom Field Definition. Reads Calendly data. Required scopes: contacts:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`definition_uuid`	Yes

TDQS

C2.4/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description's one genuine addition is the required scope 'contacts:read', which tells the agent about authorization needs — useful context beyond the annotations, but nothing about failure modes or missing-definition behavior.

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

Conciseness3/5

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

The description is short and front-loaded, but the opening sentence is pure repetition of the tool name and earns no place. The scope line is the only sentence carrying information; the rest is padding.

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?

For a simple read tool whose annotations cover safety, the definition is only marginally complete: it states auth scope, which is valuable, but with no output schema the agent gets no sense of what a 'definition' returns, and the required UUID parameter is unexplained.

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

Parameters2/5

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

Schema description coverage is 50%: the 'account' parameter is documented in the schema, but 'definition_uuid' has only a pattern and minLength with no textual meaning. The description adds nothing about either parameter, leaving the required identifier's semantics and format undocumented.

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

Purpose2/5

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

The first sentence restates the tool name and title verbatim ('Get Contact Custom Field Definition') without adding any specificity about what a definition contains or how it differs from the sibling list_contact_custom_field_definitions. The only added information is a generic 'Reads Calendly data' clause. It is essentially a tautology of the name.

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?

There is no when-to-use guidance, no mention of the sibling list_contact_custom_field_definitions, and no stated prerequisites beyond the scope line. An agent gets no help deciding between fetching a single definition and listing all definitions.

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

get_current_userGet current userB

Read-onlyIdempotent

Get current user. Reads Calendly data. Required scopes: users:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds meaningful operational context the annotations lack: the required OAuth scope 'users:read', which is essential for an agent to know whether the call will succeed.

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?

Three short fragments, front-loaded with the action, then domain, then scope. No wasted words, though the telegraphic style borders on under-explained.

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?

For a read tool with rich annotations and a fully documented schema, the description is mostly sufficient. However, there is no output schema, so the description could reasonably say what the user object contains; it does not, leaving the return shape opaque.

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%, and the single optional 'account' parameter is fully explained in the schema (selects credentials, not an organization URI). The description adds no parameter detail, so baseline 3 applies.

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?

States a specific verb and resource ('Get current user') and clarifies the data domain ('Reads Calendly data'). It implicitly distinguishes itself from the sibling 'get_user' (which presumably targets an arbitrary user), but never says so explicitly, so an agent must infer the difference.

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 prefer this over 'get_user' or 'get_organization', and no prerequisites beyond scopes. The agent is left to infer that 'current' means the authenticated caller.

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

get_eventGet EventC

Read-onlyIdempotent

Get Event. Reads Calendly data. Required scopes: scheduled_events:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`event_uuid`	Yes	The event's unique identifier

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, lowering the bar. The description adds genuinely useful context the annotations do not carry: the required OAuth scope scheduled_events:read. It stops there, offering nothing about pagination, error behavior, or what the read returns.

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?

Three short sentences with the scope requirement front-loaded and nothing padded. The opening "Get Event" is redundant with the title, which is the only wasted token.

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?

With only two simple parameters and full schema coverage, the definition is minimally serviceable, and the auth scope is a real addition. However, with no output schema, the description leaves what a returned event contains entirely unexplained.

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 the schema already documents account and event_uuid, including the pattern and account semantics. The description adds no parameter meaning at all, so the baseline of 3 is appropriate.

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

Purpose2/5

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

"Get Event" merely restates the tool name and title, and "Reads Calendly data" is a generic category rather than a specific resource. The scope hint "scheduled_events:read" narrows it slightly, but with siblings like get_event_type, get_event_invitee, and list_events, an agent cannot tell precisely which resource this fetches without inference.

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?

There is no statement of when to use this tool versus get_event_invitee, list_events, or get_event_type, nor any prerequisite or exclusion guidance. Usage is only weakly implied by the singular "Event" in the name.

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

get_event_inviteeGet Event InviteeC

Read-onlyIdempotent

Get Event Invitee. Reads Calendly data. Required scopes: scheduled_events:read.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`event_uuid`	Yes	The event's unique identifier
`invitee_uuid`	Yes	The invitee's unique identifier

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description does add genuinely useful auth context ("Required scopes: scheduled_events:read"), but does not disclose error behavior for unknown UUIDs, account-selection semantics, or anything else beyond that.

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

Conciseness3/5

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

It is short and front-loaded, but the opening sentence is pure title repetition and the scope note is the only substantive content. Minimal without being bloated, yet part of its length is unearned.

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?

No output schema exists, and the description says nothing about what a fetched invitee record contains or how it relates to the parent event. For a simple read tool with full schema coverage and clear annotations, this is passable but leaves the agent guessing about the return payload.

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 event_uuid, invitee_uuid, and the account parameter are already documented in the schema. The description adds no parameter meaning on top of that, so baseline 3 applies.

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

Purpose2/5

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

The description's first sentence simply restates the tool name/title, and "Reads Calendly data" is generic filler. It never distinguishes this single-invitee getter from siblings like get_event, list_event_invitees, or get_transcript, so an agent gains little beyond the name itself.

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?

There is no when-to-use guidance, no conditions, and no mention of alternatives such as list_event_invitees for enumerating invitees. The only hint is the required scope, which is prereq context rather than usage direction.

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

get_event_typeGet Event TypeC

Read-onlyIdempotent

Get Event Type. Reads Calendly data. Required scopes: event_types:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`event_type_uuid`	Yes

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the concrete auth requirement ('Required scopes: event_types:read'), which is genuinely useful context beyond the annotations, but it says nothing about return shape, pagination, or error behavior.

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?

Three short, front-loaded sentences with no filler. It is efficient, though the extreme brevity is achieved partly by omitting needed information rather than by tight editing.

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?

With no output schema and a 50% documented schema, the description should carry more: it never explains what the returned event type contains, whether the account param changes behavior, or how it differs from sibling retrieval tools. The scope line is the only substantive addition.

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

Parameters2/5

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

Schema coverage is 50%: the 'account' parameter is documented in the schema but 'event_type_uuid' has only pattern/minLength constraints. The description does not compensate by explaining what the UUID identifies or how account selection affects the lookup, so it adds nothing beyond the structured fields.

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

Purpose3/5

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

The description states a specific verb+resource ('Get Event Type' / 'Reads Calendly data'), which is enough to know it retrieves a single event type. However, it does not differentiate from the many sibling read tools in play (get_event, get_event_invitee, list_event_types), so an agent cannot tell at a glance why it would choose this one over the list variant.

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?

There is no guidance on when to use this tool versus alternatives such as list_event_types or get_event. The only routing information is the scope requirement, which is an authorization constraint rather than a usage condition.

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

get_groupGet GroupC

Read-onlyIdempotent

Get Group. Reads Calendly data. Required scopes: groups:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`group_uuid`	Yes	Group unique identifier

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the concrete auth requirement (groups:read), which is genuine value beyond annotations, but says nothing about failure modes or what a fetched group contains.

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?

Three short, front-loaded sentences with zero filler. It is efficient, though the brevity comes at the cost of substance rather than being packed with useful 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?

For a two-parameter read tool with full schema coverage and no output schema, the description is minimally adequate. It omits any sense of what the returned group representation includes, but with a simple read operation that gap is tolerable.

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%, so account and group_uuid are fully documented in the schema itself. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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

Purpose2/5

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

"Get Group. Reads Calendly data." largely restates the tool name and title rather than specifying what a group is or what is retrieved. It does not distinguish this tool from siblings like list_groups or get_group_relationship, leaving the agent to infer the difference.

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?

There is no when-to-use guidance and no mention of alternatives such as list_groups for enumeration. The only usable signal is the required scope, which is a prerequisite rather than a selection criterion.

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

get_group_relationshipGet Group RelationshipC

Read-onlyIdempotent

Get Group Relationship. Reads Calendly data. Required scopes: groups:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`relationship_uuid`	Yes

TDQS

C2.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description does add one genuinely useful behavioral fact the annotations lack: the required 'groups:read' scope. That earns a modest score, but nothing about failure modes, missing-resource behavior, or return shape is disclosed.

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

Conciseness3/5

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

Three short sentences with no filler and the scope note front-loaded after the name. However, the brevity reflects under-specification rather than efficient communication.

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 exists, so the description should help convey what a 'group relationship' is and what comes back; it does not. Combined with the undocumented required UUID parameter and no usage guidance, an agent has little beyond the name to work with.

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

Parameters2/5

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

Schema description coverage is only 50%: the 'account' parameter is documented in the schema, but 'relationship_uuid' has no description anywhere. The description adds nothing about either parameter, so it fails to compensate for the coverage gap on the required UUID.

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

Purpose2/5

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

The description repeats the tool title verbatim ('Get Group Relationship') and adds only the generic phrase 'Reads Calendly data.' It does not specify what a group relationship is, what resource is retrieved, or how it differs from the sibling list_group_relationships.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the alternative sibling list_group_relationships for enumeration. The only contextual hint is the scope requirement, which is auth-related rather than usage-routing.

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

get_no_showGet Invitee No ShowC

Read-onlyIdempotent

Get Invitee No Show. Reads Calendly data. Required scopes: scheduled_events:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`no_show_uuid`	Yes

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description usefully adds the required OAuth scope (scheduled_events:read), which is genuine context beyond the annotations, but says nothing about the return payload or lookup behavior for a missing no-show.

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

Conciseness3/5

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

The definition is short and front-loaded, but the opening sentence is pure redundancy that repeats the title without adding information. The scope clause is the only sentence that earns its place.

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?

For a simple read tool with annotations covering safety and no output schema, the description is nearly adequate but leaves the required UUID undocumented and offers no distinction from sibling no-show operations. It stops just short of what an agent needs.

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

Parameters2/5

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

Schema description coverage is only 50%: 'account' is documented but the required 'no_show_uuid' has only a pattern and no prose. The description provides no parameter meaning at all, so it fails to compensate for the gap on the one parameter the agent must supply.

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

Purpose3/5

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

The first sentence 'Get Invitee No Show' is a verbatim restatement of the tool title, and 'Reads Calendly data' is generic. It does convey that this retrieves a no-show record, but there is no differentiation from the sibling write operations create_no_show and delete_no_show.

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 when-to-use guidance or routing to alternatives is given. With create_no_show and delete_no_show among its siblings, an agent gets no signal about when this read is the right choice versus those.

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

get_organizationGet OrganizationA

Read-onlyIdempotent

Get Organization. Reads Calendly data. Required scopes: organizations:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`org_uuid`	Yes	The organization's unique identifier

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new information not present in annotations: the required OAuth scope 'organizations:read', which is useful for auth-aware agents.

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?

Three short fragments with zero wasted words and the resource stated first. 'Get Organization' duplicates the title, which is minor redundancy but not harmful.

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 single-resource read with full schema coverage and complete safety annotations, the definition covers purpose and auth scope adequately. It lacks any note on what the response contains, but with no output schema that is a minor gap.

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 both the org_uuid identifier and the account credential selector are already documented in the schema. The description adds no parameter-level meaning beyond that, which is the baseline expectation.

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?

States a clear verb+resource ('Get Organization'), which is unambiguous on its own. It does not distinguish itself from similar retrieval siblings such as get_group or get_team, so it falls short of a 5.

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 like get_organization_membership or get_team, and no prerequisites beyond the scope note. The agent must infer usage entirely from the name.

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

get_organization_invitationGet Organization InvitationC

Read-onlyIdempotent

Get Organization Invitation. Reads Calendly data. Required scopes: organizations:read.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`org_uuid`	Yes	The organization’s unique identifier
`invitation_uuid`	Yes	The organization invitation's unique identifier

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the concrete auth requirement 'Required scopes: organizations:read', which is real operational context not present in the annotations or schema. It stops short of noting error behavior for missing/nonexistent invitations.

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?

Three short fragments with no padding, and the scope requirement is easy to find. 'Reads Calendly data' is redundant with the tool name but costs only a few 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?

For a simple read-by-id tool with full schema coverage and rich annotations, the description plus structured fields are sufficient to invoke it correctly. The remaining gap is that no output schema exists and the description says nothing about what an invitation record contains or what happens on a bad UUID.

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 all three parameters (account, org_uuid, invitation_uuid) are already documented in the schema with types, patterns and roles. The description adds nothing about parameter meaning or interaction, so the baseline 3 applies.

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

Purpose2/5

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

The first sentence restates the tool name verbatim, adding no scope or resource detail beyond the title. 'Reads Calendly data' is generic filler that does not distinguish this tool from the many sibling read tools (e.g. list_organization_invitations, get_organization_membership).

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 call this versus siblings such as list_organization_invitations (which lists many) or revoke_organization_invitation (which acts on one). The agent must infer usage entirely from the name and required parameters.

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

get_organization_membershipGet Organization MembershipC

Read-onlyIdempotent

Get Organization Membership. Reads Calendly data. Required scopes: organizations:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`membership_uuid`	Yes	The organization membership's unique identifier

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds only the required scope 'organizations:read', which is real auth context beyond the annotations, but it says nothing about what a 404/permission failure looks like or what data is returned.

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?

Three short, front-loaded fragments with no padding. 'Reads Calendly data' is mild boilerplate that could be dropped, but nothing else is wasted.

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?

For a simple single-resource getter with a fully documented two-parameter schema and complete safety annotations, the essentials are present. However, with no output schema the description does not hint at the response shape or error behavior, leaving a small but real gap.

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%, and the schema already explains that 'account' selects credentials rather than an organization URI and that membership_uuid is the membership identifier. The description adds no meaning beyond that, so the baseline 3 applies.

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

Purpose3/5

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

The first sentence restates the title and name almost verbatim, which is close to tautology, but 'Reads Calendly data' confirms this is a read-only retrieval. It does not distinguish this single-item getter from the sibling list_organization_memberships, so an agent gets only the minimal viable signal.

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?

There is no statement of when to use this tool versus alternatives such as list_organization_memberships or get_organization. Nothing indicates that a membership_uuid is prerequisite data the agent must already possess.

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

get_recapGet RecapC

Read-onlyIdempotent

Get Recap. Reads Calendly data. Required scopes: meeting_recaps:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`recap_uuid`	Yes

TDQS

C2.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the required OAuth scope (meeting_recaps:read), which is genuine auth context beyond the structured fields, but it omits anything about the returned recap's contents or lookup failure behavior.

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

Conciseness3/5

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

It is short and front-loaded, but the leading sentence 'Get Recap' is pure repetition of the title and the 'Reads Calendly data' clause is filler, so the brevity reflects under-specification rather than efficient information density.

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?

For a fetch-by-identifier tool with no output schema, the description should at least hint at what a recap is or what is returned; instead it only names a scope and a generic data source. Annotations cover the read-only safety profile, but the description leaves the actual purpose and return content unexplained.

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

Parameters2/5

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

Schema description coverage is only 50% (account is documented, recap_uuid has only pattern/minLength with no prose). The description adds no meaning for either parameter, so it fails to compensate for the undocumented required recap_uuid.

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

Purpose2/5

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

The first sentence 'Get Recap' merely restates the tool name/title, and 'Reads Calendly data' is generic boilerplate. With siblings like list_recaps, get_transcript, update_recap, and delete_recap in the same family, the description does nothing to distinguish retrieving a single recap by UUID from listing many or fetching a transcript.

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?

There is no explicit when-to-use guidance or routing to alternatives such as list_recaps. The only usage-adjacent information is the required scope (meeting_recaps:read), which is a prerequisite rather than an indication of when this tool is the right choice over its siblings.

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

get_routing_formGet Routing FormC

Read-onlyIdempotent

Get Routing Form. Reads Calendly data. Required scopes: routing_forms:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`form_uuid`	Yes

TDQS

C2.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description does add useful auth context — the required routing_forms:read scope — which the agent needs but cannot derive from annotations.

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?

Three short, front-loaded fragments with no padding or redundancy. It is terse to the point of under-specification, but nothing in it is wasted.

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?

With no output schema, the description should at least hint at what a routing form record contains, and it should explain the undocumented form_uuid parameter. Neither is present, leaving the definition inadequate for correct invocation.

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

Parameters2/5

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

Schema description coverage is 50%: account is documented in-schema but form_uuid has only a pattern constraint and no explanation. The description adds no meaning for either parameter, so it fails to compensate for the undocumented required field.

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

Purpose2/5

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

"Get Routing Form" repeats the tool name and title almost verbatim, and "Reads Calendly data" is a generic filler statement. Nothing distinguishes it from list_routing_forms or get_routing_form_submission beyond the resource noun.

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?

There is no indication of when to use this tool versus list_routing_forms (to enumerate) or get_routing_form_submission (to read submitted data). No prerequisites or context conditions are given.

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

get_routing_form_submissionGet Routing Form SubmissionB

Read-onlyIdempotent

Get Routing Form Submission. Reads Calendly data. Required scopes: routing_forms:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`submission_uuid`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only the required OAuth scope ('routing_forms:read'), which is useful auth context but minimal beyond annotations.

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?

Very short and front-loaded: name, then action, then scope. No wasted words, though the sentence 'Reads Calendly data' is redundant with the name and could be replaced by more useful detail.

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?

For a simple two-parameter read tool with an output schema absent, the definition is minimally adequate: it covers purpose and auth scope. However, it lacks details about the return payload or how submission_uuid is obtained, and offers no differentiation from list_routing_form_submissions.

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 50%. The schema documents the 'account' parameter well ('named private Calendly account; selects credentials'), but 'submission_uuid' has no description in the schema and none in the tool description. The description does not compensate for this gap, so baseline 3 applies.

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 states a clear verb+resource ('Get Routing Form Submission'), which tells the agent exactly what it retrieves. It is distinguishable from siblings like list_routing_form_submissions by the singular 'submission', though the description itself does not call out that contrast.

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 list_routing_form_submissions or get_routing_form. The only usage-relevant info is the required scope, which is a hard prerequisite rather than selection guidance.

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

get_sample_webhook_dataGet sample webhook dataC

Read-onlyIdempotent

Get sample webhook data. Reads Calendly data. Required scopes: webhooks:read.

ParametersJSON Schema

Name	Required	Description
`user`	No
`event`	Yes
`group`	No
`scope`	Yes
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`organization`	Yes

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the 'webhooks:read' scope requirement, which is genuine auth context beyond the annotations, but says nothing about what the returned sample contains, whether it is canned vs. live, or any rate limits.

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?

Three short, front-loaded sentences with almost no padding, though 'Reads Calendly data' is filler that carries no actionable information. Nothing is buried, and the scope constraint is easy to spot.

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?

For a 6-parameter tool with low schema coverage and no output schema, the description is too thin: it never defines what 'sample' data means, how scope/event/organization combine, or what the caller should expect back. Annotations cover safety, but the functional gaps remain.

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

Parameters2/5

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

Schema description coverage is only 17% (just the 'account' field), and the description adds no parameter meaning at all. Key required parameters such as event, scope, and organization — including how the scope enum interacts with the event enum — are entirely unexplained in prose.

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

Purpose3/5

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

The first sentence is a verbatim restatement of the name/title, which is close to tautology, but 'Reads Calendly data' plus the scope requirement do signal that this returns a sample webhook payload. It offers no differentiation from the closest sibling, get_webhook, so an agent cannot tell from the text alone what distinguishes a 'sample' fetch from a real webhook record.

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?

There is no when-to-use guidance, no named alternative, and no stated preconditions beyond the scope string. Given siblings like get_webhook and list_webhooks exist, the description leaves the agent to guess which to call.

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

get_teamGet TeamC

Read-onlyIdempotent

Get Team. Reads Calendly data. Required scopes: organizations:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`team_uuid`	Yes	Team UUID

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already establish readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds one genuinely useful behavioral fact the annotations do not carry: the required OAuth scope organizations:read. It says nothing further about errors or return shape.

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?

Three short, front-loaded sentences with no padding. It loses a point only because the opening sentence duplicates the title instead of using that space for the resource detail the description lacks.

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?

For a two-parameter, single-resource read with no output schema, the definition is minimally viable: the annotations cover risk and the schema covers inputs. It never says what a team record contains or what the UUID maps to, leaving an agent to infer the return payload.

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% (team_uuid and account both documented, including the non-obvious note that account selects credentials rather than an organization URI). The description adds no parameter meaning, so the baseline 3 for a fully documented schema is correct.

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

Purpose2/5

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

"Get Team" merely restates the tool name/title, and "Reads Calendly data" is a generic filler phrase that applies to dozens of siblings. Nothing states that this retrieves a single team's details by UUID, nor how it differs from list_teams or get_group.

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?

There is no when-to-use guidance and no routing to alternatives such as list_teams (for enumeration) or get_group (for group-level data). The only prerequisite-like detail is the required scope, which hints at permissions but not at selection conditions.

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

get_transcriptGet TranscriptC

Read-onlyIdempotent

Get Transcript. Reads Calendly data. Required scopes: meeting_recaps:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`recap_uuid`	Yes	The meeting recap uuid

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description's one real contribution is the required scope 'meeting_recaps:read', which is useful auth context not present in annotations. It adds nothing about return format or pagination, so it clears the lower annotation-adjusted bar only modestly.

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

Conciseness3/5

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

It is short and front-loaded, but 'Get Transcript.' merely restates the name and 'Reads Calendly data.' is near-tautological filler. Only the scope sentence earns its place, so the size is fine but the signal-to-noise ratio is mediocre.

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?

For a simple two-parameter read tool with full annotation coverage and no output schema, the description is minimally viable. It supplies the required scope but omits anything about what a transcript returns or how recaps and transcripts relate, leaving an agent to infer usage.

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 both parameters (account, recap_uuid) are already documented in the schema; baseline 3 applies. The description adds no format, sourcing, or constraint detail beyond what the schema provides.

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

Purpose3/5

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

The description names a specific verb and resource ('Get Transcript'), so the basic action is clear. However, 'Reads Calendly data' is generic filler and it never distinguishes this from the nearby recap siblings (get_recap, list_recaps), nor explains that a transcript is a sub-resource of a meeting recap.

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?

There is no when-to-use guidance, no prerequisites, and no reference to any alternative tool. An agent learns nothing about when get_transcript is the right choice versus get_recap or list_recaps.

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

get_userGet userC

Read-onlyIdempotent

Get user. Reads Calendly data. Required scopes: users:read.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	User unique identifier, or the constant "me" to reference the caller
`account`	No	Named private Calendly account; selects credentials, not an organization URI.

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds something annotations cannot convey: the required OAuth scope (users:read), which is exactly the kind of auth context worth crediting.

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?

Three short fragments, front-loaded with the action and immediately followed by the domain and the scope requirement. The only waste is the opening "Get user," which duplicates the name and title.

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?

For a simple two-parameter read tool with full schema coverage and rich annotations, the description covers purpose and authorization adequately. It still omits the distinction from get_current_user, which matters given the "me" alias in the schema.

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 both uuid (including the "me" constant) and account are fully documented in the schema. The description adds nothing about parameters, so the baseline 3 applies.

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

Purpose2/5

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

"Get user" simply restates the tool name and title without specifying what a user record contains or how it differs from the sibling get_current_user. The only added information is the domain ("Reads Calendly data"), which is a tautology for a getter named get_user.

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?

There is no when-to-use guidance and no mention of the obvious alternative, get_current_user, which is critical here because the schema's uuid field allows "me" to reference the caller. An agent has to infer from the sibling list which tool to pick.

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

get_webhookGet Webhook SubscriptionB

Read-onlyIdempotent

Get Webhook Subscription. Reads Calendly data. Required scopes: webhooks:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`webhook_uuid`	Yes

TDQS

B3/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuine value beyond them by stating the required OAuth scope (webhooks:read), but discloses nothing about return shape, error behavior, or what the operation yields.

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?

Three short, front-loaded sentences with no padding or repetition. It is terse, though the second and third sentences ('Reads Calendly data') contribute little, keeping it just under a fully earned 5.

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?

For a simple single-resource read with annotations covering the safety profile and no output schema, the definition is minimally adequate. It omits any description of the required webhook_uuid parameter and the returned object, leaving meaningful gaps.

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

Parameters2/5

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

Schema coverage is only 50%: 'account' is documented in the schema, but the required 'webhook_uuid' has no description there and the tool description supplies none either. An agent gets no help on what a webhook UUID is or where to obtain one, which is the key required input.

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 names a specific verb+resource ('Get Webhook Subscription'), which is clear enough to distinguish from delete_webhook, create_webhook, and list_webhooks. However, it does not explicitly name or contrast with any sibling, so the agent must infer the differentiation from the tool name alone.

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?

There is no statement of when to use this tool versus alternatives such as list_webhooks or get_sample_webhook_data. The only guidance-like content is the required scope, which is a prerequisite rather than a usage condition.

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

invite_to_organizationInvite User to OrganizationB

Destructive

Invite User to Organization. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: organizations:write.

ParametersJSON Schema

Name	Required	Description
`email`	No	The email of the user being invited
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`org_uuid`	Yes	The organization's unique identifier
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.2/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description adds genuinely useful context: that it mutates Calendly state, that it requires confirm=true for the specific action, and that it needs the organizations:write scope. These are exactly the non-obvious behavioral facts an agent needs before invoking a destructive write.

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?

Three short, front-loaded sentences with no filler; the constraint facts appear immediately after the purpose. It is efficiently sized for the information it conveys, though the opening tautology slightly wastes the prime position.

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 destructive, non-idempotent write tool with no output schema, the description covers the critical constraints: state mutation, the confirm requirement, and the required scope. Given the schema fully documents parameters, this is close to complete, missing only explicit routing to sibling tools.

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 the schema fully documents all six parameters including the confirm flag and payload alternative. The description adds no parameter-level detail beyond what the schema already carries (e.g., it doesn't explain how email vs payload vs payload_file interact), so the baseline of 3 applies.

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

Purpose3/5

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

The first sentence restates the title verbatim ('Invite User to Organization'), so it adds essentially no information beyond the name. The verb+resource is nonetheless clear and distinct from siblings like remove_from_organization or revoke_organization_invitation. It sits between vague and clear because the name carries the differentiation, not the description.

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?

There is no statement of when to use this versus alternatives (e.g., create_invitee, list_organization_invitations, revoke_organization_invitation) or any preconditions. The only conditional content is the confirm=true gate, which is a mechanism rather than usage guidance. A reader can infer the intent from the name but the description itself supplies nothing.

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

list_accountsList configured accountsA

Read-onlyIdempotent

List private account labels, default selection and configured token method. No credentials, token paths or Calendly content; no network request.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare read-only, non-destructive, idempotent, non-open-world behavior. The description adds significant context: it discloses that no credentials, token paths, or Calendly content are returned, and no network request is made. This exceeds annotation coverage.

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, front-loaded sentence that efficiently communicates all key points without any waste.

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

Completeness5/5

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

Given the simplicity of the tool (no parameters, no output schema) and the rich annotations, the description provides all necessary context: what it lists, what it does not include, and that it makes no network request.

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?

The tool has zero parameters, so baseline is 4. The description adds no parameter information, but none is needed.

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 states a specific verb (List) and resource (private account labels, default selection, configured token method). This is precise and distinguishable from all sibling tools, none of which deal with accounts.

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 (viewing configured accounts) but does not explicitly state when to use this tool versus alternatives. However, given its unique purpose and the lack of direct siblings, guidance is less critical.

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

list_activity_logList activity log entriesB

Read-onlyIdempotent

List activity log entries. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: activity_log:read.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Order results by the specified field and direction. List of {field}:{direction} values.
`actor`	No	Return entries from the user(s) associated with the provided URIs
`count`	No	The number of rows to return
`action`	No	The action(s) associated with the entries
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`namespace`	No	The categories of the entries
`page_token`	No	The token to pass to get the next portion of the collection
`search_term`	No	Filters entries based on the search term. Supported operators: - `\|` - to allow filtering by one term or another. Example: `this \| that` - `+` - to allow filtering by one term and another. Example: `this + that` - `"` - to allow filtering by an exact search term. Example: `"email@website.com"` - `-` - to omit specific terms from results. Example: `Added -User` - `()` - to allow specifying precedence during a search. Example: `(this + that) OR (person + place)` - `` - to allow prefix searching. Example `@other-website.com`
`organization`	Yes	Return activity log entries from the organization associated with this URI
`max_occurred_at`	No	Include entries that occurred prior to this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone.
`min_occurred_at`	No	Include entries that occurred after this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone.

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds two genuinely useful behavioral facts: required scope 'activity_log:read' and that page_token retrieval is bounded. However, it omits pagination/quota behavior detail that the schema hints at (all_pages/max_items), leaving the disclosure incomplete for a 13-param list tool.

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?

Three short, front-loaded sentences with no filler. Efficient, though it is arguably too terse for a 13-parameter tool.

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?

For a 13-param list tool with no output schema, the description is thin. It does not mention pagination cursor flow, date-range filtering, search_term capability, or the all_pages quota cost — all of which matter for correctly invoking this 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 the schema already documents all 13 parameters thoroughly (sort enums, search_term operators, date formats, all_pages semantics). The description adds almost nothing beyond restating the scope and bounded page_token, so baseline 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?

States a specific verb+resource ('List activity log entries') that clearly identifies the operation. It does not distinguish itself from any sibling (none of the listed siblings are activity log tools), so it lands at 4 rather than 5.

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 when-to-use, when-not-to-use, or alternatives are mentioned. There is no routing guidance for an agent choosing among the many list_* tools.

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

list_availability_schedulesList User Availability SchedulesB

Read-onlyIdempotent

List User Availability Schedules. Reads Calendly data. Required scopes: availability:read.

ParametersJSON Schema

Name	Required	Description	Default
`user`	Yes	A URI reference to a user
`account`	No	Named private Calendly account; selects credentials, not an organization URI.

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful non-annotation context by naming the required OAuth scope ('availability:read'), which signals an auth precondition the agent would otherwise have to discover. It says nothing about pagination or result volume, capping it below a 4.

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?

Three short, front-loaded sentences that are easy to scan. The middle sentence 'Reads Calendly data' is largely filler given the readOnlyHint annotation, which keeps it from being a 5.

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?

For a two-parameter read tool with full schema coverage and no output schema, the description is minimally adequate. It omits pagination/return-size behavior and does not clarify the singular-vs-list distinction against sibling tools, leaving meaningful gaps.

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 the schema already documents both parameters ('user' as a URI reference and 'account' as a credential selector). The description adds no additional parameter meaning, so the baseline of 3 applies.

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 states a specific verb and resource ('List User Availability Schedules'), and the name distinguishes it from the singular get_availability_schedule and from list_event_type_availability_schedules. It does not, however, explicitly contrast its scope with those siblings, so the differentiation is left to inference from the name.

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 when-to-use guidance, no exclusions, and no pointer to alternatives such as get_availability_schedule or list_event_type_availability_schedules. The agent must guess from the name alone whether this is the right tool for a given schedule-listing need.

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

list_contact_custom_field_definitionsList Contact Custom Field DefinitionsB

Read-onlyIdempotent

List Contact Custom Field Definitions. Reads Calendly data. Required scopes: contacts:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.

TDQS

B3.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond the annotations: the required OAuth scope 'contacts:read', which tells the agent what authorization the call needs. 'Reads Calendly data' is filler, but the scope disclosure is real added value.

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?

Three very short sentences, front-loaded with the purpose and free of padding. 'Reads Calendly data' is mildly redundant filler, keeping it just short of a 5.

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?

For a parameterless read-only list tool this is minimally adequate, and the annotations plus full schema coverage carry most of the burden. With no output schema, however, the description says nothing about the shape of results or pagination, which for a list endpoint would be useful context.

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?

There is only one optional parameter and schema description coverage is 100%, with the schema explaining that 'account' selects credentials rather than an organization URI. The description adds no parameter detail, so the baseline of 3 for schema-complete parameters applies.

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

Purpose3/5

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

The description states the verb 'List' and the resource 'Contact Custom Field Definitions', which is a specific verb+resource pair. However, it is nearly a verbatim restatement of the tool name and title, adding no new discrimination. It does distinguish from the singular sibling get_contact_custom_field_definition only by implication (plural list vs. single get), which the name already conveys.

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?

The description names a required scope (contacts:read), which is a precondition, but gives no when-to-use or when-not-to-use guidance and never points to alternatives such as get_contact_custom_field_definition for a single definition. An agent must infer selection from the name alone.

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

list_contactsList ContactsB

Read-onlyIdempotent

List Contacts. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: contacts:read.

ParametersJSON Schema

Name	Required	Description
`city`	No	Filter results by partial match on city(ies). Accepts a comma-separated list-- each segment is matched independently (commas in the query string separate values).
`name`	No	Filter results by partial match on name(s). Accepts a comma-separated list-- each segment is matched independently (commas in the query string separate values).
`sort`	No	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: created_at, updated_at. Sort direction is specified as: asc, desc.
`count`	No	The number of rows to return
`email`	No	Filter results by exact match on email address. Accepts a comma-separated list.
`state`	No	Filter results by exact match on state(s), province(s), or region(s). Accepts a comma-separated list of values.
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`company`	No	Filter results by partial match on company name(s). Accepts a comma-separated list-- each segment is matched independently (commas in the query string separate values).
`country`	No	Filter results by exact match on two-letter country code (ISO 3166-1 alpha-2). Accepts a comma-separated list.
`exclude`	No	Omit the listed fields from the response. Currently only `custom_fields` is supported. When omitted, all fields are returned.
`timezone`	No	Filter results by exact match on the IANA time zone name(s). Accepts a comma-separated list of time zones.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`job_title`	No	Filter results by partial match on job title(s). Accepts a comma-separated list-- each segment is matched independently (commas in the query string separate values).
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection
`phone_number`	No	Filter results by exact match on phone number. Accepts a comma-separated list.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/openWorld, so the bar is lower. The description adds real value beyond them: the required scope ('contacts:read') tells the agent about auth requirements, and the 'bounded opaque page_token retrieval' phrasing signals quota-consuming pagination rather than an exhaustive snapshot.

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?

Three short sentences, front-loaded with the action, no padding. 'Reads Calendly data' is mild filler given the name already implies it, keeping it just short of a 5.

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?

With 16 optional filter/pagination parameters and no output schema, the description is thin on how the filters combine or what the pagination/continuation state looks like, though the 100% schema coverage compensates substantially. Adequate but not complete for a tool of this complexity.

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 the schema already documents all 16 parameters in detail (filters, sort syntax, count bounds, all_pages/max_items interplay). The description adds only a generic note about bounded page_token retrieval, which is baseline 3 territory.

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 states a clear verb+resource ('List Contacts') and identifies the domain ('Reads Calendly data'). It does not explicitly differentiate itself from siblings like get_contact or list_contact_custom_field_definitions, but the naming convention makes the list-vs-get distinction inferable.

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?

There is no statement of when to use this tool versus alternatives such as get_contact (single record) or list_contact_custom_field_definitions. The mention of page_token retrieval implies a large-collection use case but never says so explicitly or names an alternative.

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

list_event_inviteesList Event InviteesB

Read-onlyIdempotent

List Event Invitees. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: scheduled_events:read.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	Order results by the created_at field and direction specified: ascending ("asc") or descending ("desc")	created_at:asc
`count`	No	The number of rows to return
`email`	No	Indicates if the results should be filtered by email address
`status`	No	Indicates if the invitee "canceled" or still "active"
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`event_uuid`	Yes
`page_token`	No	The token to pass to get the next or previous portion of the collection

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already carry readOnlyHint/idempotent/destructive profile, so the safety story is complete. The description adds useful behavior context — 'bounded opaque page_token retrieval' and required scopes — but leaves quota/caching semantics to the schema. This adds value beyond the annotations, which earns a 3 rather than a 4 since it does not elaborate on the bounds.

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?

Three short sentences with no waste; the scope requirement is front-loaded after purpose. Adequately sized, though the opening repeats the title verbatim.

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?

For a 9-parameter list tool with no output schema, the description covers the retrieval model and auth scope. It is adequate but thin — it does not note pagination defaults, filter interaction, or return shape, and no output schema compensates.

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 89%, so the schema already documents all 9 parameters richly (sort, count, email, status, account, all_pages, max_items, event_uuid, page_token). The description adds little parameter-level meaning beyond the schema, so baseline 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?

States a specific verb+resource ('List Event Invitees') and adds scope domain ('Reads Calendly data'), which frames it against siblings. Does not explicitly differentiate from the closest sibling get_event_invitee, but the naming and 'data' framing make the read-list purpose clear.

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 when/when-not guidance. The required scopes line ('scheduled_events:read') is a prerequisite rather than usage routing. It does not tell the agent when to prefer this over get_event_invitee or list_events.

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

list_eventsList EventsC

Read-onlyIdempotent

List Events. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: scheduled_events:read.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: start_time. Sort direction is specified as: asc, desc.
`user`	No	Return events that are scheduled with the user associated with this URI
`count`	No	The number of rows to return
`group`	No	Return events that are scheduled with the group associated with this URI
`status`	No	Whether the scheduled event is `active` or `canceled`
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection
`organization`	No	Return events that are scheduled with the organization associated with this URI
`invitee_email`	No	Return events that are scheduled with the invitee associated with this email address
`max_start_time`	No	Include events with start times prior to this time (sample time format: "2020-01-02T03:04:05.678123Z"). This time should use the UTC timezone.
`min_start_time`	No	Include events with start times after this time (sample time format: "2020-01-02T03:04:05.678123Z"). This time should use the UTC timezone.

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds two genuinely useful facts beyond the annotations: that pagination uses bounded opaque page_tokens and that the scheduled_events:read scope is required. However, 'bounded opaque page_token retrieval' is vague and the return shape is not characterized.

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?

Three short sentences, front-loaded with the action and then the scope requirement. Efficient and no filler, though the first sentence is nearly contentless.

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?

With 13 optional parameters, no output schema, and rich annotations, the description covers the auth scope and pagination mode but says nothing about the default sort/count behavior or what a caller receives. It is minimally adequate given the fully documented schema, but thin for a 13-parameter listing 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% across all 13 parameters, so the schema already carries full parameter meaning. The description adds nothing about filtering semantics, defaults, or interactions between user/group/organization/invitee_email filters, so baseline 3 applies.

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

Purpose3/5

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

The description opens with 'List Events', which essentially restates the name and title, and adds only the generic 'Reads Calendly data'. There is no differentiation from close siblings such as get_event or list_event_invitees, so an agent gets a vague sense of the resource but no distinguishing scope.

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?

There is no guidance on when to use this tool versus alternatives like get_event, list_event_invitees, or the many other list_* siblings. No prerequisites, exclusions, or selection criteria are given.

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

list_event_type_availability_schedulesList Event Type Availability SchedulesC

Read-onlyIdempotent

List Event Type Availability Schedules. Reads Calendly data. Required scopes: availability:read.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`event_type`	Yes	The URI associated with the event type

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds 'Reads Calendly data' and the required 'availability:read' scope, which is genuine auth context, but says nothing about pagination, result shape, or rate limits.

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?

Two short sentences with no filler and the scope requirement front-loaded after the purpose. Slightly terse, but nothing is wasted.

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?

For a simple read-only tool with a fully documented two-parameter schema and no output schema, the definition is minimally adequate. It omits any return-value or pagination context, leaving the agent to infer the response from sibling conventions.

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 only two parameters, both fully described in the schema (account credential selection and event_type URI). The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

Purpose3/5

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

States a specific verb and resource ('List Event Type Availability Schedules'), so it is not a pure tautology, but it largely restates the title and gives no distinguishing detail versus close siblings such as list_availability_schedules, get_availability_schedule, or update_event_type_availability_schedules.

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?

There is no guidance on when to use this tool versus the similarly named availability siblings. The only context offered is the required scope, which is prerequisite information rather than usage direction.

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

list_event_type_available_timesList Event Type Available TimesC

Read-onlyIdempotent

List Event Type Available Times. Reads Calendly data. Required scopes: availability:read.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`end_time`	Yes	End time of the requested availability range. Date must be in the future and no greater than 31 days from start_time.
`event_type`	Yes	The uri associated with the event type
`start_time`	Yes	Start time of the requested availability range. Date cannot be in the past.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety behavior is covered. The description adds useful auth context via 'Required scopes: availability:read,' but 'Reads Calendly data' is redundant with the read-only annotation and no pagination, rate-limit, or output behavior is described.

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?

The description is very short and front-loads the tool's core action, with no meandering. However, the first sentence merely repeats the title and therefore does not fully earn its place.

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?

Although annotations and schema are rich, the description is too sparse for a tool with many similar siblings. It does not explain what 'available times' means in contrast to other availability-listing tools, so an agent still lacks routing and usage context.

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 all four parameters are already documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, which makes the baseline score of 3 appropriate.

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

Purpose2/5

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

The description simply restates the tool title/name: 'List Event Type Available Times.' It adds only generic context ('Reads Calendly data') and does not distinguish this availability-listing tool from sibling tools such as list_availability_schedules, list_event_type_availability_schedules, or list_user_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?

There is no guidance on when to use this tool versus alternatives, nor any exclusions or conditions. The required scope note is a prerequisite, not usage guidance for selecting this tool among the many scheduling and availability siblings.

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

list_event_type_hostsList Event Type HostsB

Read-onlyIdempotent

List Event Type Hosts. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: event_types:read.

ParametersJSON Schema

Name	Required	Description
`count`	No	The number of rows to return
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`event_type`	Yes	The uri associated with the event type
`page_token`	No	The token to pass to get the next or previous portion of the collection

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the schema descriptions cover the pagination semantics of all_pages/max_items. The description adds the required OAuth scope and a brief note on bounded page_token retrieval, which is useful but thin given annotations carry the safety profile.

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?

Four short sentences, front-loaded with the action and resource. There is mild redundancy with the title, but nothing is padded or wasted.

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 read-only list tool with no output schema, full schema coverage, and annotations covering the safety profile, the description supplies the missing pieces (scope requirement, bounded pagination frame). Only the lack of sibling routing guidance keeps it from being fully complete.

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 all six parameters are already documented in the schema (including count limits, max_items request caps, and account/credential semantics). The description only echoes 'bounded opaque page_token retrieval' and adds no syntax or default details 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?

States a specific verb+resource ('List Event Type Hosts') and clarifies it reads Calendly data, so the agent knows exactly what collection is returned. It does not distinguish itself from siblings like get_event_type or list_event_types, but the purpose is unambiguous.

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?

There is no statement of when to use this tool versus alternatives such as get_event_type or list_event_types. The scope note ('event_types:read') is a prerequisite, not usage guidance, so the agent must infer the context from the name alone.

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

list_event_typesList User's Event TypesA

Read-onlyIdempotent

List User's Event Types. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: event_types:read.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values.Supported fields are: name, position, created_at, updated_at. Sort direction is specified as: asc, desc.	name:asc
`user`	No	View available personal, team, and organization event types associated with the user's URI.
`count`	No	The number of rows to return
`active`	No	Return only active event types if true, only inactive if false, or all event types if this parameter is omitted.
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection
`organization`	No	View available personal, team, and organization event types associated with the organization's URI.
`admin_managed`	No	Return only admin managed event types if true, exclude admin managed event types if false, or include all event types if this parameter is omitted.
`user_availability_schedule`	No	Used in conjunction with `user` parameter, returns a filtered list of Event Types that use the given primary availability schedule.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive. The description adds useful behavioral context: required scope 'event_types:read' and the bounded page_token nature. However it doesn't explain quota consumption or the continuation state mentioned in the max_items schema. With annotations covering safety, a 3 is fair for the added scope info.

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?

Extremely concise: three short sentences front-loading the action, data domain, and scope. No waste.

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?

For a read-only listing tool with 11 optional parameters and no output schema, the description is thin. It covers scopes and pagination mode but ignores the significant distinctions between user vs organization vs account parameters, and between active/admin_managed filtering. Schema covers most of this, so a 3 is adequate but not comfortable.

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 rich per-parameter descriptions (sort, active, admin_managed, user vs organization, all_pages semantics). The description adds nothing about individual parameters, so baseline 3 applies since the schema carries the full load.

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?

States a specific verb+resource: 'List User's Event Types'. Clear enough, though it doesn't distinguish from the sibling list_event_type_hosts, list_event_type_available_times, or list_event_type_availability_schedules which deal with related event-type sub-resources.

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?

No explicit when-to-use vs alternatives, but implied by the name and by scope requirements. The description mentions 'Supports bounded opaque page_token retrieval' hinting at a use case, but doesn't say when to prefer all_pages over manual page_token iteration.

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

list_group_relationshipsList Group RelationshipsB

Read-onlyIdempotent

List Group Relationships. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: groups:read.

ParametersJSON Schema

Name	Required	Description
`count`	No	The number of rows to return
`group`	No	Indicates the results should be filtered by group
`owner`	No	Indicates the results should be filtered by owner <br> One Of: - Organization Membership URI - `https://api.calendly.com/organization_memberships/AAAAAAAAAAAAAAAA` - Organization Invitation URI - `https://api.calendly.com/organizations/AAAAAAAAAAAAAAAA/invitations/BBBBBBBBBBBBBBBB`
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection
`organization`	No	Indicates the results should be filtered by organization

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description still adds meaningful context beyond that: required OAuth scope (groups:read) and the bounded page_token retrieval model. It does not describe the shape of returned relationships, but with annotations carrying the safety story this is a solid contribution.

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?

Four short sentences, front-loaded with purpose, then read semantics, pagination, and scopes. Nothing is padded, though the opening sentence duplicates the title, which is a minor waste.

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?

For an eight-parameter optional-filter list tool with no output schema, the description covers reading, scoping, and pagination adequately. It leaves two notable gaps: what a 'group relationship' actually represents and how this endpoint relates to its siblings list_groups/get_group_relationship. Minimum viable, not complete.

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 all eight parameters are already documented in the schema, including count, group, owner, account, and pagination fields. The description mentions page_token retrieval but adds no syntax or semantics beyond what the schema states. Baseline 3 is appropriate when the schema does the heavy lifting.

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 gives a specific verb and resource ('List Group Relationships'), which is enough to know it is a collection read. However, the sentence basically restates the title, and it does not distinguish this list endpoint from close siblings such as get_group_relationship or list_groups. Clear purpose, but no sibling differentiation.

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?

There is no when-to-use guidance: nothing says when to call this versus get_group_relationship, list_groups, or get_group. 'Reads Calendly data' is not actionable usage context. The only hint toward usage is the scopes line, which is a prerequisite rather than a routing rule.

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

list_groupsList GroupsB

Read-onlyIdempotent

List Groups. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: groups:read.

ParametersJSON Schema

Name	Required	Description
`count`	No	The number of rows to return
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection
`organization`	Yes	Return groups that are associated with the organization associated with this URI

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered structurally. The description adds two useful behavioral facts beyond that: the required OAuth scope and that pagination is 'bounded opaque page_token' retrieval — but it does not disclose quota cost, ordering guarantees, or what a 'group' actually is.

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?

Three short sentences, purpose first, then source, then retrieval mode and scope — well front-loaded with no padding. The sentence 'Reads Calendly data' is largely redundant with the readOnlyHint annotation, a minor waste but not enough to drop below 4.

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?

For a read-only list endpoint with no output schema, the description covers purpose, pagination mode and required scope, which is close to adequate. It omits what a group represents and how the returned collection relates to organizations, which matters for an agent choosing between this and the group-relationship siblings.

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% across all six parameters, including nuanced notes on account credential selection, all_pages quota consumption and max_items continuation state. The description adds nothing parameter-specific, so the baseline 3 applies.

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 states a specific verb and resource ('List Groups') and names the data source ('Reads Calendly data'), so the agent knows exactly what is returned. It does not, however, distinguish itself from close siblings such as get_group or list_group_relationships, leaving the agent to infer the difference from names alone.

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?

The only guidance is an implicit prerequisite ('Required scopes: groups:read'), which tells the agent what credentials are needed but not when to pick this tool over list_group_relationships or get_group. There is no when-to-use, when-not-to-use, or alternative routing.

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

list_organization_invitationsList Organization InvitationsB

Read-onlyIdempotent

List Organization Invitations. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: organizations:read.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	Order results by the field name and direction specified (ascending or descending). Returns multiple sets of results in a comma-separated list.	created_at:asc
`count`	No	The number of rows to return
`email`	No	Indicates if the results should be filtered by email address
`status`	No	Indicates if the results should be filtered by status ("pending", "accepted", or "declined")
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`org_uuid`	Yes	The organization's unique identifier
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive, open-world behavior, so the bar is low. The description adds genuine value beyond them by declaring the required scope ('organizations:read') and noting that retrieval via page_token is bounded, which constrains expectations about completeness.

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?

Three short, front-loaded sentences with no redundancy. The only soft spot is 'Reads Calendly data,' which is boilerplate that consumes space without adding selection 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?

For a nine-parameter list tool with full schema coverage and no output schema, the description covers purpose, auth scope, and pagination adequately but says nothing about what an invitation record contains or how results/continuation state are shaped. That leaves a modest gap.

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 all nine parameters are already documented in the schema, including the filters, count, sort, and pagination arguments. The description adds nothing parameter-specific, so the baseline of 3 applies.

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?

States a clear verb+resource ('List Organization Invitations') and adds the domain ('Reads Calendly data'). It does not distinguish itself from close siblings like get_organization_invitation or revoke_organization_invitation, but the listing scope is unambiguous.

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 when-to-use or when-not-to-use guidance is given, and no alternative is named. An agent gets no help deciding between this, get_organization_invitation (single record), and revoke_organization_invitation; only the pagination mechanics are hinted at.

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

list_organization_membershipsList Organization MembershipsC

Read-onlyIdempotent

List Organization Memberships. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: organizations:read.

ParametersJSON Schema

Name	Required	Description
`role`	No	Indicates if the results should be filtered by role
`user`	No	Indicates if the results should be filtered by user
`count`	No	The number of rows to return
`email`	No	Indicates if the results should be filtered by email address
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection
`organization`	No	Indicates if the results should be filtered by organization

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnly=true, idempotent=true, openWorld=true, destructive=false, so the safety profile is covered. The description adds two pieces of genuinely useful context beyond that: the required OAuth scope and the bounded/opaque nature of page_token retrieval. It does not describe pagination limits or return shape beyond the schema, so a 3 is appropriate.

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?

Four short sentences, front-loaded with the resource. Docked one point because 'Reads Calendly data.' conveys no information and could be dropped without loss.

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?

For a 9-parameter list tool with no output schema and no required parameters, the description is thin: it never says what a membership record contains or that results are paginated by default. The scope note and annotations fill part of the gap, but an agent still lacks return-shape context.

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% across all 9 parameters, so the schema already documents each filter, count bounds, page_token, and all_pages/max_items semantics. The description adds no parameter-level meaning (e.g., interaction between all_pages and count is undocumented), so the baseline 3 applies.

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

Purpose3/5

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

The first sentence restates the title verbatim, and the second ('Reads Calendly data.') is generic filler. The verb+resource (list organization memberships) is nonetheless identifiable, but nothing distinguishes it from siblings like get_organization_membership, list_organization_invitations, or list_teams.

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?

There is no when-to-use guidance and no disambiguation from the many sibling list/get tools. The only usage-relevant content is the 'Required scopes: organizations:read' prerequisite, which is a partial but real hint; otherwise the agent must infer everything.

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

list_outgoing_communicationsList outgoing communicationsB

Read-onlyIdempotent

List outgoing communications. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: outgoing_communications:read.

ParametersJSON Schema

Name	Required	Description
`count`	No	The number of records to return
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next portion of the collection
`organization`	Yes	Return outgoing communications from the organization associated with this URI
`max_created_at`	No	Include outgoing communications that were created prior to this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone
`min_created_at`	No	Include outgoing communications that were created after this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds two pieces of context beyond that: the required OAuth scope (outgoing_communications:read) and that page_token retrieval is 'bounded opaque', warning the agent not to treat it as an unbounded scan.

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?

Four short, front-loaded sentences with no padding; the scope requirement is easy to spot. 'Reads Calendly data' is mild filler that could be dropped, keeping it just short of a 5.

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?

With 8 parameters fully documented in the schema and annotations covering the safety profile, the description is adequate. It omits anything about result ordering (e.g., by created_at) or what an 'outgoing communication' record actually contains, which matters given there is no output schema.

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 the schema already documents count, account, all_pages, max_items, page_token and the created-at bounds. The description only echoes page_token usage and adds no format or defaulting detail beyond the schema, which is the expected baseline 3.

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 opens with a specific verb+resource ('List outgoing communications'), matching the title but stating the operation plainly. It does not, however, differentiate itself from any sibling (e.g., list_activity_log or list_events), so an agent gets no help distinguishing similar list 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?

'Reads Calendly data' restates the obvious and gives no when-to-use guidance. There is no mention of alternatives, no condition for choosing this tool over list_activity_log or list_events, and no exclusions.

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

list_recapsList RecapsB

Read-onlyIdempotent

List Recaps. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: meeting_recaps:read.

ParametersJSON Schema

Name	Required	Description
`count`	No	The number of rows to return
`event`	No	Filter results to recaps associated with a specific event scheduled via Calendly. This field corresponds to the `/scheduled_events` endpoint.
`status`	No	Filter by recap availability. When omitted, returns Available recaps only. - `available` — completed recaps with summary content - `processing` — recaps still being generated - `unavailable` — recaps that cannot be retrieved
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`attendee`	No	Filter results to recaps that include a specific attendee email address.
`end_time`	No	Return recaps for meetings that start before (or start at) this time (ISO 8601).
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection
`start_time`	No	Return recaps for meetings that end after (or end at) this time (ISO 8601).

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely new context: the required OAuth scope (meeting_recaps:read) and the fact that retrieval is bounded-opaque-pagination based, which an agent needs for auth planning.

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?

Three terse sentences, front-loaded with the operation and then the two added facts. Nothing is padded, though the fragments read more like generated scaffolding than a tight human sentence.

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 safe read-only list tool with a rich 10-param schema and full annotations, the description covers the missing pieces (scope requirement, pagination nature). The default-status-filter behavior and return shape live in the schema, which is acceptable given no output schema requirement.

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 all ten parameters are already fully documented in the schema (including the status default and page_token semantics). The description adds no parameter-level detail, so the baseline 3 applies.

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

Purpose3/5

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

The description states a verb+resource ("List Recaps") and adds that it reads Calendly data, so the basic purpose is clear. However, it does nothing to distinguish it from the adjacent get_recap, update_recap, and delete_recap siblings, and "Reads Calendly data" is filler rather than differentiation.

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?

There is no guidance on when to use list_recaps versus get_recap or the other recap tools, and no described conditions or prerequisites. The only usable signal is the implied read-vs-mutate split from the name.

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

list_routing_formsList Routing FormsB

Read-onlyIdempotent

List Routing Forms. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: routing_forms:read.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: created_at. Sort direction is specified as: asc, desc.
`count`	No	The number of rows to return
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection
`organization`	Yes	View organization routing forms associated with the organization's URI.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, idempotentHint, openWorldHint), so the bar is lower. The description still adds genuinely useful context beyond them: the required OAuth scope (routing_forms:read) and the fact that pagination is bounded opaque page_token retrieval, which signals quota-consuming, non-snapshot behavior.

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?

Three short, front-loaded sentences with the resource name first and no redundancy. "Reads Calendly data" is mild filler, but nothing is bloated or buried.

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?

For a read-only list tool with full schema coverage and clear annotations, the description is adequate but thin. With no output schema present, it could have said something about what records are returned or the pagination shape; as written it leaves return-value expectations entirely to inference.

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%, and each parameter (sort, count, account, all_pages, max_items, page_token, organization) is documented in the schema itself. The description adds no parameter-level detail, so the baseline 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 states a specific verb and resource ("List Routing Forms") that an agent can immediately act on. It is clearly distinct from the sibling get_routing_form (list vs. single-fetch), but it never explicitly draws that contrast or names the sibling, so it falls short of the top score.

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?

There is no statement of when to use this tool versus alternatives such as get_routing_form or list_routing_form_submissions. The only contextual hint is the required scope, which tells the agent about permissions but not usage conditions.

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

list_routing_form_submissionsList Routing Form SubmissionsC

Read-onlyIdempotent

List Routing Form Submissions. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: routing_forms:read.

ParametersJSON Schema

Name	Required	Description
`form`	Yes	View routing form submissions associated with the routing form's URI.
`sort`	No	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: created_at. Sort direction is specified as: asc, desc.
`count`	No	The number of rows to return
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that with 'Required scopes: routing_forms:read' and the bounded page_token note, but says nothing about quota cost, result format, or completeness guarantees.

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?

Four short sentences, front-loaded with the operation and free of padding. The only soft filler is 'Reads Calendly data,' which conveys almost nothing.

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?

With no output schema, the description should hint at what submissions look like or how continuation state is returned when using all_pages/max_items, but it does not. The auth-scope note and pagination hint partially compensate, leaving it adequate but incomplete for a 7-parameter listing 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 the schema already documents all seven parameters including sort syntax, count bounds, and page_token semantics. The description's 'bounded opaque page_token retrieval' adds only a marginal gloss on page_token, so the baseline 3 is appropriate.

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

Purpose2/5

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

The first sentence is a verbatim restatement of the tool's name/title, which is the definition of a tautological purpose statement. It never distinguishes this tool from close siblings like list_routing_forms or get_routing_form_submission, so an agent gains nothing about scope from the description itself.

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?

There is no when-to-use guidance and no mention of alternatives among the many siblings (e.g., get_routing_form_submission for a single record). The only routing hint is the phrase 'Supports bounded opaque page_token retrieval,' which is a capability note rather than usage guidance.

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

list_teamsList TeamsB

Read-onlyIdempotent

List Teams. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: organizations:read.

ParametersJSON Schema

Name	Required	Description
`user`	No	Filter results to Teams associated with a specific user
`count`	No	The number of rows to return
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, so safety is covered. The description adds the required scope (organizations:read) and notes pagination is opaque/bounded, which is useful auth and retrieval context. It does not disclose quota-per-request behavior or that all_pages is not a complete snapshot, though the schema does.

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?

Three short, front-loaded fragments: purpose, data domain, retrieval behavior, scopes. No wasted words, though the terse fragment style leaves little connective context for why each clause matters.

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?

For a read-only list tool with full schema coverage and rich annotations, the description is adequate: it names the resource, the data source, the pagination model, and the required scope. It omits the relationship to sibling team/group tools and the filter semantics, which would help an agent choose correctly among list_teams, list_groups, and get_team. No output schema exists, so return shape is also unaddressed.

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 all six parameters carry their own descriptions in the schema. The description adds only a general note that page_token retrieval is bounded, which the schema already conveys via max_items/all_pages. Baseline 3 is appropriate when the schema does the work.

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?

States a clear verb (List) and resource (Teams), and the scope 'Reads Calendly data' tells the agent this is a Calendly-team collection. It does not name or differentiate itself from the sibling get_team/list_groups, but the resource is unambiguous.

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 hints at pagination via 'bounded opaque page_token retrieval' but never states when to use this tool versus get_team or list_groups, nor when to prefer account vs user filtering. Usage context is implied by the schema parameters rather than specified.

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

list_user_busy_timesList User Busy TimesC

Read-onlyIdempotent

List User Busy Times. Reads Calendly data. Required scopes: availability:read.

ParametersJSON Schema

Name	Required	Description
`user`	Yes	The uri associated with the user
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`end_time`	Yes	End time of the requested availability range. Date must be in the future of start_time.
`start_time`	Yes	Start time of the requested availability range. Date cannot be in the past.

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral fact is the required OAuth scope ("availability:read"), which is genuinely useful auth context, but nothing about pagination, result shape, or failure modes is disclosed. Modest value-add over annotations justifies a 3.

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?

Three short, front-loaded sentences with no verbosity. The only inefficiency is that the opening sentence duplicates the title rather than using that space for scope or usage detail.

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?

With rich annotations, a fully covered schema, and no output schema, the description need not explain returns, but it still omits any usage context distinguishing it from sibling availability tools. It is minimally adequate for a query endpoint but leaves the selection decision to the 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 description coverage is 100%, and the schema fully documents all four parameters including the start_time/end_time future/past constraints and the account credential selector. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

Purpose2/5

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

The first sentence, "List User Busy Times," is a verbatim restatement of the tool's title and adds no information beyond the name. There is no elaboration of scope such as whose busy times, over what period, or how this differs from sibling availability tools like list_availability_schedules or list_event_type_available_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?

The description gives no indication of when to use this tool versus the numerous availability-related siblings (list_availability_schedules, get_availability_schedule, list_event_type_available_times). No preconditions, exclusions, or alternative-routing cues are provided.

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

list_user_locationsList User Meeting LocationsB

Read-onlyIdempotent

List User Meeting Locations. Reads Calendly data. Required scopes: locations:read.

ParametersJSON Schema

Name	Required	Description	Default
`user`	Yes	The URI associated with the user
`account`	No	Named private Calendly account; selects credentials, not an organization URI.

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context with the required OAuth scope ('locations:read'), which annotations do not carry, but says nothing about pagination or return shape.

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?

Three short statements, all front-loaded and free of filler. Nothing is wasted, though the content is thin relative to what a full definition could carry.

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?

For a simple two-parameter read with no output schema and full annotation coverage, the definition is minimally adequate. It lacks any mention of result volume, pagination, or how locations relate to the user, which an agent might need for a list endpoint.

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 both the 'user' URI and the 'account' credential selector are already documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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?

States a specific verb and resource ('List User Meeting Locations') and identifies the data domain ('Reads Calendly data'). It does not differentiate from sibling list tools such as list_user_busy_times or list_availability_schedules, so it falls short of a 5.

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 the many sibling list tools, and no prerequisites or exclusions stated. The scope requirement hints at eligibility but does not tell the agent when this call is the right choice.

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

list_webhooksList Webhook SubscriptionsB

Read-onlyIdempotent

List Webhook Subscriptions. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: webhooks:read.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Order results by the specified field and direction. Accepts comma-separated list of {field}:{direction} values. Supported fields are: created_at. Sort direction is specified as: asc, desc.
`user`	No	Indicates if the results should be filtered by user. This parameter is only required if the `scope` parameter is set to `user`.
`count`	No	The number of rows to return
`group`	No	Indicates if the results should be filtered by group. This parameter is only required if the `scope` parameter is set to `group`.
`scope`	Yes	Filter the list by organization, user, or group
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`all_pages`	No	Read bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`page_token`	No	The token to pass to get the next or previous portion of the collection
`organization`	Yes	The given organization that owns the subscriptions being returned. This field is always required.

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it 'Reads Calendly data' and needs 'webhooks:read' scope, plus mentions bounded opaque page_token retrieval. It doesn't explain pagination behavior or the quirk that 'each request consumes quota' (that's only in the schema). A 3 is appropriate given the annotations cover the safety profile.

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?

Four short sentences, front-loaded with the core purpose and scoping, then auth requirements. No wasted words.

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?

Given the annotations carry safety/idempotency, and schema has 100% coverage with a detailed 10-param surface, the description covers the essentials: it's a read, needs webhooks:read, supports pagination. It doesn't explain the account param or the all_pages/max_items interplay, but those are in the schema. Slightly incomplete for a complex tool but adequate.

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%, so the schema already documents all parameters in detail (including max_items, all_pages, page_token). The description only mentions 'bounded opaque page_token retrieval' generically. Baseline 3 is correct when the schema does the heavy lifting.

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?

States a clear verb and resource: 'List Webhook Subscriptions.' It doesn't explicitly differentiate from sibling get_webhook, but the plural 'List' and read-only nature makes the distinction reasonably clear.

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 vs get_webhook or how to choose between scopes/accounts. The required scopes hint is useful but doesn't tell the agent when this tool is the right choice.

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

remove_from_organizationRemove User from OrganizationA

Destructive

Remove User from Organization. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: organizations:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`membership_uuid`	Yes	The organization membership's unique identifier

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: that it 'Changes Calendly state' and requires the organizations:write scope, which tells the agent about authorization needs and the confirmation gate.

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?

Three short, front-loaded sentences with no filler; the confirmation and scope constraints come early. The opening sentence does slightly restate the title, preventing a 5.

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 destructive write tool with no output schema, the description covers the key agent-facing facts: state change, confirmation requirement, and required scope. It omits downstream effects (e.g., what happens to the user's owned resources or reversibility), but the annotations carry the destructive warning.

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 all three parameters (account, confirm, membership_uuid) are already documented in the schema. The description only echoes the confirm requirement and adds no syntax or format detail, matching the baseline of 3.

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 states a specific verb and resource ('Remove User from Organization'), so the operation itself is unambiguous. It does not differentiate from near-neighbors such as revoke_organization_invitation or get_organization_membership, so it falls short of a 5.

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?

It states a prerequisite ('requires confirm=true') but gives no guidance on when to use this tool versus alternatives like revoke_organization_invitation or deleting a contact. No when-not conditions or context of use are offered.

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

revoke_organization_invitationRevoke User's Organization InvitationA

Destructive

Revoke User's Organization Invitation. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: organizations:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`org_uuid`	Yes	The organization’s unique identifier
`invitation_uuid`	Yes	The organization invitation's unique identifier

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds two useful behavioral facts beyond the annotations: it changes Calendly state and requires confirm=true. It does not, however, state the permanence of the revocation, whether the invitee is notified, or what it returns, so some transparency is still missing.

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?

Two sentences, front-loaded with the action, then the confirm and scope requirements. No filler. The title is repeated as the first sentence, which is slightly redundant, but it is not wasteful.

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 destructive, non-idempotent, open-world write tool with no output schema, the description supplies the scope requirement and the confirm gate, which are the two most likely causes of a failed call. It omits return behavior, post-revocation state, and side effects, but the annotations already flag destructiveness and non-idempotency, so the remaining gap is small.

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% — every parameter has a description. The description adds one semantic point the schema does not: 'requires confirm=true for the specific requested action', which explains the confirm flag's condition. The remaining parameters (org_uuid, invitation_uuid, account) are already fully documented in the schema, so 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?

States a specific verb + resource: 'Revoke User's Organization Invitation'. It maps directly to a distinct resource and is distinguishable from siblings like remove_from_organization (a membership) and delete_contact (a different entity). An agent can tell what it does without reading the schema.

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?

There is no when-to-use guidance, no explicit alternative (e.g., 'use this to cancel a pending invitation; use remove_from_organization to revoke an active member'), and no prerequisites beyond the scope line. The scopes hint at required permission but do not tell the agent when to choose this over siblings.

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

update_contactUpdate ContactC

Destructive

Update Contact. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: contacts:write.

ParametersJSON Schema

Name	Required	Description
`city`	No
`name`	No
`state`	No
`emails`	No	The user's email addresses. Max 10. <br> <span style="color:red">Warning: </span>Updating emails will overwrite all existing emails for the contact. Use the GET endpoint to first retrieve the existing emails and then pass the modified emails to the emails array.
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`company`	No
`confirm`	No	Must be true for the specific user-requested write.
`country`	No
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`linkedin`	No
`timezone`	No
`job_title`	No
`contact_uuid`	Yes
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`custom_fields`	No	Custom field values to set on the contact. Each item requires a `uuid` (the custom field definition identifier) and a `value`; any other keys (such as `label`) are ignored. The entire request is rejected if any `uuid` is unknown, any `value` is the wrong type for its field (including an array for a scalar field or a scalar for an array field), or any `single_select` `value` is not one of the field definition's option `uuid`s.
`phone_numbers`	No	The user's phone numbers. Max 10. <br> <span style="color:red">Warning: </span>Updating phone_numbers will overwrite all existing phone numbers for the contact. Use the GET endpoint to first retrieve the existing phone numbers and then pass the modified phone_numbers to the phone_numbers array.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description does add real value beyond them: the mandatory confirm=true flag and the contacts:write scope requirement. However it omits the most important behavioral hazard — that emails and phone_numbers are wholesale overwritten — which is left entirely to the schema.

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

Conciseness3/5

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

It is short and front-loaded, but the opening "Update Contact." is pure tautology that consumes space without earning it. The two substantive sentences (confirm requirement, scope) are dense and useful, so the size is fine but efficient use of the first sentence is not.

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?

For a destructive 16-parameter mutation with nested objects, no output schema, and three competing input mechanisms (payload, payload_file, body flags), this description is far too thin. An agent still cannot tell which input mode to use or how the overwrite semantics on arrays behave from the description alone.

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

Parameters2/5

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

With 16 parameters at 44% schema coverage, the description needs to compensate and does not. It explains only the confirm flag, saying nothing about contact_uuid, the account credential selector, or the mutually exclusive payload / payload_file / body-flag input modes that dominate this schema.

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

Purpose3/5

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

"Update Contact" merely restates the tool name and title, so the resource/verb pair adds nothing new. The phrase "Changes Calendly state" confirms it is a mutation but does not say which contact fields are updatable or distinguish it from create_contact/delete_contact/get_contact. Purpose is identifiable but vague.

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?

There is no when-to-use guidance, no conditions for choosing this over get_contact or create_contact, and no exclusions. The mention of confirm=true and the required scope is a precondition, not a usage guideline. An agent gets no routing help.

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

update_event_typeUpdate Event TypeB

Destructive

Update Event Type. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: event_types:write.

ParametersJSON Schema

Name	Required	Description
`name`	No	The event type name
`color`	No	The hexadecimal color value of the event type's scheduling page
`active`	No	Indicates if the event type is active or not
`locale`	No	The locale on the event type, used to determine the language of the event type's scheduling page
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`duration`	No	The length of sessions booked with this event type. Must be one of the duration options if they're provided.
`locations`	No	Configuration information for each possible location for this Event Type
`description`	No	The event type description
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`event_type_uuid`	Yes
`duration_options`	No	A maximum of 4 unique options is allowed. Each option must be >= 1 and <= 720.

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, so safety profile is covered. The description adds the confirm=true guard requirement and the required scope (event_types:write), which are useful beyond annotations, but doesn't explain what gets overwritten or side effects.

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?

Three short sentences, front-loaded with the action. The 'specific requested action' phrasing is slightly cryptic but overall tight and scannable.

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?

A 13-parameter mutation tool with nested payload support and no output schema warrants more explanation of request body modes (payload vs payload_file vs flags) and the confirm guard's exact semantics. The description leaves the agent to infer the write-guard mechanics.

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 92%, so parameters are well-documented in structured data. The description adds only the confirm guard and scope, not field-level meaning beyond the schema. Baseline 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?

States a clear verb+resource ('Update Event Type'), distinguishing it from siblings like create_event_type and get_event_type. However, it doesn't enumerate which fields are updatable or differentiate from update_event_type_availability_schedules.

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 when-to-use guidance or alternatives named. The confirm=true requirement hints at a write-guard pattern but doesn't explain when the tool should or shouldn't be invoked versus create_event_type or availability schedule tools.

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

update_event_type_availability_schedulesUpdate Event Type Availability SchedulesB

Destructive

Update Event Type Availability Schedules. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: availability:write.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`event_type`	Yes	Event Type uri in which to update the availability schedule
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`availability_rule`	No
`availability_setting`	No	By default every host on the Event Type shares an identical schedule.	host

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond the annotations: it must change Calendly state and requires confirm=true plus the availability:write scope. It stops short of describing the destructive overwrite of existing rules (that lives only in the schema).

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?

Three short sentences, front-loaded, with no padding. The only minor waste is the opening sentence, which merely repeats the title, but the overall structure is tight and scannable.

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?

For a destructive, non-idempotent mutation the description covers scope and the confirm gate, and annotations plus an 86%-covered schema carry the rest (including the rule-overwrite warning). It is adequate but does not surface the destructive overwrite behavior in the description itself, which would help an agent avoid data loss.

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 86% (high), so the schema already documents the parameters, including the overwrite warning on rules and the user/admin constraint. The description adds no syntax or format detail beyond what the schema provides. Baseline 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 states a specific verb+resource (update event type availability schedules), so an agent understands the general operation. However, the first sentence is a verbatim restatement of the title and provides no differentiation from siblings like list_event_type_availability_schedules or update_event_type. Clear but undifferentiated.

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?

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The description notes the required scope (availability:write) and confirm=true, which is auth context, not usage routing. An agent gets no help distinguishing this from sibling update or list tools.

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

update_recapUpdate RecapA

Destructive

Update Recap. Changes Calendly state and requires confirm=true for the specific requested action. Required scopes: meeting_recaps:write.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Calendly account; selects credentials, not an organization URI.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
`recap_uuid`	Yes
`summary_md`	No	Summary in Markdown.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`discussion_md`	No	Discussion notes in Markdown.
`action_items_md`	No	Action items in Markdown.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds genuine value beyond them by disclosing the confirm=true guard and the required scope (meeting_recaps:write), both of which matter for invoking a destructive write correctly.

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?

Two short sentences, front-loaded with the verb+resource, no filler or redundancy. It is terse and efficient, though fragmentary in style rather than fully polished.

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 destructive mutation tool with no output schema, the description covers the key behavioral elements (state change, confirm guard, required scope) and the rich nested schema covers parameters. It is adequately complete, though it could note what a recap contains or the mutation's consequence more explicitly.

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 high (88%), so the schema documents parameters like confirm, payload, and the *_md fields adequately; baseline is 3. The description only reinforces the confirm parameter and adds no new syntax or format 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?

States a specific verb (Update) and resource (Recap), making the intent clear against siblings like get_recap/delete_recap. However, 'Changes Calendly state' is vague about what specifically is mutable (summary/discussion/action items), relying on the schema for that detail, and no sibling is explicitly named.

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 versus alternatives such as delete_recap or get_recap. The only contextual hint is the prerequisite that confirm=true is required, which is a precondition rather than true when-to-use guidance.

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.

66 tool updatesv2.0.0Oct 2, 2026
- First observedcancel_event
- First observedcreate_contact
- First observedcreate_event_type
- First observedcreate_invitee
- First observedcreate_no_show
- First observedcreate_one_off_event_type
- First observedcreate_scheduling_link
- First observedcreate_share
- First observedcreate_webhook
- First observeddelete_contact
- First observeddelete_invitee_data
- First observeddelete_no_show
- First observeddelete_recap
- First observeddelete_scheduled_event_data
- First observeddelete_webhook
- First observedget_availability_schedule
- First observedget_contact
- First observedget_contact_custom_field_definition
- First observedget_current_user
- First observedget_event
- First observedget_event_invitee
- First observedget_event_type
- First observedget_group
- First observedget_group_relationship
- First observedget_no_show
- First observedget_organization
- First observedget_organization_invitation
- First observedget_organization_membership
- First observedget_recap
- First observedget_routing_form
- First observedget_routing_form_submission
- First observedget_sample_webhook_data
- First observedget_team
- First observedget_transcript
- First observedget_user
- First observedget_webhook
- First observedinvite_to_organization
- First observedlist_accounts
- First observedlist_activity_log
- First observedlist_availability_schedules
- First observedlist_contact_custom_field_definitions
- First observedlist_contacts
- First observedlist_event_invitees
- First observedlist_event_type_availability_schedules
- First observedlist_event_type_available_times
- First observedlist_event_type_hosts
- First observedlist_event_types
- First observedlist_events
- First observedlist_group_relationships
- First observedlist_groups
- First observedlist_organization_invitations
- First observedlist_organization_memberships
- First observedlist_outgoing_communications
- First observedlist_recaps
- First observedlist_routing_form_submissions
- First observedlist_routing_forms
- First observedlist_teams
- First observedlist_user_busy_times
- First observedlist_user_locations
- First observedlist_webhooks
- First observedremove_from_organization
- First observedrevoke_organization_invitation
- First observedupdate_contact
- First observedupdate_event_type
- First observedupdate_event_type_availability_schedules
- First observedupdate_recap

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.9/5.0

Scored 2026-10-02 19:50 across 66 tools

Disambiguation3/5

Tool names are mostly distinct, but many share similar patterns (e.g., get_group_relationship vs list_group_relationships; get_event_type vs list_event_type_availability_schedules; get_contact vs get_contact_custom_field_definition) and there are two tools named 'get_current_user' and 'get_user', 'list_events' vs 'list_activity_log' (which may overlap), and 'list_teams' vs 'list_groups' which could be confused. Descriptions help but the volume and specificity create occasional ambiguity.

Naming Consistency4/5

Names follow a consistent verb_noun pattern with snake_case throughout (e.g., get_, list_, create_, update_, delete_). The pattern is largely predictable, with only minor deviations such as 'create_one_off_event_type' and 'invite_to_organization' that slightly break the regular noun phrase structure.

Tool Count2/5

With 66 tools, the surface is very large for a single MCP server, likely overwhelming for an agent and increasing selection errors. While Calendly's API is broad, this exceeds the typical 3-15 range for well-scoped servers and would benefit from splitting by functional area or using more generic resource-oriented tools.

Completeness4/5

The set covers a wide range of Calendly domains (users, events, invitees, event types, availability, groups, organizations, routing forms, webhooks, etc.) with CRUD operations for many. However, a few gaps exist: no delete for event types (only create/update), no update for webhooks, and limited CRUD for routing forms (only read operations). These are minor gaps that agents can largely work around.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Chronary A
ai.chronary
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
Calendar Management Workplace & Productivity
542
ComposioOAuth
io.github.ComposioHQ
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
Agent Orchestration App Automation
21
ScrollportOAuth
com.scrollport
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Agent Orchestration Developer Tools
1
Kalender Sync A
de.kalender-sync
GDPR-compliant calendar access for AI assistants: read, create, edit, RSVP. Google, MS 365, Apple.
Calendar Management Workplace & Productivity
81

Related MCP Servers

mcp-calendly
Calendar Management App Automation
shwetank-dev
A
license
A
quality
C
maintenance
Enables interaction with Calendly to manage event types, scheduled events, and invitees. It provides tools for checking user availability and canceling appointments directly through the Calendly API.
Updated 8 months ago (2026-02-18 16:02 UTC)
7
MIT
Cal.com MCP Server
Calendar Management Workplace & Productivity
imubashir9
A
license
Not graded
quality
D
maintenance
Exposes Cal.com scheduling tools to AI agents via MCP, enabling listing event types, checking availability, and managing bookings (create, cancel, reschedule).
Updated 6 months ago (2026-04-02 11:39 UTC)
570 npm
MIT
Chronaryofficial
Calendar Management Workplace & Productivity
Chronary
A
license
A
quality
C
maintenance
Calendar API purpose-built for AI agents. Exposes tools to manage agents, calendars, and events, find meeting times, run scheduling proposals, set availability rules, manage webhooks, and subscribe to iCal feeds.
Updated 3 months ago (2026-07-14 21:12 UTC)
54
86 npm
Apache 2.0
Calendly MCP Server
Calendar Management App Automation
pranjalkumar-evonence
F
license
Not graded
quality
D
maintenance
Exposes personal Calendly account as MCP tools, allowing users to manage events, view availability, and handle bookings through natural language.
Updated 3 months ago (2026-07-01 10:16 UTC)
-

Calendly MCP Server & CLI

Two ways to use it

Command line

MCP server, for your AI app

Which one

Features

Contents

1. What you can ask it

2. Quick install

3. Set up Calendly access

Personal Access Token for your own account

Existing REST OAuth grant

Scopes, roles and plans

Current request limits

Official hosted MCP is a separate connection

4. Connect your client

5. Check it works

6. Output, flags and exit codes

7. MCP or CLI and token cost

8. Every tool and argument

list_activity_log

get_availability_schedule

list_event_type_availability_schedules

update_event_type_availability_schedules

list_availability_schedules

list_user_busy_times

create_contact

list_contacts

delete_contact

get_contact

update_contact

get_contact_custom_field_definition

list_contact_custom_field_definitions

delete_invitee_data

delete_scheduled_event_data

create_event_type

list_event_types

create_one_off_event_type

get_event_type

update_event_type

list_event_type_available_times

list_event_type_hosts

get_group

get_group_relationship

list_group_relationships

list_groups

list_user_locations

delete_recap

get_recap

update_recap

get_transcript

list_recaps

get_organization

get_organization_invitation

revoke_organization_invitation

get_organization_membership

remove_from_organization

get_team

invite_to_organization

list_organization_invitations

list_organization_memberships

list_teams

list_outgoing_communications

get_routing_form

get_routing_form_submission

list_routing_form_submissions

list_routing_forms

cancel_event

create_invitee

create_no_show

delete_no_show

get_no_show

get_event

get_event_invitee

list_event_invitees

list_events

create_scheduling_link

create_share

get_current_user

get_user