Skip to main content
Glama
thenavidm

Calendly MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create Webhook Subscription

create_webhook
Destructive

Subscribe a POST endpoint to Calendly events such as invitee bookings, cancellations, or contact changes so your app gets real-time notifications. Requires confirm=true.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoThe URL where you want to receive POST requests for events you are subscribed to.
userNoThe unique reference to the user that the webhook will be tied to.
groupNoThe unique reference to the group that the webhook will be tied to.
scopeNoIndicates whether the webhook subscription scope is `organization`, `user`, or `group`
eventsNoList of user events to subscribe to.
accountNoNamed private Calendly account; selects credentials, not an organization URI.
confirmNoMust be true for the specific user-requested write.
payloadNoComplete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
signing_keyNoOptional secret key shared between your application and Calendly. See https://developer.calendly.com/api-docs/overview/webhooks/webhook-signatures for additional information.
organizationNoThe unique reference to the organization that the webhook will be tied to.
payload_fileNoRegular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

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.

Deploy Server

Other Tools