mcp-calendly

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions in the Calendly domain. For example, 'get_event' retrieves details of a single event, while 'list_scheduled_events' lists multiple events with filters, and 'cancel_event' performs a distinct cancellation action. There is no overlap or ambiguity in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with clear, descriptive actions (e.g., 'cancel_event', 'get_current_user', 'list_event_types'). The naming is uniform across all seven tools, using snake_case consistently without any deviations or mixed conventions.
Tool Count5/5
With 7 tools, this server is well-scoped for managing Calendly events and user interactions. The count is appropriate for the domain, covering core operations like checking availability, listing events, and managing event details without being overly sparse or bloated.
Completeness4/5
The tool set provides strong coverage for core Calendly workflows, including event listing, retrieval, cancellation, availability checks, and user profile access. A minor gap exists in the lack of a tool for creating or scheduling new events, which agents might need to work around, but the surface is otherwise comprehensive for the inferred domain.
Average 3.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral details beyond the annotations, which already indicate read-only operation via 'readOnlyHint: true'. It fails to disclose aspects like error handling, authentication needs, or rate limits, but since annotations cover safety, a baseline score is appropriate without contradiction.
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 a single, clear sentence that efficiently states the tool's purpose without unnecessary words. It is appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
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?
Given the tool's simplicity (one parameter, read-only annotation, no output schema), the description is minimally adequate. However, it lacks details on return values or error cases, which would enhance completeness, especially without an output schema to compensate.
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?
With 100% schema description coverage, the input schema fully documents the 'event_uuid' parameter. The description does not add any extra meaning or context about the parameter, such as format examples or sourcing, so it meets the baseline for high 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?
The description clearly states the verb ('Get details') and resource ('specific scheduled event'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'list_scheduled_events' or 'list_invitees', which might also retrieve event-related information, so it falls short of a perfect 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?
The description provides no guidance on when to use this tool versus alternatives, such as 'list_scheduled_events' for multiple events or 'list_invitees' for attendee details. It lacks context on prerequisites or exclusions, offering only a basic statement of function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, indicating this is a mutation operation. The description adds minimal behavioral context beyond this—it doesn't specify whether cancellation is reversible, if notifications are sent, or what happens to associated data. With annotations covering the safety profile, a 3 is appropriate as the description adds little extra value.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy.
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?
Given the tool's complexity (a destructive operation with 2 parameters), the description is minimally adequate. It lacks output details (no output schema exists) and behavioral nuances, but annotations cover the destructive nature. For a simple cancel action, it meets basic needs but could be more informative about side effects or 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%, with both parameters ('event_uuid' and 'reason') fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is correct when the schema does all 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 clearly states the action ('Cancel') and resource ('a scheduled Calendly event'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential alternatives like deleting or rescheduling events, which could exist in a broader Calendly API context.
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. It doesn't mention prerequisites (e.g., needing an existing scheduled event), exclusions, or relationships with sibling tools like 'get_event' or 'list_scheduled_events' that might help identify events to cancel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which the description aligns with by using 'Get' (implying a read operation). The description adds minimal behavioral context beyond annotations, such as specifying it returns 'time slots' but not detailing format, pagination, or rate limits. With annotations covering safety, it meets baseline but lacks rich disclosure.
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, efficient sentence with zero waste. It is front-loaded with the core purpose and appropriately sized for the tool's complexity, making it easy to parse quickly.
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?
Given the tool has annotations (readOnlyHint) and high schema coverage, the description is minimally adequate. However, with no output schema, it does not explain return values like slot format or error cases, and it lacks context on usage relative to siblings. For a read operation with three parameters, it could be more complete but meets basic needs.
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 the three parameters (event_type_uri, start_time, end_time). The description adds no additional meaning beyond implying these are used to 'check availability', which is already inferred from the tool name and schema. Baseline 3 is appropriate as the schema handles 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 clearly states the verb 'Get' and the resource 'available time slots for an event type', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'list_scheduled_events' or 'list_event_types', which might also involve time-related queries, so it misses full sibling distinction.
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. It lacks context on prerequisites, such as needing a valid event type URI, and does not mention when-not scenarios or direct comparisons to siblings like 'list_scheduled_events' for checking existing events versus availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds no behavioral context beyond what annotations provide - no information about rate limits, authentication needs, or what happens when no event types exist. No contradiction with annotations exists.
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, clear sentence that efficiently communicates the core purpose without any wasted words. It's appropriately sized for a simple list operation and gets straight to the point.
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 list tool with read-only annotations and full parameter documentation, the description is minimally adequate. However, without an output schema, it doesn't describe what the return values look like (e.g., array of event type objects with specific fields), leaving the agent uncertain about the response format.
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?
With 100% schema description coverage, the input schema fully documents both parameters (count with range 1-100, page_token for pagination). The description adds no parameter information beyond what the schema provides, so it meets the baseline for high 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?
The description clearly states the action ('List') and resource ('the user's Calendly event types'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_invitees' or 'list_scheduled_events' beyond specifying 'event types'.
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. It doesn't mention when this tool is appropriate compared to 'get_event' or 'list_scheduled_events', nor does it specify any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. Annotations already declare readOnlyHint=true, indicating a safe read operation. The description implies listing invitees, but does not disclose details like pagination behavior (though hinted by 'page_token' in schema), rate limits, or authentication needs, offering only basic operational intent.
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, clear sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficiently communicates the core purpose, making it highly concise and well-structured.
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?
Given the tool's moderate complexity (3 parameters, no output schema) and good schema coverage, the description is adequate but incomplete. It lacks details on output format, error handling, or integration with sibling tools, which could enhance agent understanding, though annotations cover safety aspects.
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?
With 100% schema description coverage, the input schema fully documents all parameters (event_uuid, count, page_token). The description does not add any additional meaning or context about these parameters, such as how 'event_uuid' is obtained or the implications of pagination, so it meets the baseline without extra value.
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 clearly states the action ('List') and resource ('invitees for a scheduled event'), making the tool's purpose immediately understandable. However, it does not differentiate from sibling tools like 'get_event' or 'list_scheduled_events', which might also involve event-related data retrieval, so it lacks explicit distinction.
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. For example, it does not specify if this is the primary method for retrieving invitee information or if other tools like 'get_event' might include invitee data, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds that it lists events with optional filters, which offers some context beyond annotations. However, it doesn't disclose behavioral traits like pagination handling (implied by page_token), rate limits, authentication needs, or what 'scheduled' specifically entails. With annotations covering safety, the description adds moderate value but misses key operational details.
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, efficient sentence that front-loads the core purpose ('List scheduled Calendly events') and adds key detail ('with optional filters'). There is no wasted text, and it's appropriately sized for a listing tool with clear annotations and schema.
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?
Given the tool's moderate complexity (5 parameters, no output schema), annotations cover safety, and schema fully describes inputs. The description is minimal but adequate for a read-only listing tool. However, it lacks details on output format, pagination behavior, or error handling, which could improve completeness for agent 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 parameters are well-documented in the schema. The description mentions 'optional filters', which aligns with parameters like status and time filters, but adds no semantic details beyond what the schema provides. This meets the baseline for high schema coverage, but doesn't enhance understanding of parameter use or interactions.
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 clearly states the action ('List') and resource ('scheduled Calendly events'), and mentions optional filters. It distinguishes from siblings like 'get_event' (single event) and 'list_event_types' (different resource), but doesn't explicitly contrast with 'list_invitees' (related but different). The purpose is specific but could better differentiate from similar listing tools.
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 for listing scheduled events with filters, but provides no explicit guidance on when to use this versus alternatives like 'get_event' for a single event or 'list_invitees' for participants. It mentions optional filters, which hints at context, but lacks clear when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying that it retrieves the 'authenticated' user's profile, which implies authentication is required, and clarifies the scope ('current user'), enhancing context beyond the annotations. No contradictions with annotations are present.
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, efficient sentence that front-loads the key information ('Get the authenticated Calendly user's profile') with zero waste. Every word earns its place, making it highly concise and well-structured for quick understanding.
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 tool's simplicity (0 parameters, read-only operation, no output schema), the description is complete enough for an agent to understand its purpose and usage. However, without an output schema, it could benefit from hinting at the return format (e.g., profile details), but the current description suffices for the low complexity.
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?
With 0 parameters and 100% schema description coverage, the input schema fully documents the absence of parameters. The description doesn't need to add parameter details, but it implicitly confirms no inputs are required by focusing on the output (user's profile), which is appropriate. Baseline for 0 parameters is 4, as it adequately addresses the lack of inputs.
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 clearly states the specific action ('Get') and resource ('authenticated Calendly user's profile'), distinguishing it from sibling tools like 'get_event' or 'list_event_types' which target different resources. It precisely defines what the tool does without being vague or tautological.
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 by specifying 'authenticated Calendly user', suggesting it's for retrieving the current user's data, but it doesn't explicitly state when to use this tool versus alternatives like 'list_invitees' or provide exclusions. The context is clear but lacks explicit guidance on alternatives or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-calendly MCP server](https://glama.ai/mcp/servers/shwetank-dev/mcp-server-calendly/badges/card.svg)](https://glama.ai/mcp/servers/shwetank-dev/mcp-server-calendly)

Score Badge

Copy to your README.md:

[![mcp-server-calendly MCP server](https://glama.ai/mcp/servers/shwetank-dev/mcp-server-calendly/badges/score.svg)](https://glama.ai/mcp/servers/shwetank-dev/mcp-server-calendly)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shwetank-dev/mcp-server-calendly'

If you have feedback or need assistance with the MCP directory API, please join our Discord server