Kalender Sync

Get availability

get_availability

Read-only

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 in the range, including all-day events and ones marked "tentative". Cancelled events are not included.

blocks_time per entry says whether it actually occupies the time. It is false for entries that do not make the user unavailable — holidays, birthdays, and (importantly) ALL all-day events from Apple/iCloud, which that provider always marks as free with no setting for the user to change. Such an entry is still a real appointment: an all-day "Baustelle Darmstadt" is a working day, not free time.

Use it accordingly: for "am I free / find me a slot", count only blocks_time: true. For "what do I have on", list everything and let the user judge. Never present a blocks_time: false entry as nonexistent.

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.

Check status first: credits_exhausted means this call was NOT performed. Only warnings and credit information are returned in that case; no result data or write confirmation. Tell the user how to restore credits; do not retry automatically.

Input Schema

TableJSON Schema

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)

Output Schema

TableJSON Schema

Name	Required	Description
`busy`	No
`range`	No
`status`	Yes	ok: tool executed; use its result fields. credits_exhausted: not executed; no result fields.
`sources`	No
`warnings`	No
`resets_at`	No
`range_clamped`	No
`credits_required`	No
`credits_available`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 11, 2026

addedOutput schema / properties / credits_available
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / credits_required
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / resets_at

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / status

Added value: +{
+  "description": "ok: tool executed; use its result fields. credits_exhausted: not executed; no result fields.",
+  "enum": [
+    "ok",
+    "credits_exhausted"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "range",
-  "range_clamped",
-  "busy",
-  "sources",
-  "warnings"
-]New value: +[
+  "status"
+]

Changed2 schema fields changedSep 11, 2026

addedOutput schema / properties / busy / items / properties / blocks_time
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / properties / busy / items / required

Previous value: -[
-  "start",
-  "end",
-  "is_all_day",
-  "calendar_id",
-  "calendar_name"
-]New value: +[
+  "start",
+  "end",
+  "is_all_day",
+  "blocks_time",
+  "calendar_id",
+  "calendar_name"
+]

Changed6 schema fields changedSep 10, 2026

addedOutput schema / properties / busy / items / properties / attendees

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "email": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "optional": {
+        "type": "boolean"
+      },
+      "organizer": {
+        "type": "boolean"
+      },
+      "self": {
+        "type": "boolean"
+      },
+      "status": {
+        "enum": [
+          "accepted",
+          "declined",
+          "tentative",
+          "needs_action"
+        ],
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / busy / items / properties / event_id
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / busy / items / properties / has_other_attendees
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / busy / items / properties / is_organizer
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / busy / items / properties / is_recurring
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / busy / items / properties / more_attendees
```
Added value: +{
+  "type": "number"
+}
```

Changed1 schema field changedAug 26, 2026
- addedOutput schema / properties / sources / items / properties / retryable
```
Added value: +{
+  "type": "boolean"
+}
```
First observedJul 31, 2026

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already covering the safety profile, the description adds substantial non-obvious behavior: direct reads merged with no cached copy, 60-second read reuse that can briefly hide new events, per-calendar as_of, exclusion of cancelled events, inclusion of tentative/all-day, partial-read handling via read: false in sources and warnings, and the credits_exhausted not-performed state. This is exactly the extra context annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence front-loads the purpose, then proceeds in clearly labeled sections by concern. It is long, but the length is largely earned by genuinely surprising semantics (blocks_time for Apple all-day events, credit exhaustion); a few clauses could still be tightened.

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 read-only, two-parameter tool with an output schema present, the description still covers the non-obvious output semantics an agent must interpret (busy, blocks_time, as_of, sources/read, warnings, status) and the failure mode. Nothing needed to call and correctly use it is missing.

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% (from/to both documented as ISO 8601), so the schema carries the parameter burden and a 3 is the baseline. The description adds range semantics (busy times within the range, all-day inclusivity) but no new syntax or constraints for the two inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource ('Returns the user's busy times...across all calendars shared with this access'), which is sufficient to distinguish it from the event-mutation siblings and from search_events. It stops short of explicitly naming an alternative tool, so sibling differentiation is implied by scope rather than stated.

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?

It gives concrete intent-based routing ('for am I free / find me a slot, count only blocks_time: true'; 'for what do I have on, list everything') and an explicit prohibition ('Never present a blocks_time: false entry as nonexistent'). It also prescribes behavior for credits_exhausted (do not retry automatically). It never names a sibling tool to use instead, so it falls short of the top band.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Kalender Sync tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?