calendar-mcp

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 distinct purpose. list_calendars handles calendar metadata, search_events and find_free_time are clearly separated (scheduled events vs open slots), and CRUD operations plus RSVP are all unique. No overlapping or ambiguous tools.
Naming Consistency5/5
All tools use snake_case with a consistent verb_noun pattern: list_calendars, create_event, search_events, find_free_time, update_event, rsvp_event, delete_event. The naming is predictable and uniform.
Tool Count5/5
7 tools is well-scoped for a calendar server. The count covers essential operations without bloat, each tool earning its place in the surface.
Completeness5/5
The surface provides full lifecycle coverage: create, read (search), update, delete, plus calendar enumeration, free-time discovery, and event RSVP. No critical operations are missing for typical calendar workflows.
Average 4.4/5 across 7 of 7 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only mentions creating an event and returning an id. It omits important behavioral traits such as the permanence of creation, that non-default parameters like participants may send irreversible invitation emails, or any permission requirements.
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 two sentences, front-loaded with the primary action, and includes only essential supplementary guidance. No filler or redundant information.
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?
Despite a rich schema, the tool has 12 parameters and no annotations, and the description lacks critical context such as the participant email side effect, calendar selection default, or all-day event nuances. These details exist in the schema but are not surfaced in the description, making it insufficient for an agent to safely invoke the tool without deep parameter inspection.
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 detailed parameter descriptions for all 12 fields, so the baseline is 3. The tool description itself adds no parameter-level meaning beyond what the schema already provides.
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 'Create a calendar event' with a specific verb and resource, and notes it returns the new event's id. This distinguishes it from sibling tools like list_calendars, search_events, and update_event, especially with the explicit pointer to update_event for modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool (to create a new calendar event) and gives an alternative for a related operation: 'Use update_event to change an existing event.' This provides a clear when-not and alternative, covering the main ambiguity.
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?
No annotations are provided, so the description carries the burden of disclosing behavior. It states that it 'sets your participation status and sends a reply to the organizer,' which implies a write operation and communication side effect. However, it doesn't mention any potential consequences (e.g., whether the reply is sent to all attendees, if there are any restrictions on changing status, or if there's a confirmation step). The description is adequate but not rich in behavioral detail.
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 concise and well-structured. It opens with a clear one-sentence purpose, then adds a brief note about the side effect (sending a reply), and finally provides specific guidance for recurring events. Every sentence adds value without unnecessary fluff.
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 (2 parameters, no output schema, no nested objects), the description is fairly complete. It covers the main action, the side effect, and the special case of recurring events. It could mention whether the tool is idempotent or if there are any prerequisites (e.g., must be an invitee), but for a simple RSVP tool, this is sufficient.
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?
The input schema already provides 100% coverage for both parameters: 'id' is described as 'The event ID to RSVP to, as returned by search_events' and 'status' is described with the allowed values. The description adds context about recurring events (occurrence id vs series id) but doesn't add much beyond the schema. Since schema coverage is high, a baseline of 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?
The description clearly states the tool's purpose: 'Respond to a calendar event invitation' and specifies the action of setting participation status and sending a reply to the organizer. It distinguishes itself from sibling tools like create_event, update_event, and delete_event by focusing on the RSVP action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (responding to an invitation) and includes specific guidance for recurring events, explaining how to handle occurrences vs. the whole series. It doesn't explicitly mention when not to use it or name alternatives, but the context is sufficient for most cases.
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?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It does so by explaining the destructive difference between deleting one occurrence versus the entire series. It doesn't mention permissions or irreversibility, but the verb 'delete' plus the series nuance covers the main risk.
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?
Two sentences: the first states the action, the second provides the only necessary conditional guidance. No filler or repetition of schema details.
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 single-parameter delete tool with no output schema and no annotations, the description sufficiently covers the key scenario (recurring events) and the source of the ID is in the schema. Minor missing details like return value or explicit irreversibility are not critical given the tool's simplicity.
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?
Schema coverage is 100% and the schema describes 'id' as 'the event ID to delete, as returned by search_events.' The description adds meaning by explaining that the same parameter can be an occurrence id or a master id, which is critical for recurring events and goes beyond the schema description.
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?
Description uses a specific verb and resource: 'Delete a calendar event.' The recurring-event clause clarifies the scope of deletion, distinguishing it from siblings like update_event (modification) and search_events (querying).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit operational guidance for recurring events: 'pass an occurrence id to cancel just that occurrence, or the master id to delete the entire series.' This tells the agent when to use which ID, though it doesn't explicitly list alternative tools for other use cases.
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?
No annotations are provided, so the description carries the transparency burden. It discloses non-obvious behavior—'Recurring events are expanded into individual occurrences, so each occurrence has its own ID and can be updated or deleted independently'—which is critical for an agent to know. It also enumerates the return fields, compensating for the lack of an output schema. This goes beyond the name and provides meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense: a short purpose statement, a usage tip, a key behavioral note, and a return-details list. No sentences are redundant, and the most relevant facts appear early.
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?
For a search/list tool with five optional parameters and no output schema, the description covers the essential guidance: how to invoke, what behavior to expect (recurring expansion), and what results will contain. It does not spell out every default (those are in the schema) or mention ordering/result sorting, but for the tool's complexity it is sufficiently complete. The absence of annotations is compensated by this content.
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?
Schema coverage is 100%, so the baseline is 3. The description adds a semantic distinction between passing 'query' versus only after/before to switch between search and list modes, which complements the schema descriptions. This helps the agent select the right combination of parameters for the user's intent.
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 opens with 'List or search calendar events,' clearly identifying the action and resource. It distinguishes this from siblings like create_event/update_event/delete_event by focusing on listing/searching, and from list_calendars by targeting events. The recurring-event detail also clarifies a distinct behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use listing vs searching: 'To list a period... pass only after/before and omit query.' This instructs the agent how to select parameters based on intent. It does not explicitly name alternative tools for other operations, but the context is clear enough; the absence of exclusions is why it isn't a 5.
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?
Since no annotations are provided, the description carries the full burden of behavioral transparency. It discloses important behaviors: openings reported at full length, not trimmed to duration; events not counted as busy (free, cancelled, declined), and all-day events not counted but listed separately. The only missing detail is the exact return format, but the description covers key edge cases.
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 well-structured and appropriately sized. It is front-loaded with the core purpose, then provides usage guidance, then behavioral details. Every sentence earns its place, covering purpose, usage, alternative, and behavioral nuances without redundancy or fluff.
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 parameter count of 8, no output schema, and no annotations, the description is quite comprehensive. It addresses key behavioral edge cases (full-length reporting, non-counted events, all-day events) that are not apparent from the schema. Minor gap: it does not explain the default time range or how openings are returned (e.g., start/end times), but the input schema covers defaults. Overall, it provides sufficient context for an agent to use the tool effectively.
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 schema already has 100% coverage for parameters, so the baseline is 3. The description adds value by explaining the semantics of the 'duration' parameter in relation to output behavior (full length not trimmed), which informs interpretation of the duration input. It also clarifies the treatment of all-day events, which relates to how parameters like includeWeekends and dayStart/dayEnd might interact. The description does not repeat parameter descriptions but adds contextual meaning.
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 tool finds open slots on the user's calendars, specifying the requirement of sufficient length. It distinguishes from search_events, which is about existing events, by noting the intended use for availability queries and pre-event planning. The verb 'find' is specific to the resource 'open slots' and the scope is user's calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use the tool: to answer 'when am I free for X' or to pick a time before calling create_event. It also gives an explicit alternative: 'To ask what is already scheduled, use search_events instead.' This is clear usage guidance with exclusions and alternative, matching the highest benchmark.
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?
The description discloses that only specified fields are changed, giving transparency about its mutation behavior. It does not explicitly mention potential side effects like sending invitation emails, but that is detailed in parameter descriptions; given no annotations, the description provides reasonable transparency.
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 concise, using two sentences to convey the core function and key usage instructions without unnecessary detail.
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?
The description covers the essential context: update existing, create for new, only specified fields, and recurring event handling. It does not discuss output or errors, but given the simple update operation and no output schema, it is sufficiently complete.
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 description adds value to the id parameter by clarifying that a recurrence ID targets a single occurrence while the master ID affects the whole series, enhancing understanding beyond the schema's basic description.
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 tool updates an existing calendar event, and distinguishes it from create_event for new events, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool (update) versus create_event, and explains how to handle recurring events by specifying occurrence vs master ID, covering the main usage scenarios.
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?
With no annotations provided, the description carries the full burden. It states the key behavioral nuance that only calendars holding events are returned, and reminder lists are excluded. It does not explicitly state it is read-only, but that is implicitly clear from the verb 'list.' A slightly stronger disclosure of side-effect-free behavior would warrant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every clause adds value. No redundant or filler wording.
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?
Despite having no output schema, the description explains the return values (IDs, names, colors) and the filtering behavior. It is complete for a simple list operation with no parameters.
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 the schema fully covers this aspect. The description adds no parameter-specific information, but none is needed. A baseline of 4 is given per instructions for zero-parameter tools.
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 tool's purpose: 'List the user's calendars.' It specifies the resource (calendars), the action (list), and the returned data (IDs, names, colors). It also distinguishes itself from sibling event-management tools by noting its role in finding a calendar to add events to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use it: 'Use this to find which calendar to add events to.' It also provides an exclusion—'Only calendars that hold events are listed; reminder lists are not part of this server's surface'—which helps avoid misuse.
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:

[![calendar-mcp MCP server](https://glama.ai/mcp/servers/duanefields/calendar-mcp/badges/card.svg)](https://glama.ai/mcp/servers/duanefields/calendar-mcp)

Score Badge

Copy to your README.md:

[![calendar-mcp MCP server](https://glama.ai/mcp/servers/duanefields/calendar-mcp/badges/score.svg)](https://glama.ai/mcp/servers/duanefields/calendar-mcp)

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/duanefields/calendar-mcp'

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