Skip to main content
Glama

Kalender Sync

by de.kalender-sync
OverviewDiscussionsAdmin

List calendars

list_calendars
Read-only

Lists the calendars shared with this access, each with the detail level the user allowed. This tool costs no credits and works even at zero balance. Credit warnings concern the other calendar tools, not this calendar list.

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.

sync_target: true means the user allowed setting up syncs into this calendar (create_sync) and pausing or resuming syncs that write into it.

notice, when present, explains an access limitation and how the user can resolve it. Mention it only when it is relevant to the requested action.

missing_calendars says what the user can do when a calendar they expect is not in this list. Pass it on when the user asks about a calendar that is not listed; calendars that are not shared with this access are deliberately not named.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noticeNo
warningsNo
calendarsYes
missing_calendarsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / missing_calendars
      Added value: +{
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "calendars"
-]New value: +[
+  "calendars",
+  "missing_calendars"
+]
  2. Changed2 schema fields changed
    • addedOutput schema / properties / calendars / items / properties / sync_target
      Added value: +{
+  "type": "boolean"
+}
    • changedOutput schema / properties / calendars / items / required
      Previous value: -[
-  "id",
-  "name",
-  "provider",
-  "visibility",
-  "readable",
-  "writable",
-  "manageable",
-  "sync_health"
-]New value: +[
+  "id",
+  "name",
+  "provider",
+  "visibility",
+  "readable",
+  "writable",
+  "manageable",
+  "sync_target",
+  "sync_health"
+]
  3. Changed1 schema field changed
    • addedOutput schema / properties / warnings
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  4. Changed2 schema fields changed
    • addedOutput schema / properties / calendars / items / properties / manageable
      Added value: +{
+  "type": "boolean"
+}
    • changedOutput schema / properties / calendars / items / required
      Previous value: -[
-  "id",
-  "name",
-  "provider",
-  "visibility",
-  "readable",
-  "writable",
-  "sync_health"
-]New value: +[
+  "id",
+  "name",
+  "provider",
+  "visibility",
+  "readable",
+  "writable",
+  "manageable",
+  "sync_health"
+]
  5. Changed1 schema field changed
    • addedOutput schema / properties / notice
      Added value: +{
+  "type": "string"
+}
  6. Changed2 schema fields changed
    • addedOutput schema / properties / calendars / items / properties / writable
      Added value: +{
+  "type": "boolean"
+}
    • changedOutput schema / properties / calendars / items / required
      Previous value: -[
-  "id",
-  "name",
-  "provider",
-  "visibility",
-  "readable",
-  "sync_health"
-]New value: +[
+  "id",
+  "name",
+  "provider",
+  "visibility",
+  "readable",
+  "writable",
+  "sync_health"
+]
  7. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only/non-destructive, but the description adds substantial behavior beyond them: zero credit cost, works at zero balance, that unreadable calendars remain listed deliberately and are excluded from `get_availability`, and that `sync_health` reflects Kalender Sync's own sync rather than provider availability. That last distinction is real operational nuance an agent could not infer.

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?

Front-loaded with the highest-value facts (what it lists, that it is free), then organized one paragraph per return field with consistent backticked field naming. Eight short paragraphs for a zero-param tool is on the long side, but each paragraph carries a distinct decision-relevant rule, so little is padding.

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?

With no parameters and an output schema already present, the description's job is interpretation and routing, both of which it covers: cost behavior, how each flag should influence downstream calls like `create_event` and `create_sync`, and how to relay `notice`/`missing_calendars` to the user. Nothing needed to call it correctly is missing.

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 takes zero parameters, so the baseline is 4. The description instead invests in defining the semantics of returned fields (`readable`, `writable`, `sync_target`, `notice`, `missing_calendars`, `sync_health`), which is useful interpretation guidance even though an output schema exists.

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?

States a specific verb and resource ('Lists the calendars shared with this access') and immediately bounds scope with 'each with the detail level the user allowed.' It also implicitly separates itself from the other calendar tools by noting 'Credit warnings concern the other calendar tools, not this calendar list.' An agent can identify the tool's role 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: this is the free, always-available calendar directory, and it explicitly says the credit warnings apply to sibling calendar tools instead. It tells the agent to pass on `missing_calendars` and to mention `notice` only when relevant. It stops short of an explicit 'use this when the user asks X' routing statement.

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

All Kalender Sync toolsInspect
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