Skip to main content
Glama
thenavidm

Calendly MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Update Contact

update_contact
Destructive

Update an existing Calendly contact's details, such as name, emails, phone numbers, and custom fields. Requires the contact UUID and confirm=true to apply write changes.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNo
nameNo
stateNo
emailsNoThe 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.
accountNoNamed private Calendly account; selects credentials, not an organization URI.
companyNo
confirmNoMust be true for the specific user-requested write.
countryNo
payloadNoComplete JSON request body instead of body flags. Supports nested booking, contact, availability and nullable fields.
linkedinNo
timezoneNo
job_titleNo
contact_uuidYes
payload_fileNoRegular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
custom_fieldsNoCustom 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_numbersNoThe 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

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.

Deploy Server

Other Tools