GDPR-compliant calendar access for AI assistants - Google, Microsoft 365, Apple, GMX, WEB.DE, mailbox.org. Per-calendar visibility levels, event search, event creation from Basic. Existing events are not addressable by the AI — capability security by architecture. EU-hosted, audit log included.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 7 of 7 tools scored.
Each tool has a distinct purpose: creation, deletion, update, availability, calendar listing, search, and feedback are clearly separate actions. No overlapping or ambiguous tools.
All tool names follow the same verb_noun snake_case pattern (create_event, delete_event, get_availability, list_calendars, search_events, send_feedback, update_event), making the set predictable and easy to navigate.
Seven tools is a well-scoped number for a calendar sync server, covering the core operations without being bloated or too thin.
Covers event CRUD (with limitations), availability, calendar listing, and search. Missing a direct get_event and the ability to modify events not created by this access, but the search tool and feedback mechanism help work around these gaps.
create_eventCreate eventAInspectCreates an event in one of the calendars this access may write to.
Availability in the requested slot is checked LIVE (not from cache). An overlapping event does NOT prevent creation — the event is created regardless and the overlap comes back as a warning. Pass that warning on to the user instead of silently double-booking; whether the overlap is intended is the user's call.
calendar_id is only needed when several calendars are writable; with exactly one, that one is used. list_calendars shows the writable calendars. title is required.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End, ISO 8601 with timezone | |
| start | Yes | Start, ISO 8601 WITH timezone — e.g. 2026-07-28T10:00:00+02:00 or …Z. Rejected without a zone. | |
| title | Yes | Event title (required) | |
| location | No | ||
| calendar_id | No | Target calendar; only needed when several are writable | |
| description | No |
| Name | Required | Description |
|---|---|---|
| warning | No | |
| event_id | Yes | |
| calendar_id | Yes | |
| calendar_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations: availability is checked live, an overlapping event does not prevent creation and instead returns a warning, and the warning should be passed to the user to decide. It also clarifies that the access may write to specific calendars. This is valuable context not available 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in three paragraphs: purpose, booking behavior, and parameter guidance. Every sentence earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description correctly focuses on behavior and edge cases. It covers the live availability check, overlap behavior, warning handling, and calendar_id logic, making it complete for a create tool with these nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers required title, start, and end, and describes calendar_id. The description adds a useful behavioral rule for calendar_id: with exactly one writable calendar, that one is used, and points to list_calendars for discovering writable calendars. This adds meaning beyond the schema, though location and description are left self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Creates an event in one of the calendars this access may write to.' This clearly states the action and scope, and distinguishes it from sibling tools like delete_event, update_event, and search_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool and related helper usage: 'list_calendars shows the writable calendars' and 'calendar_id is only needed when several calendars are writable; with exactly one, that one is used.' It does not explicitly name alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_eventDelete eventADeletes an event that THIS access created itself (via event_id from create_event). Events created by anyone else are not addressable. The deletion is executed at the provider and propagates into any mirrored calendars through the normal sync.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Identifier from create_event | |
| calendar_id | No |
| Name | Required | Description |
|---|---|---|
| deleted | Yes | |
| event_id | Yes | |
| calendar_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description adds valuable behavioral context: the deletion is executed at the provider and propagates to mirrored calendars via sync, and only self-created events are addressable. This goes beyond the generic destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose, then add a constraint and a behavioral detail. Every sentence earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering destructive intent, the description covers the essential aspects: what is deleted, the self-created scope, and sync behavior. It does not mention error cases or the role of calendar_id, but the core usage is fully explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — event_id has a description ('Identifier from create_event'), but calendar_id is undocumented. The description reinforces the event_id semantics by linking it to create_event and self-created events, but provides no clarification for calendar_id, leaving a meaningful gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes an event') and specifies the exact resource scope (events that THIS access created itself). It distinguishes itself from sibling tools like update_event and create_event by emphasizing the self-created constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: only for events created by the same access via create_event. It also states an exclusion ('Events created by anyone else are not addressable'), but does not explicitly name alternative tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_availabilityGet availabilityAReturns the user's busy times in a given range, across all calendars shared with this access.
How the answer is produced: every shared calendar is read directly at the provider and the results are merged. There is no detour through a copy. as_of per calendar says when it was read — reads are reused for up to 60 seconds, so an event created moments ago may briefly be missing.
What busy contains: every event that blocks time — including all-day events and ones marked "tentative". NOT included are cancelled events and events explicitly marked "free" in the calendar. An empty busy therefore means "nothing blocks this time", not "no events exist".
Completeness: the answer covers exactly the calendars the user shared — not necessarily all calendars they own. If one of them could not be read, it appears with read: false in sources and additionally in warnings. These limitations belong in your answer to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End of the range, ISO 8601 | |
| from | Yes | Start of the range, ISO 8601 (e.g. 2026-07-21T00:00:00Z) |
| Name | Required | Description |
|---|---|---|
| busy | Yes | |
| range | Yes | |
| sources | Yes | |
| warnings | Yes | |
| range_clamped | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds substantial behavioral detail: reads are direct and cached for 60 seconds, all-day/tentative events block time, 'free' and cancelled events are excluded, and the meaning of an empty `busy` list is clarified. It also explains failure representation via `sources` and `warnings`. This is exceptional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is deliberately structured into distinct sections (answer production, `busy` semantics, completeness) and each sentence conveys essential information without redundancy. Though longer than average, it earns its length given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully equips an agent to invoke and interpret results: it explains the exact semantics of the output, caching behavior, scope limitations (only shared calendars), and edge cases. With an output schema present and no missing behavioral details, this is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters with ISO 8601 format descriptions. The description does not add any parameter-specific semantics beyond the schema, which is acceptable given the high schema coverage. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Returns the user's busy times in a given range, across all calendars shared with this access.' It clearly defines the tool's scope and implicitly distinguishes it from siblings like list_calendars (listing calendars) and search_events (searching events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the tool (checking availability across shared calendars) and includes important caveats about completeness and caching. However, it does not explicitly mention sibling tools as alternatives or state when NOT to use this tool, falling just short of the 'explicit exclusions' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_calendarsList calendarsALists the calendars shared with this access, each with the detail level the user allowed.
readable: false means this calendar cannot be read right now — its events are also missing from get_availability. Such calendars are deliberately listed rather than omitted.
sync_health describes Kalender Sync's OWN synchronisation of this calendar, if it takes part in one. It does not affect availability answers (those read the provider directly), but a broken sync is something the user can fix.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| calendars | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond readOnlyHint by explaining the semantics of 'readable: false' and 'sync_health', including the deliberate listing of unreadable calendars and the non-impact on availability answers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose statement followed by two concise, necessary explanations of output fields. Every sentence earns its place without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and zero parameters, the description covers purpose and field semantics thoroughly, making the tool's behavior fully understandable in its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input parameters exist, so the baseline is 4. The description correctly has nothing to add to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly: 'Lists the calendars shared with this access, each with the detail level the user allowed.' Specific verb+resource and scope, naturally distinct from siblings like get_availability and search_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage by noting that 'readable: false' calendars are missing from get_availability, hinting at when to prefer this tool over that sibling, but lacks explicit 'use when' or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eventsSearch eventsAFinds events by text across the calendars shared with this access — case-insensitive substring match on title, location and description.
The search only sees what this access may see: it filters the same visibility-rendered data get_availability returns. Calendars limited to free/busy expose no text and therefore can never match — when such calendars are part of this access, a warning says so. "No match" is thus NOT proof that no such event exists.
The range works like get_availability (single span of at most 92 days, lookback bounded to one year). Without from/to the search covers the last 7 days plus the next 85. Cancelled events and events explicitly marked "free" are not searchable.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of the range, ISO 8601. Default: 85 days ahead. | |
| from | No | Start of the range, ISO 8601. Default: 7 days ago. | |
| query | Yes | Text to look for (case-insensitive substring) |
| Name | Required | Description |
|---|---|---|
| range | Yes | |
| matches | Yes | |
| sources | Yes | |
| warnings | Yes | |
| truncated | Yes | |
| range_clamped | Yes | |
| unsearchable_calendars | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses visibility filtering, free/busy limitations, warning behavior, default range, and exclusion of cancelled/free events. This is rich contextual behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused paragraphs, each earning its place: core function, visibility/limitations, and range/defaults. Front-loaded with the primary purpose; no redundant or filler content given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described. The description covers all major operational aspects: scope, limitations, defaults, and exclusions, making it complete for an AI agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with descriptions, but the tool description adds meaningful context: defaults for from/to, case-insensitive substring semantics, and what types of events are excluded. This elevates beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Finds events by text across the calendars shared with this access' and details the subject (case-insensitive substring on title, location, description). It clearly distinguishes from siblings by aligning scope with get_availability and contrasting with list_calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly references get_availability for range and visibility behavior, and states when search will not work (free/busy calendars) and that 'No match' is not proof of absence. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_feedbackSend feedback to Kalender SyncAInspectSends feedback from the user to the Kalender Sync team — for example when the user wanted to do something these tools cannot do yet (editing an existing event, answering an invite, …), or when something looks broken.
Call this ONLY when the user explicitly asked to send feedback, or clearly agreed after you offered it. Never send feedback on your own initiative, and never include calendar content the user did not put into the message themselves.
Set contact_ok ONLY if the user explicitly agreed to receive a single reply about this feedback — ask them first. It is not a newsletter signup.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The user's feedback in their own words (what they wanted, what happened). | |
| category | Yes | missing_capability: the user wanted something the tools cannot do. bug: something misbehaved. other: everything else. | |
| contact_ok | No | true ONLY if the user explicitly agreed to one reply about this feedback. |
| Name | Required | Description |
|---|---|---|
| received | Yes | |
| feedback_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behavioral requirements: user consent is mandatory before sending, the feedback must be based on the user's own words, and contact_ok requires explicit user agreement for a follow-up reply. It also implies external communication (sending to a team), which is a significant side effect the annotations do not capture. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear first sentence stating the action, followed by contextual examples, then explicit usage constraints. Every sentence provides value—consent rules, content boundaries, and contact_ok clarification—without redundancy or fluff. It is appropriately sized for a tool with significant permission/consent implications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (sending external feedback, consent gating) and the presence of an output schema (so return value detail is not needed), the description fully covers the decision framework: when to invoke, what to include, consent handling, and the meaning of each parameter. There are no critical gaps that would leave an agent unsure about correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the three parameters with clear descriptions. The tool description adds extra semantic context by explaining that `contact_ok` is not a newsletter signup and requires explicit agreement, and that `message` should be the user's own words. This goes beyond the schema's descriptions, adding meaningful nuance, though the schema alone already covers the operational meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Sends feedback from the user to the Kalender Sync team.' It clarifies the tool's purpose with concrete examples (editing an event, answering an invite) and clearly differentiates it from the sibling query tools (get_availability, list_calendars, search_events) by framing it as a feedback/communication action rather than a calendar data operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Call this ONLY when the user explicitly asked to send feedback, or clearly agreed after you offered it.' It also states what not to do ('Never send feedback on your own initiative') and specific inclusion boundaries ('never include calendar content the user did not put into the message themselves'), giving concrete exclusions and agreement prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_eventUpdate eventAUpdates an event that THIS access created itself (via event_id from create_event). Events created by anyone else are not addressable. title, start and end describe the complete new state.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | New end, ISO 8601 with timezone | |
| start | Yes | New start, ISO 8601 with timezone (e.g. …+02:00 or …Z) | |
| title | Yes | ||
| event_id | Yes | Identifier from create_event | |
| location | No | ||
| calendar_id | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| updated | Yes | |
| event_id | Yes | |
| calendar_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnly=false, so the description is not required to repeat that. The description adds useful behavioral context: events created by others are not addressable, and 'title', 'start', 'end' describe the complete new state, implying replacement semantics. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose, and every clause adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavior and constraints, and the output schema plus annotations fill in return and safety details. However, it is ambiguous about how optional fields interact with the 'complete new state' statement, and there is no guidance on failure modes or permissions, leaving gaps for a tool with 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description must compensate. It nicely explains the three required state fields and the origin of event_id, but it does not address optional parameters like location, calendar_id, or description, leaving their semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and the resource (event), with a specific scope: only events created by this access. It distinguishes the tool from siblings like create_event and delete_event by adding the self-created constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (for updating events that this access created) and implies a restriction (not for events created by others). However, it does not explicitly name alternatives or exclusions, leaving some room for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!