GDPR-compliant calendar access for AI assistants. Google, Microsoft 365, Apple & more. EU-hosted.
Creates 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.
All-day events: pass bare dates (start: "2026-09-01", end: "2026-09-03") or set all_day: true. For all-day the end date is INCLUSIVE — that example creates a three-day event covering 1–3 September. Both ends must use the same form.
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 — same form as `start`. For all-day events this date is INCLUSIVE (end 2026-09-03 means the event runs through 3 September). | |
| start | Yes | Start — either an ISO 8601 timestamp WITH timezone (2026-07-28T10:00:00+02:00 or …Z), or a bare date (2026-07-28) for an all-day event. A timestamp without a zone is rejected. | |
| title | Yes | Event title (required) | |
| all_day | No | Force an all-day event; time components in start/end are then discarded. Not needed when start/end are already bare dates. | |
| location | No | ||
| time_zone | No | IANA zone, e.g. America/New_York. For timed events it preserves the NAMED zone so the event follows daylight saving (without it the event is stored as UTC and shows as GMT in Apple Calendar, and a recurring series will not shift with the clocks). For all-day events it decides which local day is covered. Always send it when you know the user's zone; defaults to UTC. | |
| 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?
This description goes well beyond annotations by exposing live availability checking, non-blocking behavior for overlaps, the warning return, all-day end-date inclusivity, rejection of timestamp without timezone, and DST behavior via time_zone. These are exactly the non-obvious behaviors an agent needs to handle correctly.
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 long but every sentence carries operational value. Important edges are highlighted in bold and front-loaded, with practical examples and clear guidance, so the length is justified and easy to scan.
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?
For a tool with 8 parameters, an output schema, and several subtle interactions (all_day, time_zone, calendar_id, overlap warnings), the description covers all critical behavioral corners. The existing output schema handles return details, so no further description is needed.
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?
Although schema coverage is at 75%, the description adds meaningful semantics: it explains the date-string forms for all-day events, the inclusive end requirement, and the exact conditions for supplying calendar_id. It also provides a concrete example that clarifies how all-day dates are interpreted.
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 'Creates an event in one of the calendars this access may write to', naming a specific verb and resource. It clearly distinguishes creation from siblings like update_event, delete_event, and search_events by stating the action and its target.
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 explains when calendar_id is needed and references list_calendars for discover writable calendars, which gives concrete usage context. It does not explicitly mention when to prefer update_event or get_availability, but the creation intent and prerequisite awareness are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes 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.
Returns 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?
The description goes well beyond the readOnlyHint annotation by disclosing the direct-read mechanism, 60-second cache reuse and its freshness implications, inclusion of all-day/tentative events, exclusion of cancelled/free events, and the meaning of empty busy. It also explains how failed calendar reads surface in sources and warnings.
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 organized into labeled sections, each adding non-redundant value: result semantics, freshness behavior, busy definition, and completeness caveats. Despite being longer than average, nothing is wasted.
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 output schema covers return structure, so the description need not restate it. The description covers the behavioral caveats an agent must know to answer users correctly, including incomplete calendar reads and event freshness. No significant missing 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?
The input schema already describes both parameters with 100% coverage, including an ISO 8601 example. The description only adds 'given range' and doesn't add semantics like inclusivity or timezone handling, so a baseline 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 opens with a specific verb and resource: returns the user's busy times across all shared calendars in a given range. It clearly differentiates from siblings like list_calendars and search_events by focusing on busy/blocked time rather than calendar metadata or event lookup.
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 makes the scope explicit (shared calendars only, not necessarily all owned) and even tells the agent to relay limitations to the user. It does not explicitly state when to prefer this over a sibling tool, but the domain is distinct enough that 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.
Lists 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.
writable: true means this access may create events there. When more than one calendar is writable, create_event requires the calendar_id of one of them.
notice, when present, describes something the USER can change — either about this access or about their Kalender Sync setup. Pass it on rather than concluding the product cannot do what was asked. When it reads as an offer rather than an answer to what was asked, use your judgement about whether it fits the moment.
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 |
|---|---|---|
| notice | No | |
| calendars | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint and destructiveHint annotations. It details the semantics of 'readable: false' (events missing from get_availability, deliberately listed), 'writable: true' (create_event implications), 'notice' (user-changeable items, pass on), and 'sync_health' (does not affect availability reads). This is rich behavioral context that helps the agent interpret result fields correctly.
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 front-loaded with the main purpose, then systematically explains each returned field in its own paragraph. Every sentence adds operational value, and the use of inline code formatting makes field names easy to scan. Despite being longer than average, it is not verbose.
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 this is a simple list tool with no parameters and an output schema, the description fully covers the meaningful context: what the output fields mean, how they affect other tools, and how the agent should handle notice and sync_health. No significant gaps remain.
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 tool has zero parameters, and the input schema is empty, so schema coverage is effectively 100%. With no parameters to document, the baseline of 4 is appropriate; the description correctly focuses on output semantics rather than parameter syntax.
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 'Lists the calendars shared with this access, each with the detail level the user allowed,' which is a specific verb+resource statement. It clearly distinguishes the tool from siblings like get_availability and create_event by focusing on calendar metadata rather than events or mutations.
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 strong contextual guidance by explaining how readable/writable flags influence other tools (e.g., events missing from get_availability, create_event requiring calendar_id). However, it does not explicitly state when not to use this tool or name alternative tools, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds 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?
The description discloses many important behaviors—visibility filtering, free/busy limitations, defaults, exclusions, and a warning. However, it directly contradicts the openWorldHint=false annotation by stating 'No match is thus NOT proof that no such event exists,' which is an open-world claim. Per the contradiction rule, this dimension must be scored 1.
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 three short paragraphs, each with a distinct purpose: what the tool does, its visibility caveats, and its range/exclusion rules. It is front-loaded, dense, and contains no 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?
Given the output schema exists and the parameters are fully documented, the description covers the important behavioral context: visibility limits, warning behavior, default range, exclusions, and the no-match caveat. It loses one point because the openWorldHint annotation conflicts with the description, leaving the agent with inconsistent signals about whether absence of results is meaningful.
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 covers all three parameters, so the baseline is 3. The description adds meaningful extra constraints: the range is a single span of at most 92 days, lookback is bounded to one year, and the default window is last 7 days plus next 85. This goes beyond the schema without fully re-explaining the query parameter.
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 states a specific verb and resource: 'Finds events by text across the calendars shared with this access — case-insensitive substring match on title, location and description.' This clearly separates it from sibling tools like get_availability, list_calendars, create_event, delete_event, and update_event.
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?
It gives useful context by referencing get_availability for range and visibility semantics, and it explains limitations such as free/busy calendars not matching. However, it does not explicitly state 'use this tool when X' or 'instead of Y,' so guidance is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends 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.
Replies: for a bug report the team may send the user a single reply about it by default — set contact_ok to false if the user does not want that. For the other categories it is the reverse: no reply is sent unless the user asked for one, in which case set contact_ok to true. Never a newsletter signup either way.
| 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 | May the team send one reply about this feedback? Omit to use the default: yes for `bug`, no for the other categories. Set false if the user declined a reply, true if the user asked for one. |
| Name | Required | Description |
|---|---|---|
| received | Yes | |
| feedback_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations, such as the default reply behavior per category, the distinction between bug and other categories for contact_ok, and the rule about not including unsolicited calendar content. Since annotations only provide basic booleans (readOnlyHint: false, destructiveHint: false), the description adds substantial value.
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 with a clear first paragraph explaining purpose, a second paragraph with when-to-use rules, and a third paragraph explaining contact_ok behavior. Every sentence provides necessary guidance without redundancy. It is concise yet comprehensive.
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 (3 parameters, 1 enum, 100% schema coverage, and an output schema), the description adequately covers usage rules and behavioral details. The only minor gap is the lack of explicit mention of what the tool returns (output schema exists but no description of response). However, since an output schema is present, this is acceptable.
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?
Although schema description coverage is 100%, the description adds context beyond the schema by explaining the contact_ok default behavior based on category (bug vs others) and the nuance of when to set it to true or false. The description could slightly improve by explicitly linking category values to the feedback scenarios mentioned in the first paragraph, but overall adds meaningful guidance.
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 that this tool sends feedback from the user to the Kalender Sync team, and provides concrete examples of when it should be used (e.g., missing capabilities, broken features). This distinguishes it well from sibling tools like create_event or update_event which handle calendar operations.
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 explicitly states when to call the tool ('only when the user explicitly asked to send feedback'), when not to call it ('never send feedback on your own initiative'), and provides clear rules about including calendar content. It also gives nuanced guidance on the contact_ok parameter based on feedback category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates 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 — including whether it is all-day: an event created all-day becomes a timed event if this call passes timestamps, and vice versa.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | New end — same form as `start`; INCLUSIVE for all-day events. | |
| start | Yes | New start — ISO 8601 with timezone (…+02:00 or …Z), or a bare date (2026-07-28) for an all-day event. | |
| title | Yes | ||
| all_day | No | Force an all-day event; time components in start/end are discarded. | |
| event_id | Yes | Identifier from create_event | |
| location | No | ||
| time_zone | No | IANA zone, e.g. America/New_York. Preserves the named zone for timed events (so recurrences follow daylight saving) and decides the local day for all-day ones. Defaults to UTC. | |
| 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 declare readOnlyHint=false, destructiveHint=true, and openWorldHint=false, and the description agrees with all three — no contradiction. Beyond the annotations, it discloses two non-obvious behaviors: title/start/end specify the complete new state (replacement, not a partial patch), and the all-day/timed conversion (an all-day event becomes timed if timestamps are passed, and vice versa). Neither is inferable from the schema or annotations alone.
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 dense sentences with the most critical constraint (own-created events only) front-loaded. The second sentence partially restates the first ('created itself' vs 'created by anyone else are not addressable'), a minor redundancy, but every other clause earns its place and nothing is padding.
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?
An output schema is present, so return-value documentation is unnecessary. The description covers the closed-world scope, replacement semantics, and all-day conversion, while the schema covers ISO formats, all_day forcing, and time_zone behavior. The one noticeable gap is the fate of omitted optional fields (location, description, calendar_id, time_zone) on update — unclear whether they are preserved or cleared — but annotations and the output schema carry much of the remaining burden.
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 56% — start, end, all_day, event_id, and time_zone are well documented, while title, location, calendar_id, and description have no text. The description adds a valuable cross-parameter insight (the required trio constitutes the complete new state, and the start/end format drives all-day vs timed), but it does not compensate for the undocumented optional parameters. This lands at 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 uses a specific verb and resource ('Updates an event') and immediately narrows the scope: only events 'THIS access created itself (via event_id from create_event),' with events created by anyone else 'not addressable.' This clearly distinguishes it from siblings like search_events, get_availability, and create_event, so an agent can select it correctly without opening the schema.
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 states an explicit when-not: events created by anyone else are not addressable, preventing the agent from attempting updates on foreign events. It also ties event_id to create_event, which implies the creation prerequisite. However, it never names an alternative sibling for routing, so it stops just short of the full five.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
create_event1 field changedInput schema / properties / time_zone / descriptionPrevious value: -"IANA zone (e.g. Europe/Brussels) deciding which local day an all-day event covers. Defaults to UTC. Ignored for timed events, which carry their own offset."New value: +"IANA zone, e.g. America/New_York. For timed events it preserves the NAMED zone so the event follows daylight saving (without it the event is stored as UTC and shows as GMT in Apple Calendar, and a recurring series will not shift with the clocks). For all-day events it decides which local day is covered. Always send it when you know the user's zone; defaults to UTC."update_event1 field changedInput schema / properties / time_zone / descriptionPrevious value: -"IANA zone deciding which local day an all-day event covers. Defaults to UTC."New value: +"IANA zone, e.g. America/New_York. Preserves the named zone for timed events (so recurrences follow daylight saving) and decides the local day for all-day ones. Defaults to UTC."create_event4 fields changedInput schema / properties / all_dayAdded value: +{
+ "description": "Force an all-day event; time components in start/end are then discarded. Not needed when start/end are already bare dates.",
+ "type": "boolean"
+}Input schema / properties / end / descriptionPrevious value: -"End, ISO 8601 with timezone"New value: +"End — same form as `start`. For all-day events this date is INCLUSIVE (end 2026-09-03 means the event runs through 3 September)."Input schema / properties / start / descriptionPrevious value: -"Start, ISO 8601 WITH timezone — e.g. 2026-07-28T10:00:00+02:00 or …Z. Rejected without a zone."New value: +"Start — either an ISO 8601 timestamp WITH timezone (2026-07-28T10:00:00+02:00 or …Z), or a bare date (2026-07-28) for an all-day event. A timestamp without a zone is rejected."Input schema / properties / time_zoneAdded value: +{
+ "description": "IANA zone (e.g. Europe/Brussels) deciding which local day an all-day event covers. Defaults to UTC. Ignored for timed events, which carry their own offset.",
+ "type": "string"
+}update_event4 fields changedInput schema / properties / all_dayAdded value: +{
+ "description": "Force an all-day event; time components in start/end are discarded.",
+ "type": "boolean"
+}Input schema / properties / end / descriptionPrevious value: -"New end, ISO 8601 with timezone"New value: +"New end — same form as `start`; INCLUSIVE for all-day events."Input schema / properties / start / descriptionPrevious value: -"New start, ISO 8601 with timezone (e.g. …+02:00 or …Z)"New value: +"New start — ISO 8601 with timezone (…+02:00 or …Z), or a bare date (2026-07-28) for an all-day event."Input schema / properties / time_zoneAdded value: +{
+ "description": "IANA zone deciding which local day an all-day event covers. Defaults to UTC.",
+ "type": "string"
+}get_availability1 field changedOutput schema / properties / sources / items / properties / retryableAdded value: +{
+ "type": "boolean"
+}search_events1 field changedOutput schema / properties / sources / items / properties / retryableAdded value: +{
+ "type": "boolean"
+}send_feedback1 field changedInput schema / properties / contact_ok / descriptionPrevious value: -"true ONLY if the user explicitly agreed to one reply about this feedback."New value: +"May the team send one reply about this feedback? Omit to use the default: yes for `bug`, no for the other categories. Set false if the user declined a reply, true if the user asked for one."list_calendars1 field changedOutput schema / properties / noticeAdded value: +{
+ "type": "string"
+}list_calendars2 fields changedOutput schema / properties / calendars / items / properties / writableAdded value: +{
+ "type": "boolean"
+}Output schema / properties / calendars / items / requiredPrevious value: -[
- "id",
- "name",
- "provider",
- "visibility",
- "readable",
- "sync_health"
-]New value: +[
+ "id",
+ "name",
+ "provider",
+ "visibility",
+ "readable",
+ "writable",
+ "sync_health"
+]create_eventdelete_eventget_availabilitylist_calendarssearch_eventssend_feedbackupdate_eventClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
Scheduling infrastructure for AI agents across Google and Microsoft calendars.
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
Permissioned access to Gmail, Drive and Calendar via the user's own Google account
Add one secure layer between your agents and this server.
Each tool targets a distinct action or resource: create/update/delete events, availability lookup, calendar listing, text search, and feedback. Even closely related read tools like get_availability and search_events are clearly separated by their purpose and output.
All tool names follow a consistent verb_noun snake_case pattern: create_event, delete_event, get_availability, list_calendars, search_events, send_feedback, update_event. There are no mixed conventions or vague generic verbs.
Seven tools is well-scoped for a calendar integration server, covering the core calendar operations plus a feedback channel. Each tool has a clear purpose and none feel redundant or unnecessary.
The surface covers the main calendar lifecycle: create, update, delete, availability, listing, and search. Minor gaps exist such as no direct get_event-by-id operation and no invite/RSVP handling, but these are acknowledged limitations rather than severe dead ends.
