kalendia-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources and actions, with clear descriptions. A few pairs overlap slightly (refresh_calendars vs. discover_calendars, get_billing vs. get_billing_overview), but the usage context is explained well enough to avoid major confusion.
Naming Consistency5/5
All tool names consistently follow a verb_noun pattern in lowercase snake_case (e.g., list_connections, create_event, delete_scheduling_page). The use of provider names in connect_ics/connect_icloud is a natural and predictable deviation.
Tool Count2/5
With 27 tools, the set exceeds the 25-tool threshold considered too many for most servers. While the domain is broad, several tools could be consolidated (e.g., billing tools, refresh/discover), making the count feel inflated rather than well-scoped.
Completeness3/5
The server provides solid coverage for connections, calendars, sync rules, events, and scheduling pages, with full CRUD for scheduling pages. However, sync rules lack an update endpoint, and event editing is limited to rescheduling (no metadata updates), which are notable gaps for a calendar service.
Average 4.5/5 across 27 of 27 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
The annotation readOnlyHint already establishes that this is a read-only operation. The description's use of 'List' reinforces that but adds no additional behavioral context, such as pagination, ordering, or what exactly constitutes a 'scheduling page'. No contradiction exists, but the description adds no transparency beyond the annotation.
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 a single, compact sentence that directly states the tool's function without any superfluous words. It is fully front-loaded and appropriately sized.
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 parameterless list operation, the description is complete. The existence of an output schema covers return value details, and the readOnly annotation covers safety. No further context is necessary to understand the tool's scope.
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 input schema has no parameters (0 params), so the baseline is 4. The description adds no parameter-specific detail, but none is needed since there are no parameters to define.
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 description uses a specific verb 'List' and clearly identifies the resource as 'the user's scheduling (booking) pages'. It is unambiguous and, while not explicitly comparing to siblings like get_scheduling_page or create_scheduling_page, the plural 'pages' implies a collection operation distinct from singular actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states what the tool does without mentioning scenarios, prerequisites, or trade-offs compared to sibling tools like get_scheduling_page or list_connections.
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?
The annotation readOnlyHint=true already communicates that this is a safe read operation, lowering the bar. The description adds the specific output fields (plan, tier, subscription_status, etc.), but does not disclose any further behavioral traits such as authentication requirements, caching, or latency implications.
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 a single, well-structured sentence that front-loads the core purpose and lists the returned fields without redundancy or filler.
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 simple zero-parameter read-only tool with an output schema and the readOnlyHint annotation, the description is quite complete. It lists the key return fields. The only gap is the lack of differentiation from the similarly named sibling 'get_billing_overview', which could cause confusion.
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, and the schema is trivially 100% covered. The description does not need to add parameter semantics; the baseline of 4 applies since there is nothing to document.
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 description clearly states a specific verb ('Get') and resource ('current plan and subscription status'), listing the exact fields returned. However, it does not distinguish itself from the sibling tool 'get_billing_overview', which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool versus alternatives like 'get_billing_overview' or any other billing/info-related tools. There are no exclusions or prerequisites.
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 adds behavioral context beyond the readOnlyHint annotation by noting that the tool returns the full config including availability_window. It also reveals that update_scheduling_page performs a full replace, which is critical for understanding how the fetched config will be used.
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 with no unnecessary words. It front-loads the action and then provides essential contextual guidance about the update workflow, making every sentence useful.
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 read-only tool with an output schema, the description covers the core purpose and usage relationship to update. It could mention error handling or prerequisites, but the simplicity of the tool and presence of the output schema make the current description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the page_id parameter beyond what the schema already provides (integer type). With 0% schema description coverage, the description should compensate but does not, leaving ambiguity about how to identify a scheduling page.
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 uses the specific verb 'Get' and names the resource as a single scheduling page's full config, including the availability_window. It clearly distinguishes this tool from sibling tools like list_scheduling_pages (which lists all pages) and update_scheduling_page (which modifies config).
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 explicitly advises to fetch before update_scheduling_page and explains why (update is a full replace), giving a clear when-to-use directive. It does not explicitly state when not to use it, but the instruction to fetch before update implies its role as a read-only prerequisite.
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?
The annotation readOnlyHint=true already declares this as a read-only operation, and the description adds the behavioral detail that it lists all rules without filtering. It doesn't disclose pagination or ordering, but with the annotation covering safety, the description provides adequate 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 two sentences, immediately starting with the action and resource. It efficiently clarifies what a sync rule is and what data is returned, leaving no redundant text.
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?
With no parameters, an output schema, and a read-only annotation, the description covers the essential information: the action, the resource, and the returned fields. It could mention potential limitations like pagination, but for a likely simple listing tool, this is adequate.
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 baseline is 4. The description correctly states it lists all rules and enumerates the return fields, which is sufficient given the absence of parameter requirements.
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 uses the specific verb 'List' with the resource 'sync (mirror) rules' and explains the rule's function. It clearly distinguishes from sibling tools like create_sync_rule and delete_sync_rule by focusing on listing. The returned fields are enumerated.
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 implies this tool is for viewing existing sync rules, but it doesn't explicitly state when to use it versus alternatives like run_sync_rule or delete_sync_rule. However, the context of sibling names and the 'list all' phrasing provides clear context for the listing use case.
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?
Annotations already indicate readOnlyHint=false, but description adds critical behavioral context: it performs a full reconcile that backfills the target, and returns counts of created/updated/deleted events and per-event errors. This explains side effects and return payload, which annotations don't provide.
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, front-loaded with the action and parenthetical detail, followed by return values. No redundant or filler content.
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 tool with a single parameter and a straightforward trigger action, the description covers purpose, mechanism, and return values. It also has an output schema and annotations, so return format is structurally defined. It lacks edge-case guidance (e.g., what happens if rule is already running), but overall is sufficient.
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 0% (no description for rule_id). The description does not explicitly describe rule_id but the tool name and action ('Run a sync rule') make it obvious that rule_id identifies which sync rule to run. Since there's only one self-explanatory parameter, the description adequately compensates.
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 function: 'Run a sync rule now (a full reconcile that backfills the target from the source).' It uses a specific verb ('run') and resource ('sync rule'), and the parenthetical clarifies the mechanism. This distinguishes it from sibling tools like create_sync_rule, delete_sync_rule, and list_sync_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies immediate execution ('Run a sync rule now') versus scheduled or other operations. However, it doesn't explicitly mention alternatives or when-not-to-use, such as 'use list_sync_rules to see rules' or 'only run when you need to force a refresh.' The context is clear but lacks explicit exclusions.
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 readOnlyHint annotation already declares this as a safe read operation. The description adds valuable behavioral context by specifying the exact fields returned (calendars, scheduling_pages) and the meaning of null limits (unlimited), which goes beyond the annotation.
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 a single, well-structured sentence that front-loads the core purpose and then provides precise details. Every word earns its place; there is no fluff or repetition.
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?
Given that there are no parameters and an output schema exists, the description is complete. It fully specifies what the tool returns and explains the 'null limit' convention, leaving no important gaps for the agent to infer.
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?
With zero parameters, the baseline is 4. The description adds meaning about the output structure and the semantics of limit values, which is helpful even though no parameters are involved.
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 function with a specific verb ('Get') and resource ('billing overview'), and elaborates on the exact content (plan, usage, limits). It distinguishes itself from siblings like get_billing by detailing the specific usage and limit fields returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose obvious, so when to use it is implied. However, it does not explicitly mention alternatives or exclusions, and there is a sibling tool named get_billing that could potentially overlap, but no guidance is provided to differentiate them.
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 the feed is fetched and parsed to validate it, adding a key behavioral trait beyond the annotations. It also clarifies read-only nature of the calendar and its inability to be a sync target. It does not detail error handling or state changes, but that is partially covered by the tool name and output schema.
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 three focused sentences with no redundancy. It front-loads the main action, then provides the URL format, validation behavior, and a key capability constraint, all earning their place.
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?
With one parameter, an output schema, and clear validation/source-target semantics, the description is largely complete. It could mention that a connection is created or that the feed must be publicly accessible without authentication, but these are mostly implied and not critical gaps.
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 provides only a parameter name with no description, and schema coverage is 0%. The description compensates by specifying that feed_url must be a public ICS feed URL using https or webcal .ics link, adding meaningful format and access constraints.
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 connects a calendar from a public ICS feed URL, with the specific verb 'connect' and resource 'read-only calendar'. It also distinguishes itself from siblings like connect_icloud by specifying the ICS/webcal format.
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 clear context for when to use this tool: for public ICS feed URLs, and explicitly notes the calendar is a sync source but not a target. It does not name alternative tools but implies the boundary well enough for selection.
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?
Annotations only indicate readOnlyHint=false and destructiveHint=false, which is minimal. The description adds meaningful behavioral context: source_calendar_ids are checked for conflicts, target_calendar_id is where confirmed bookings land, and video_provider values impose a dependency (zoom requires zoom_connection_id). This goes beyond annotations, although it doesn't cover error cases or idempotency.
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 a single well-structured paragraph that front-loads the purpose, then covers the parameters in a logical order. The embedded example for availability_window is concise and necessary, earning its place. No redundant words 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 tool's complexity (13 params, nested objects, dependencies) and the presence of an output schema, the description covers the most intricate and error-prone aspects (availability format, provider-specific requirements, calendar constraints). It leaves a few self-explanatory optional parameters undocumented, but the overall context is sufficient for correct invocation.
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?
With 0% schema description coverage, the description carries the full burden for parameter meaning. It explains the complex availability_window structure with an inline JSON example, clarifies slug uniqueness, and states the roles of source_calendar_ids and target_calendar_id, plus the video_provider enum. However, several simpler parameters (duration_minutes, buffers, horizon, webhook URL) rely on name inference, so it isn't a 5.
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 'Create a scheduling (booking) page,' a clear verb+resource statement that unambiguously distinguishes this from sibling tools like update_scheduling_page, delete_scheduling_page, and get_scheduling_page. The purpose is specific and immediately understandable.
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 implies usage by being the create counterpart to the update/delete/get siblings, and it provides key prerequisites ('target_calendar_id (must be writable and active)'). However, it does not explicitly state when to prefer this over alternatives or mention exclusions, so it stops short of 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds the critical context that the operation 'Cannot be undone.' This goes beyond the annotation by specifying irreversibility, a meaningful behavioral disclosure. No contradiction exists.
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 short sentences deliver both the purpose and a key safety warning with zero filler. Every word earns its place, and the critical information is front-loaded.
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 tool with a single parameter and an output schema, the description sufficiently covers purpose, irreversibility, and identifier provenance. It does not mention potential failure conditions or cascading effects, but given the tool's simplicity and annotations, this is adequate.
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 only defines page_id as an integer with no additional description. The description compensates by specifying its source ('from list_scheduling_pages'), which gives the agent actionable guidance on where to obtain a valid identifier. This adds value beyond the bare schema.
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 uses a specific verb ('Delete') and names the resource ('scheduling page'), making the action unambiguous. It also includes the only identifier needed, clearly distinguishing it from sibling tools like list_scheduling_pages, create_scheduling_page, or update_scheduling_page.
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 explicitly directs the agent to use 'page_id from list_scheduling_pages', which implies a prerequisite workflow and distinguishes this from other delete tools. It does not explicitly state when not to use it, but for a targeted delete operation, this is sufficient guidance.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read. The description adds meaningful behavioral context beyond this: the date window semantics (ISO-8601 UTC), the exact return shape, and that omitting the window yields the full horizon. It does not contradict annotations.
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 concise sentences. The first front-loads the core function and key parameters; the second gives return format and usage nuance. Every word earns its place with no repetition of schema or annotation 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?
The description covers the essential elements: purpose, parameter semantics, return format, and a key usage nuance. Given the tool's moderate complexity (3 params, output schema present), it is largely complete. It does not explicitly contrast with sibling tools or mention potential errors/pagination, but these are partially covered by the output schema and annotations.
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 description coverage is 0%, so the description carries the burden. It explains that 'slug' identifies the scheduling page and that 'from_iso/to_iso' form an optional ISO-8601 UTC window, with a note that omitting them means the full horizon. This compensates well for the lack of schema descriptions, though it could be slightly more explicit about individual parameter formatting edge cases.
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 a specific action ('Get bookable slots') on a specific resource ('scheduling page by its slug'), which distinguishes it from siblings like get_scheduling_page (which likely returns page config) and list_scheduling_pages (which lists pages).
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 conveys when to use the tool (to retrieve availability slots, optionally constrained by a date window) and how to use it ('Omit the window for the page's full horizon'). However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial context: permanent deletion of credentials, pausing of booking pages, removal of sync rules, best-effort OAuth revocation, irreversibility, and return value details. This goes well beyond the annotations.
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, front-loaded with the primary action, then logically details consequences and return value. Every sentence adds necessary information without repetition or filler.
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 single-parameter destructive action with an output schema, the description fully covers the behavioral context: side effects, irreversibility, OAuth revocation nuance, and return value. Nothing important is left unexplained.
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?
With zero schema description coverage, the description does not explicitly explain the single 'connection_id' parameter. However, the parameter name is self-explanatory, and the description's overall context makes clear it identifies the account to disconnect. This is adequate but not exceptional.
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 a specific verb and resource ('Disconnect a calendar account') and clearly enumerates the full scope of the action. It distinguishes itself from sibling tools by describing the cascade of effects on booking pages and sync rules.
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 implicitly defines when to use the tool by explaining the irreversible consequences and the affected linked resources. It does not explicitly name alternatives or state 'use this when...', but the context is unambiguous.
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 adds meaningful behavioral detail beyond the annotations: it discloses the auto-activation side effect and the plan's calendar limit. The annotations already indicate mutation potential, and the description aligns with that, showing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences earn their place: the first states the action and scope, and the second explains the important activation behavior and limit. No filler or repetition.
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?
The tool has a single parameter and an output schema, and the description covers purpose, input source, and side effects. It is complete enough for an agent to select and invoke the tool correctly.
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 only parameter, connection_id, is described as coming from list_connections, which adds meaning beyond the raw integer schema. Since schema coverage is 0%, the description compensates well for the single parameter.
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 starts with a specific action and resource: 'Re-discover the calendars under one connection.' It also adds scope (one connection, connection_id from list_connections) and a distinguishing behavioral detail (auto-activation), making it clear what the tool does and how it differs from simple listing tools.
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 provides clear context by instructing the caller to use connection_id from list_connections and explains the effect ('Newly visible calendars are auto-activated'). It does not explicitly name alternative tools or when not to use it, so it stops short of 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?
Annotations already declare readOnlyHint=true, and the description reinforces this with "Read events." It adds behavioral context beyond annotations by explaining that omitting from_iso/to_iso uses Kalendia's default window and that the return value is an events array. It doesn't mention edge cases like empty results or pagination, but for a read-only tool this is fairly transparent.
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: three sentences with clear line breaks. The main action is front-loaded, and every clause adds value—no filler or repetition of structural metadata.
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 simple read-only nature and the presence of an output schema, the description covers the essential context: parameter sources, default behavior, and return shape. It doesn't mention error handling or timezone details, but those are less critical for selection and invocation. It's complete enough for the agent to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter's origin (list_connections, list_calendars), format (ISO-8601 with example), and optionality (default window). This adds significant meaning beyond the bare schema fields.
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 a specific verb+resource+scope: "Read events from one calendar in a time window." This clearly distinguishes it from sibling tools like list_calendars (which lists calendars) or create_event (which writes), and the "one calendar" qualifier sets it apart from list_all_calendars.
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 guidance on parameter sourcing: connection_id comes from list_connections, and calendar_id is a provider_calendar_id from list_calendars. It also explains optional parameter behavior (omit for default window). However, it doesn't explicitly name alternatives or state when not to use this tool, so it falls short of 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?
The readOnlyHint annotation already signals a safe read operation, and the description adds the return format and the flat-list nature, which is useful behavioral context. There is no contradiction, and the description provides value beyond the annotation without being verbose.
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 a single, well-structured sentence that front-loads the core action and scope, followed by a brief list of output fields and a usage note. No wasted words.
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?
Given that an output schema exists and the description already lists the fields, the tool is fully specified. It also covers the primary use case for the returned data, making it complete for a parameter-free read-only list tool.
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 provides no meaningful information. Per the baseline for 0-parameter tools, the description does not need to compensate. The description focuses on output semantics, which 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 lists every calendar across all connected accounts, with a specific verb ('List') and resource. It also enumerates the exact fields returned, distinguishing it from sibling tools like list_calendars by emphasizing the cross-account scope.
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 concrete guidance on when to use the resulting calendar id (as a sync-rule source/target or for a scheduling page). It does not explicitly contrast with list_calendars, but the 'across all connected accounts' phrasing implies the appropriate context for this tool.
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?
Annotations already declare readOnlyHint=true. The description adds behavioral context by mentioning the fresh fetch from the provider and the absence of Kalendia calendar id, which is useful beyond the annotation.
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 focused sentences front-load the core purpose and then add essential output/alternative guidance without unnecessary detail.
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?
Given the output schema is present and readOnlyHint is annotated, the description is complete for usage: it explains key fields, how to use them in get_agenda, and when to choose the sibling tool list_all_calendars.
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?
With one parameter (connection_id) and 0% schema coverage, the description adds some context via 'under one connection' but does not explain where the connection id comes from or validate any constraints beyond the schema.
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 lists live provider calendars under one connection, with specific output fields. It distinguishes from list_all_calendars by noting this is the provider view with no Kalendia calendar id.
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 instructs to use provider_calendar_id as calendar_id in get_agenda and directs users to list_all_calendars when they need the numeric Kalendia calendar id for sync rules and scheduling pages, making the alternative clear.
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 readOnlyHint annotation already signals a safe read operation, and the description consistently describes a listing action. It adds useful behavioral context by specifying the exact fields returned per item and noting the 'id' is meant for use with list_calendars, which helps the agent understand the output shape.
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 long, front-loads the action, and every sentence adds value—the first defines the scope, the second details the output schema and next-step usage. No wasted words.
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 zero-parameter read-only list tool with an output schema, the description fully covers the purpose, output fields, and how to chain the result to another tool. It is complete given the low complexity and available annotations.
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 description has nothing to add about parameter meanings. This is the baseline for a parameterless tool, and the description compensates by explaining the output rather than parameter details.
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 lists the user's connected calendar accounts, enumerating specific providers (Google, Microsoft, iCloud, ICS, Zoom). It distinguishes itself from sibling tools like list_calendars by focusing on connection-level metadata rather than calendar-level data.
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 provides clear usage context by stating the returned items and explicitly instructing to use the 'id' with list_calendars. It does not explicitly contrast with alternatives like list_all_calendars, but the purpose is clear enough for an agent to select it appropriately.
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 adds behavioral context beyond the annotations, specifically the non-fatal error handling ('connection whose provider errors is skipped'). This is useful for an operation that might have partial failures. The annotations do not contradict the description.
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, front-loaded with the primary action, and the second sentence adds essential error-handling detail. No unnecessary words.
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 simple no-parameter refresh tool, the description adequately explains the purpose, scope, and failure handling. An output schema exists, so returning details are covered. No gaps apparent.
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 description doesn't need to explain parameter meaning. The baseline for 0 params is 4, and the description still conveys what the no-arg call does.
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 re-discovers calendars across all connected accounts, using a specific verb ('re-discover') and resource ('calendars') with explicit scope ('ALL connected accounts'). This distinguishes it from siblings like list_calendars and discover_calendars by emphasizing the global, updated scan.
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 implies when to use the tool: to pick up calendars created since account connection. It also clarifies that a connection with errors is skipped, providing a clear context. However, it doesn't explicitly name alternatives or state when not to use it, which prevents 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?
Annotations already indicate a non-read-only, non-destructive operation. The description adds valuable behavioral context by explaining that passing null or an empty string clears the override and falls back to the provider's name. This is not obvious from annotations or schema and enhances transparency without contradiction.
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 concise sentences with no filler. The first sentence states the core purpose, and the second covers an important edge case. Information is front-loaded and every word earns its place.
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?
Given the tool's simplicity, the description covers all necessary aspects: purpose, parameter source, and override behavior. The output schema exists, so return value details are unnecessary. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for parameters, but the description compensates fully by explaining that calendar_id is sourced from list_calendars and that custom_name uses null/empty to clear the override. This adds crucial meaning beyond the raw type definitions, making parameter usage clear.
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 uses a specific verb ('Set') and resource ('display name for a calendar'), making the tool's function unambiguous. It is clearly distinct from sibling tools like list_calendars or create_event, as it focuses on renaming. The inclusion of the clearing behavior adds precision.
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: calendar_id must come from list_calendars, and null/empty clears the override. This guides correct usage. However, it does not explicitly mention alternatives or scenarios where this tool should not be used, so it falls short of full explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the app-specific password requirement, validation before saving, and the return value, adding important context beyond the minimal annotations. This helps the agent set user expectations and understand preconditions.
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?
Three concise sentences, each adding essential information: the action, the password requirement, validation, and return value. No wasted words.
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 two-parameter connection tool with an output schema, the description covers all necessary behavioral aspects: what it does, required credentials, validation, and return. It is fully sufficient for an agent to invoke it correctly.
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?
With 0% schema coverage, the description explains the app_specific_password parameter in detail and implies the meaning of apple_id. It partially compensates for the missing parameter descriptions, though it could be more explicit about apple_id.
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 uses a specific verb ('Connect') and explicitly identifies the resource ('Apple iCloud calendar'), clearly distinguishing it from sibling tools like connect_ics and list_connections.
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 clearly states the tool's purpose, implying when to use it (for iCloud calendars). It does not explicitly contrast with alternatives like connect_ics, but the context is unambiguous enough for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses important side effects and behaviors: notify=True emails attendees an invitation, add_conference=True attaches a native video link, naive datetimes are interpreted as UTC, and the return shape is {event: {...}}. This gives the agent a clear understanding of what to expect, including potential external effects.
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 a single compact paragraph that front-loads the core purpose and then packs essential parameter guidance, a practical example, side-effect warnings, and the return value into a coherent structure. It is appropriately sized for the tool's complexity and contains no wasted words.
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?
Given the tool has 11 parameters, no schema descriptions, and an output schema, the description covers prerequisites (ID sourcing), input format (ISO-8601), constraints (writable, sync-rule exclusion), side effects (notify, conference), and return. This is complete enough for an agent to invoke the tool correctly without additional external documentation.
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?
With schema description coverage at 0%, the description compensates well for the most critical parameters: connection_id (source), calendar_id (writable calendar's provider_calendar_id), start_iso/end_iso (ISO-8601 format with UTC handling), attendees (list of emails), notify (default true), and add_conference (native video link). However, it leaves some parameters like all_day, location, and description undefined, which, while partially inferable, could use more clarity.
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 the direct, specific statement 'Create a calendar event,' which clearly identifies the verb and resource. It distinguishes itself from sibling tools like cancel_event and reschedule_event by focusing solely on creation, and it reinforces the purpose by explaining how to obtain the required IDs from list_connections and list_calendars.
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 for when to use the tool: it requires a writable calendar, explicitly states that the target 'must NOT be the target of a sync rule,' and tells the user where to get connection_id and calendar_id. However, it does not explicitly mention alternative tools for related operations (e.g., reschedule_event for modifying an existing event), so it stops short of a full when/when-not/alternatives breakdown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true and readOnlyHint: false. The description adds meaningful beyond-annotation context: mirrored events are cleaned up afterward by Kalendia, and the operation is irreversible. These details are not present in the structured hints and help the agent understand side effects.
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 with no wasted words. The first sentence states the action, the second highlights consequences. Every clause adds value, and the sentence ordering front-loads the primary purpose.
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 deletion tool with an output schema available, the description covers the essential aspects: the action, the source of the ID, the cleanup side effect, and irreversibility. No critical information is missing for successful invocation.
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 only provides an integer rule_id with no description. The description compensates by linking rule_id to list_sync_rules, giving it semantic meaning and source. While it does not elaborate on constraints or format, this is a significant addition given 0% schema coverage.
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 'Delete a sync rule,' a specific verb and resource. It also adds a distinguishing scope ('sync rule') and a key behavioral note about mirrored events being cleaned up, which clearly differentiates this from sibling deletion tools like delete_scheduling_page.
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 explicitly states 'rule_id from list_sync_rules,' telling the agent where to obtain the required identifier. It also warns that the operation 'cannot be undone,' providing important caution. However, it does not explicitly mention alternatives or when not to use this tool, though the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds useful behavioral details: ordering (most recent first), exact fields returned, and the clamping range (1..500). These specifics help the agent predict output and limits without contradicting the annotation.
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 extremely concise: two sentences, no fluff. It front-loads the core purpose and then adds essential details about fields and constraints. Every sentence contributes value.
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?
Given the tool's simplicity (one optional parameter, output schema present, readOnly annotation), the description covers all necessary aspects: what it does, ordering, return fields, and the limit behavior. There are no obvious gaps for an agent to invoke it correctly.
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 only defines 'limit' as an integer with a default, but the description adds crucial semantic meaning by stating it is clamped to 1..500. This compensates for the lack of schema-level descriptions and clarifies acceptable values.
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 retrieves audit-log entries with a specific verb ('Get'), resource ('account audit-log entries'), and ordering ('most recent first'). It also enumerates the returned fields, making it distinct from sibling tools that handle calendars, sync rules, or scheduling.
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 implies the tool is for viewing recent account audit activity, which is a distinct context among the sibling tools. It doesn't explicitly state when not to use it, but there are no overlapping alternatives for audit logs, so the context is clear enough without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already indicate this is a write operation, the description adds critical behavior: omitted optional fields reset to defaults, and setting is_active=False pauses the page. This goes well beyond the annotations and explains the exact consequences of the full-replace update.
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?
Three tightly worded sentences deliver the full-replace rule, the required workflow, and a key behavioral toggle without filler. Every sentence earns its place.
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?
Given the tool's complexity (15 params, nested objects, output schema), the description covers the most crucial operational context: the full-replace semantics, the get-before-update pattern, and default-reset behavior. Output schema exists, so return value details are not needed here. References to create_scheduling_page for field meanings are reasonable.
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 0%, so the description must compensate. It adds key semantic meaning for parameter handling: all fields must be passed, omitted optionals reset, and is_active controls page pause. However, individual field meanings are deferred to create_scheduling_page rather than explained inline, leaving some burden on the agent.
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 a scheduling page and immediately distinguishes it from creation by emphasizing the full-replace semantics. It also names the companion tool get_scheduling_page, reinforcing its role relative to siblings like create_scheduling_page.
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 provides explicit workflow guidance: call get_scheduling_page first, modify desired fields, and pass every field back to avoid resets. It does not explicitly contrast with create_scheduling_page, but the full-replace instruction implies the correct usage context and avoids common pitfalls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it destructive, but the description adds valuable context: 'Cannot be undone', 'notify=True sends a cancellation to attendees', and provider-specific differences (iCloud treats already-deleted as success vs error on Google/Microsoft). This goes well beyond the annotation hints.
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?
Three concise sentences: action+consequence, parameter sourcing, and behavior variants. Each sentence earns its place with no redundancy or filler.
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?
The description covers irreversibility, parameter sources, side effects (notify), and cross-provider error handling. Combined with the output schema, this is complete for a destructive cancellation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema_description_coverage, the description compensates fully by explaining where each ID comes from (list_connections, list_calendars, get_agenda) and what notify does. All four parameters (connection_id, calendar_id, event_id, notify) receive meaningful semantics.
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 states 'Cancel (delete) one event' with a specific verb and resource, clearly distinguishing it from sibling tools like create_event and reschedule_event. The added 'Cannot be undone' reinforces the destructive nature.
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 explains how to obtain required parameters (connection_id, calendar_id, event_id) from other tools, which is clear usage context. It doesn't explicitly state when not to use it, but no alternative cancellation tool exists, so the lack of exclusions is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it states that the target must be writable, clarifies the visibility_mode enum values and default, explains mirror_prefix with an example, and explicitly notes that 'Mirrors the source's current events into the target on creation.' This anticipates side effects and parameter consequences.
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 front-loaded. The first sentence states the core purpose, followed by prerequisites and parameter semantics in a logical order. Every sentence adds necessary information; there is no redundancy or fluff.
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?
Given the five parameters, zero schema descriptions, and the presence of an output schema, the description is fully complete. It covers purpose, parameter semantics, prerequisites, and immediate behavior on creation. No essential information is missing for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully compensate. It does: source_calendar_id and target_calendar_id are sourced from list_calendars, visibility_mode enumerates its three options with meaning and default, mirror_prefix is exemplified, and enabled is explained with the paused option. Every parameter is semantically covered.
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 a specific verb and resource: 'Create a sync rule that mirrors events from source_calendar_id onto target_calendar_id.' This clearly states what the tool does and distinguishes it from siblings like delete_sync_rule and run_sync_rule.
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 provides clear usage context: calendar IDs come from list_calendars and the target must be writable. It also explains parameter options and how to create the rule paused. However, it does not explicitly contrast with alternatives like run_sync_rule or list_sync_rules, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare mutating and non-destructive, but the description adds rich behavior: it preserves title/attendees/location/video link, defaults notify=True which emails attendees, and explains how recurring occurrences are handled. This goes well beyond the annotations.
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 packs all necessary information into a tight paragraph. It is front-loaded with the purpose, then parameter sourcing, special cases, format, preservation, notification, and return. Every sentence adds value, with no fluff.
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 tool with 6 parameters, a recurring-meeting edge case, and notification side effects, the description is complete. It even notes the return format, despite having an output schema. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explains every parameter: where to get connection_id, calendar_id, event_id (including provider_event_id), format for start_iso/end_iso, and the notify default and effect. This is exemplary compensation for a bare schema.
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 a specific verb and resource: 'Reschedule one event to a new time window' and frames it as the 'core move this call' action. It also distinguishes itself from siblings by stating 'Only the time changes' and preserving other fields, making it clear this is not create/cancel.
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 explicit context on when to use: it tells where to source parameters (connection_id from list_connections, etc.) and handles recurring meetings. It implies when-not by stating only time changes, but does not explicitly name alternative tools for other modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits beyond the annotations: it replaces the full active set (not a merge), and it rejects empty lists to prevent accidental account disconnection. With annotations only stating readOnlyHint=false and destructiveHint=false, this added context is essential and goes well beyond what annotations convey.
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 concise sentences that front-load the core action, then add essential caveats. No filler or redundant phrasing.
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?
The description covers purpose, behavior, parameter constraints, and the appropriate alternative for a boundary case. Since an output schema exists, omitting return-value details is appropriate. This is as complete as needed for a tool with two simple 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?
Schema coverage is 0%, so the description must compensate. It indirectly clarifies active_calendar_ids by explicitly stating the empty-list rejection (meaning at least one ID is required). It does not restate parameter names, but the operation context makes connection_id and the list of calendar IDs understandable. A slightly more explicit name would earn a 5.
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 operation: setting which calendars under a connection are active for syncing and use in rules/pages. It names the specific resource (calendars under a connection) and differentiates itself from the related disconnect_connection tool.
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 provides an alternative for the empty-list case, telling users to use disconnect_connection instead. This clear exclusion and pointer to a sibling tool makes the usage context unambiguous.
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:

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

Score Badge

Copy to your README.md:

[![kalendia-mcp MCP server](https://glama.ai/mcp/servers/bradbogdan/kalendia-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bradbogdan/kalendia-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/bradbogdan/kalendia-mcp'

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