A
licenseNot graded
qualityF
maintenanceProvider-agnostic CalDAV calendar MCP server that connects any CalDAV calendar to AI assistants, enabling calendar operations like listing, creating, updating, and deleting events.
AGPL 3.0
Chronos MCP
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Chronos MCPCreate a task 'Review documentation' due next Friday."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Chronos MCP - Advanced CalDAV Management Server
A comprehensive Model Context Protocol (MCP) server for CalDAV calendar management, built with FastMCP 2.0. Chronos provides advanced calendar and event management capabilities with multi-account support.
🚀 Features
Multi-account Support: Manage multiple CalDAV servers simultaneously
Full CRUD Operations: Create, read, update, and delete calendars and events ✅
Advanced Event Management:
Recurring events with RRULE support ✅
Event updates with partial field modifications ✅
Attendee management and invitations (JSON format) ✅
Reminders and alarms (VALARM) ✅
Timezone-aware operations
Advanced Search:
Full-text search across events ✅
Field-specific search (title, description, location) ✅
Multiple match types (contains, starts_with, exact, regex) ✅
Date range filtering ✅
Relevance ranking algorithm ✅
Bulk Operations:
Create multiple events in parallel ✅
Delete multiple events efficiently ✅
Atomic operations with rollback ✅
Configurable error handling modes ✅
Security Hardening:
Comprehensive input validation ✅
XSS and injection prevention ✅
Path traversal protection ✅
RFC-compliant validation ✅
Task Management: Full VTODO support ✅
Journal Entries: Full VJOURNAL support ✅
Related MCP server: ical-mcp
📋 Task Management (VTODO)
Chronos MCP provides comprehensive support for CalDAV tasks:
Create tasks with due dates, priorities, and descriptions
Track progress with percentage completion (0-100%)
Manage status: NEEDS-ACTION, IN-PROCESS, COMPLETED, CANCELLED
Create subtasks using related_to relationships
Bulk operations for efficient task management
Available tools:
create_task— Create a task with summary, due date, priority, descriptionlist_tasks— List tasks in a calendar, optionally filtering by statusupdate_task— Partial update of task fields (status, priority, progress, etc.)delete_task— Delete a task by UIDbulk_create_tasks— Create multiple tasks in parallelbulk_delete_tasks— Delete multiple tasks in parallel
# Example: Create a task
mcp call create_task '{
"calendar_uid": "my-calendar",
"summary": "Complete project documentation",
"due": "2025-02-01T15:00:00Z",
"priority": 2
}'📓 Journal Entries (VJOURNAL)
Keep detailed records with CalDAV journal entries:
Create journal entries with timestamps and rich descriptions
Link related entries using related_to relationships
Organize with categories for better searchability
Update and manage existing journal entries
Available tools:
create_journal— Create a journal entry with summary and descriptionlist_journals— List journal entries in a calendarupdate_journal— Partial update of journal fieldsdelete_journal— Delete a journal entry by UIDbulk_create_journals— Create multiple journal entries in parallelbulk_delete_journals— Delete multiple journal entries in parallel
# Example: Create a journal entry
mcp call create_journal '{
"calendar_uid": "my-calendar",
"summary": "Team Meeting Notes",
"description": "Discussed Q1 objectives..."
}'For detailed usage, see VTODO/VJOURNAL Guide.
🔐 Security
Secure Password Storage (New!)
Chronos MCP now supports secure password storage using your system's keyring (via python-keyring). When available, passwords are automatically stored in:
macOS: Keychain Access
Windows: Windows Credential Locker
Linux: Secret Service (GNOME Keyring, KWallet, etc.)
Migration to Secure Storage
If you have existing accounts with passwords stored in plain text, migrate them to secure storage:
# Check what will be migrated (dry run)
python scripts/migrate_to_keyring.py --dry-run
# Perform actual migration
python scripts/migrate_to_keyring.pyThe migration script will:
Read existing passwords from
~/.chronos/accounts.jsonStore them securely in your system keyring
Create a backup of the original configuration
Remove passwords from the JSON file
Fallback Behavior
If keyring is not available (e.g., SSH sessions, containers), Chronos MCP will:
Warn about the security implications
Fall back to storing passwords in the configuration file
Automatically attempt to migrate passwords to keyring when it becomes available
Legacy Security Warning
Note: If keyring is not installed or available, passwords will be stored in plain text at ~/.chronos/accounts.json. Install keyring support with:
pip install "chronos-mcp[secure]" # or just: pip install keyringInstallation
Standard Installation
pip install -e .Secure Installation (Recommended)
Includes keyring support for secure password storage:
pip install -e ".[secure]"Or if you already have Chronos installed:
pip install keyring>=24.0.0Configuration
Environment Variables (Default Account)
CALDAV_BASE_URL=http://<YOUR_CALDAV_SERVER>:5232
CALDAV_USERNAME=<YOUR_USERNAME>
CALDAV_PASSWORD=<YOUR_PASSWORD>Multi-Account Configuration
Create ~/.chronos/accounts.json:
{
"accounts": {
"personal": {
"url": "http://<YOUR_CALDAV_SERVER>:5232",
"username": "<YOUR_USERNAME>",
"display_name": "Personal Calendar"
},
"work": {
"url": "https://caldav.company.com",
"username": "user",
"display_name": "Work Calendar"
}
},
"default_account": "personal"
}Note: Passwords are not included in the JSON when using keyring. They will be:
Prompted for on first use and stored securely
Migrated from existing configuration using
scripts/migrate_to_keyring.pyOnly stored in JSON if keyring is unavailable (with a warning)
Usage
Running the Server
./run_chronos.shBasic Operations
List all configured accounts:
list_accounts()Example Tool Usage
Create an event with reminder:
chronos:create_event(
calendar_uid="assistant",
summary="Team Meeting",
start="2025-07-08T14:00:00",
end="2025-07-08T15:00:00",
location="Conference Room",
alarm_minutes="15" # Note: Pass as string!
)Create recurring event with attendees:
chronos:create_event(
calendar_uid="work",
summary="Weekly Standup",
start="2025-07-07T09:00:00",
end="2025-07-07T09:30:00",
recurrence_rule="FREQ=WEEKLY;BYDAY=MO,WE,FR",
attendees_json='[{"email": "team@example.com", "name": "Team"}]'
)Delete an event:
chronos:delete_event(
calendar_uid="assistant",
event_uid="abc-123-def-456"
)Update an event (partial update):
chronos:update_event(
calendar_uid="assistant",
event_uid="abc-123-def-456",
location="Room 202", # Update location
alarm_minutes="30" # Change reminder to 30 minutes
# Other fields remain unchanged
)Documentation
Usage - Basic tool usage examples
Architecture Guide - System design and components
RRULE Guide - Recurring events documentation
VTODO/VJOURNAL Guide - Task and journal management
Architecture Decisions - ADR records
Contributing - Development guidelines
Security Policy - Security reporting and practices
Known Issues
See GitHub Issues for current limitations and workarounds.
Changelog
See CHANGELOG.md for version history.
Contributing
See CONTRIBUTING.md for development guidelines.
Available Tools
27 toolsadd_accountA
Add a new CalDAV account to Chronos
By default, this function blocks URLs pointing to localhost and private IP addresses for security (SSRF protection). For local development or testing, set allow_local=True to explicitly allow these addresses.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | CalDAV server URL | |
| alias | Yes | Unique alias for the account | |
| password | Yes | Password for authentication | |
| username | Yes | Username for authentication | |
| request_id | No | ||
| allow_local | No | Allow localhost/private IPs (WARNING: only for development/testing) | |
| display_name | No | Display name for the account |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It effectively communicates the SSRF protection blocking localhost/private IPs by default and the availability of allow_local to bypass it for testing. This is important safety behavior.
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, using two sentences to convey the core action and a critical behavioral detail. It is front-loaded with the primary purpose, making it easy to parse quickly.
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 (7 parameters) and that an output schema exists (so return values need not be described), the description adequately covers the main aspects: purpose, key parameters, and security context. Minor gaps remain (e.g., no mention of validation or duplicate handling), but overall it 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 description coverage is high (86%), but the description adds value beyond the schema by explaining the security implications of the url parameter and the purpose of allow_local. This contextual information aids correct parameter selection.
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 adds a CalDAV account, specifying the action ('Add'), resource ('new CalDAV account'), and system ('Chronos'). This distinguishes it from sibling tools like list_accounts, remove_account, and test_account.
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?
While not explicitly stating when to use vs alternatives, the description provides context on SSRF protection and the allow_local parameter for development/testing. This implies typical usage scenarios but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_create_eventsB
Create multiple events in bulk
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Operation mode: continue, fail_fast | continue |
| events | Yes | List of event data dictionaries | |
| account | No | Account alias | |
| calendar_uid | Yes | Calendar UID | |
| validate_before_execute | No | Validate events before creation |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states the basic action, omitting side effects, error handling, atomicity, rate limits, or what 'bulk' implies operationally. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, but it is too brief for the tool's complexity (5 parameters, output schema). Conciseness is achieved at the expense of necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description should explain bulk behavior, error modes, validation, and limits. It only states the basic function, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; parameters like 'mode' and 'validate_before_execute' are documented only in 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 'Create multiple events in bulk' clearly states the verb (create), resource (events), and scope (multiple/bulk). It effectively distinguishes from singleton 'create_event' and sibling bulk operations like 'bulk_delete_events'.
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 guidance on when to use this tool versus alternatives like 'create_event' or other bulk tools. No prerequisites, exclusions, or contextual advice provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_create_journalsC
Create multiple journal entries in bulk
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Operation mode | continue |
| account | No | Account alias | |
| parallel | No | Execute operations in parallel | |
| request_id | No | ||
| calendar_uid | Yes | Calendar UID | |
| journals_json | Yes | JSON array of journal data |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It provides no insight into error handling, partial failures, idempotency, or permission requirements, essential for a bulk mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely short (5 words). While concise, it lacks necessary qualifying information that would justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema, the description fails to communicate expected return values, possible errors, or aggregate behavior for bulk operations, leaving critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so baseline is 3. The description adds nothing beyond schema; no explanation of the journals_json format or how calendar_uid relates to the operation.
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 the tool creates multiple journal entries in bulk, distinguishing it from single journal creation (create_journal) and other bulk operations by name and scope.
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 guidance on when to use this tool versus alternatives like create_journal for single entries or bulk_create_events/tasks, nor any prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_create_tasksB
Create multiple tasks in bulk
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Operation mode | continue |
| account | No | Account alias | |
| parallel | No | Execute operations in parallel | |
| request_id | No | ||
| tasks_json | Yes | JSON array of task data | |
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the purpose. It does not disclose whether the operation is atomic, error handling, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste, but it could be structured to include more useful details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered. However, the description lacks context like batch limits, performance notes, or relationship to sibling tools, making it somewhat incomplete for a bulk operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so the baseline is 3. The description adds no extra meaning to parameters beyond what the schema provides.
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 creates multiple tasks in bulk, distinguishing it from single-task creation tools like create_task and other bulk creation tools like bulk_create_events.
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 guidance is provided on when to use this tool versus alternatives (e.g., create_task for single tasks). The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_delete_eventsC
Delete multiple events in bulk
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Operation mode | continue |
| account | No | Account alias | |
| parallel | No | Execute operations in parallel | |
| event_uids | Yes | List of event UIDs to delete | |
| request_id | No | ||
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the basic operation (deleting events) but reveals nothing about error handling, partial failures, authorization requirements, side effects, or return value (despite an output schema existing). This is insufficient for safe autonomous use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise. However, it does not 'earn its place' by providing additional value beyond the obvious. For a tool with six parameters and an output schema, a slightly expanded description would improve clarity without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bulk operation, six parameters, output schema) and absence of annotations, the description is far from complete. It fails to explain bulk semantics (atomic vs partial), expected results, or error scenarios. The output schema exists but is not referenced, leaving the agent uninformed about return values.
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?
The input schema already describes 83% of parameters with meaningful descriptions. The tool description adds no additional semantic context beyond what the schema provides, meeting the baseline expectation but not exceeding it.
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 identifies the verb 'Delete', the resource 'events', and the bulk operation. It implicitly distinguishes from 'delete_event' which handles single events, but does not explicitly contrast with other bulk delete tools for journals or tasks. Overall, it's specific enough for an agent to understand the tool's primary function.
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 such as 'delete_event' for single deletions or other bulk delete tools. There are no usage context, prerequisites, or exclusion criteria, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_delete_journalsB
Delete multiple journal entries in bulk
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Operation mode | continue |
| account | No | Account alias | |
| parallel | No | Execute operations in parallel | |
| request_id | No | ||
| calendar_uid | Yes | Calendar UID | |
| journal_uids | Yes | List of journal UIDs to delete |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits like irreversibility, partial failure handling, or required permissions. Minimal info beyond basic action.
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?
Single short sentence with no unnecessary words. Efficiently conveys core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite presence of output schema and 6 parameters, description lacks details on return values, error conditions, or batch behavior. Incomplete for a bulk operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83% (5 of 6 params described in schema). Description adds no value beyond schema. Baseline 3 applies.
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?
Description clearly states the verb 'delete' and resource 'multiple journal entries', and the term 'bulk' distinguishes it from the single delete sibling tool.
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 guidance on when to use this tool vs 'delete_journal' or other alternatives. No context about prerequisites, permissions, or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_delete_tasksB
Delete multiple tasks in bulk
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Operation mode | continue |
| account | No | Account alias | |
| parallel | No | Execute operations in parallel | |
| task_uids | Yes | List of task UIDs to delete | |
| request_id | No | ||
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to state whether deletions are permanent, handle partial failures, or mention any rate limits or permissions, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could be slightly expanded to include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description lacks crucial context like the behavior of mode and parallel parameters, reversibility, and prerequisites. For a bulk operation, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so the schema already documents most parameters. The description adds no extra meaning beyond the schema. Baseline of 3 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 'Delete multiple tasks in bulk' clearly states the verb (Delete), resource (tasks), and scope (multiple). It distinguishes from sibling tools like delete_task (single) and other bulk_delete_* tools.
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 usage for deleting multiple tasks but provides no explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned, though sibling tool names help differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_calendarC
Create a new calendar
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Calendar name | |
| color | No | Calendar color (hex format) | |
| account | No | Account alias (uses default if not specified) | |
| description | No | Calendar description |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.7/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as permissions required, side effects, or limits. This is insufficient for a creation tool.
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 sentence with no wasted words. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what is returned (e.g., the created calendar ID). With no annotations and 4 parameters, the description is too minimal to be complete.
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?
The schema covers 100% of the parameters with descriptions. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
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 states 'Create a new calendar', which is a clear verb+resource pair. It distinguishes from sibling creation tools like create_event or create_journal, as those target different entities.
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 guidance on when to use this tool versus alternatives, such as using add_account for a different kind of calendar setup. There are no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_eventB
Create a new calendar event
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | Event end time (ISO format) | |
| start | Yes | Event start time (ISO format) | |
| account | No | Account alias | |
| all_day | No | Whether this is an all-day event | |
| summary | Yes | Event title/summary | |
| location | No | Event location | |
| related_to | No | List of related component UIDs | |
| description | No | Event description | |
| calendar_uid | Yes | Calendar UID | |
| alarm_minutes | No | Reminder minutes before event as string ('-10080' to '10080') | |
| attendees_json | No | JSON string of attendees list [{email, name, role, status, rsvp}] | |
| recurrence_rule | No | RRULE for recurring events (e.g., 'FREQ=WEEKLY;BYDAY=MO') |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Create a new calendar event'. It does not disclose behavioral traits such as success/failure behavior, required permissions, or side effects. This is insufficient for a mutation tool.
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?
Single sentence with no fluff, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 12 parameters and the description is extremely minimal. It lacks context about prerequisites, default behavior, or usage constraints, making it incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no parameter meaning beyond the schema, thus no improvement.
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 'Create a new calendar event' clearly states the action (create) and the resource (calendar event). It distinguishes from siblings like bulk_create_events and create_recurring_event, making it specific.
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 guidance on when to use this tool versus alternatives. For example, it does not mention that for recurring events, 'create_recurring_event' should be used instead, leaving the agent without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_journalC
Create a new journal entry
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account alias | |
| summary | Yes | Journal entry title/summary | |
| entry_date | No | Journal entry date (ISO format) | |
| related_to | No | List of related component UIDs | |
| description | No | Journal entry content | |
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the name. With no annotations, the agent is left unaware of side effects, auth requirements, rate limits, or any implicit constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it does not earn its place by adding value. It is adequate but minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present, the description fails to explain the tool's purpose in context. With 6 parameters and sibling tools, it lacks guidance on how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning or context for parameters like account, entry_date, or related_to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new journal entry' is a tautology that merely restates the tool name. It does not differentiate from sibling create tools (e.g., create_event, create_task) or specify what a journal entry is.
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 guidance is provided on when to use this tool versus alternatives like bulk_create_journals or create_event. There is no mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_recurring_eventC
Create a recurring event with validation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| start | Yes | Event start time (ISO format) | |
| account | No | Account alias | |
| summary | Yes | Event title/summary | |
| location | No | Event location | |
| description | No | Event description | |
| calendar_uid | Yes | Calendar UID | |
| alarm_minutes | No | Reminder minutes before event | |
| attendees_json | No | JSON string of attendees list | |
| recurrence_rule | Yes | RRULE for recurring events | |
| duration_minutes | Yes | Event duration in minutes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Create' implies mutation, but nothing is said about side effects, required permissions, validation specifics, or idempotency. The description is too minimal to inform safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the single-sentence description is concise, it is under-specified for a tool with 10 parameters and many siblings. It lacks critical details and earns its place poorly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, 5 required, output schema present but not described), the description omits details about return values and does not differentiate from sibling tools. It is incomplete for tool selection.
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?
The input schema has 100% coverage with clear descriptions for each parameter (e.g., 'Event start time (ISO format)', 'RRULE for recurring events'). The description adds no extra meaning, so it meets the baseline but does not enhance understanding.
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 the tool creates a recurring event, which aligns with the name. The addition of 'with validation' hints at some checks, but it does not distinguish from sibling tools like 'create_event' that likely creates a single event.
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 guidance is provided on when to use this tool versus alternatives such as 'create_event' for single events or 'bulk_create_events' for multiple events. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_taskC
Create a new task
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| due | No | Task due date (ISO format) | |
| status | No | Task status (NEEDS-ACTION, IN-PROCESS, COMPLETED, CANCELLED) | NEEDS-ACTION |
| account | No | Account alias | |
| summary | Yes | Task title/summary | |
| priority | No | Task priority (1-9, 1 is highest) | |
| related_to | No | List of related component UIDs | |
| description | No | Task description | |
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description fails to disclose behavioral traits such as side effects, required permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise but overly minimal; it lacks important context that should be front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and an output schema, the description omits details about return values, parameter relationships, and constraints, making it insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema.
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 'Create a new task' clearly states the action and resource, but does not differentiate from sibling tools like bulk_create_tasks or create_recurring_event.
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 guidance on when to use this tool versus alternatives, nor any prerequisites like needing a calendar UID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_calendarC
Delete a calendar
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account alias (uses default if not specified) | |
| request_id | No | ||
| calendar_uid | Yes | Calendar UID to delete |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.7/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'Delete a calendar' without any behavioral traits such as irreversibility, permissions, or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but omits essential context, making it less effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a simple operation, the description lacks usage context and behavioral details, leaving the agent underinformed.
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?
Schema coverage is 67% (2 of 3 parameters have descriptions), but the tool description adds no additional meaning beyond the schema. Request_id parameter is undocumented.
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?
Description clearly states verb 'Delete' and resource 'calendar', distinguishing it from sibling tools like delete_event or delete_task.
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 guidance on when to use or not use this tool. No mention of prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_eventC
Delete a calendar event
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account alias | |
| event_uid | Yes | Event UID to delete | |
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details such as side effects, permissions, or reversibility. The full burden falls on the description, which is minimal.
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?
Single sentence, no wasted words. Could include more detail, but it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation, the description lacks crucial context about consequences, prerequisites, or behavior with recurring events. Even with an output schema, the description is too sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters. The description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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?
Description clearly states 'Delete a calendar event', specifying the verb and resource. It is distinguishable from siblings like create_event and bulk_delete_events, though it does not explicitly differentiate from bulk_delete_events.
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 guidance on when to use this tool versus alternatives (e.g., bulk_delete_events, delete_calendar). An agent would have no context for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_journalB
Delete a journal entry
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account alias | |
| request_id | No | ||
| journal_uid | Yes | Journal UID to delete | |
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Delete a journal entry' without disclosing behavioral traits such as permanence, permission requirements, side effects, or whether the operation is reversible. For a destructive action, this is a significant gap.
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 concise sentence with no redundant or irrelevant information. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema but the description does not explain what it returns (e.g., success status, deleted object). Additionally, there is no mention of idempotency or error handling. For a simple delete, this is adequate but not comprehensive.
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?
The input schema covers 75% of parameters with descriptions, so the baseline is 3. The tool description adds no additional meaning beyond the schema, but the schema itself is fairly clear on required parameters (calendar_uid, journal_uid) and optional ones (account, request_id).
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 'Delete a journal entry' clearly identifies the verb (delete) and resource (journal entry), making the purpose immediately understandable. However, it does not distinguish this tool from the sibling 'bulk_delete_journals', which is a closely related alternative.
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 like 'bulk_delete_journals', nor does it mention any prerequisites or conditions for use. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_taskC
Delete a task
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account alias | |
| task_uid | Yes | Task UID to delete | |
| request_id | No | ||
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any behavioral disclosure beyond the action of deletion. It does not state whether deletion is permanent, soft, or if there are side effects (e.g., on recurring events). With no annotations, the description carries full burden but fails to provide crucial safety or behavior details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words) but lacks structure such as bullet points or separation of concerns. It is front-loaded but too minimal to provide adequate context. While concise, it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description is incomplete. It does not explain the return value, required permissions, or the effect of optional parameters. The description provides insufficient context for proper invocation.
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?
The input schema has 75% description coverage, so the schema already documents most parameters. The description 'Delete a task' adds no additional meaning beyond the schema. Baseline of 3 applies as schema covers most semantics.
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 'Delete a task' clearly states the verb and resource, distinguishing it from sibling tools like 'delete_event' or 'bulk_delete_tasks' through the resource name. However, it does not explicitly specify that it deletes a single task, which could cause confusion with 'bulk_delete_tasks'.
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 guidelines are provided. The description does not mention when to use this tool over alternatives (e.g., single vs bulk deletion) or any prerequisites or conditions. This leaves the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_events_rangeC
Get events within a date range
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account alias | |
| end_date | Yes | End date (ISO format) | |
| start_date | Yes | Start date (ISO format) | |
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Get' implies a read-only operation, but no additional behavioral traits are disclosed. With no annotations, the description should specify that it does not modify data, what happens with empty results, or any side effects. Currently, it is minimal.
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?
Single sentence, 5 words, with the verb front-loaded. Extremely concise, but could benefit from a bit more structure or detail without becoming verbose. Still effective for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description combined with schema is adequate. However, it lacks context about calendar requirement, date inclusivity, and how it differs from search_events, which has similar functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The tool description adds no extra meaning beyond the schema, such as explaining the optional account parameter or date format nuances. Baseline 3 is appropriate.
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?
Description clearly states the action (Get), resource (events), and constraint (within a date range). It differentiates from siblings like search_events, create_event, etc., but could explicitly mention that events are tied to a specific calendar.
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 guidance on when to use this tool vs alternatives like search_events or list_calendars. No mention of prerequisites, exclusions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_accountsA
List all configured CalDAV accounts
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action ('List all configured CalDAV accounts') with no disclosure of behaviors like idempotency, rate limits, or prerequisites. The read-only nature is implied but not explicit.
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?
Extremely concise: one sentence, 5 words, no fluff. Every word earns its 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?
Given the output schema exists (not shown), the description need not explain return values. For a simple list tool with no parameters, the description adequately conveys its purpose, though it lacks context on prerequisites or 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?
No parameters exist, so baseline is 4. The description adds no parameter information, but schema coverage is 100% (empty 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 ('List') and resource ('all configured CalDAV accounts'), clearly distinguishing it from sibling tools like add_account, remove_account, and test_account that operate on the same resource.
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 guidance on when to use this tool versus siblings (e.g., test_account for checking connectivity). The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_calendarsC
List all calendars for an account
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account alias (uses default if not specified) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states the basic action without disclosing outcomes for null account, pagination, read-only nature, or any side effects. This is insufficient for an agent to predict behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded. While concise, it lacks substantive detail; however, it does not contain unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, reducing the need for extensive description. However, the description omits helpful context like typical use (e.g., obtaining calendar IDs) that would aid an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the parameter. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
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 the verb 'list' and resource 'calendars' with scope 'for an account'. It is specific and unambiguous, though no differentiation from siblings is provided, which is acceptable as no sibling performs a similar listing.
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 guidance is provided on when to use this tool versus alternatives, such as prerequisites or typical use cases. The description lacks any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_journalsB
List journal entries in a calendar
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of journals to return | |
| account | No | Account alias | |
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavior such as pagination, ordering, or scope of journals returned (e.g., date range). The minimal description adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it could be restructured to front-load key information, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and high schema coverage, the description lacks usage guidance, behavioral details, and context that would help an agent decide when to use this tool. It feels incomplete for the complexity of the toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond what the schema already provides for parameters like limit and account.
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 journal entries in a calendar, which matches the required calendar_uid parameter and distinguishes it from sibling tools like bulk_create_journals or delete_journal.
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 guidance on when to use this tool versus alternatives like get_events_range or list_tasks. No mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tasksC
List tasks in a calendar
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account alias | |
| calendar_uid | Yes | Calendar UID | |
| status_filter | No | Filter by status (NEEDS-ACTION, IN-PROCESS, COMPLETED, CANCELLED) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It does not disclose behavioral traits like pagination, ordering, rate limits, or whether tasks are returned in a specific format. The presence of an output schema is known but not leveraged in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. However, it could be expanded slightly to add value without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (1 required) and an output schema, the description is too minimal. It does not address what the output contains, pagination behavior, or ordering. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema, not explaining parameters like account or status_filter in any detail.
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 'List tasks in a calendar' clearly states the action (list) and resource (tasks) with scope (in a calendar), distinguishing from sibling tools like create_task or delete_task. However, it does not mention filtering or sorting options which are present in the input schema.
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 guidance is provided on when to use this tool vs alternatives such as search_events or get_events_range. There are no explicit recommendations or exclusions for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_accountC
Remove a CalDAV account from Chronos
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | Account alias to remove | |
| request_id | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'remove' without clarifying whether the operation is reversible, requires authorization, or affects related data like events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose with no superfluous words. However, it is too brief for a potentially destructive action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is a removal action with 2 parameters and no behavioral annotations, the description is too minimal. It does not explain account existence checks, consequences, or how to use output, making it inadequate for safe usage.
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?
Schema description coverage is 50% (alias is described in schema, request_id is not). The description does not add extra meaning beyond the schema, and with low coverage, it fails to compensate for undocumented parameters.
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 'Remove a CalDAV account from Chronos', specifying the verb 'remove' and the resource 'CalDAV account', distinguishing it from sibling tools like delete_calendar or delete_event.
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 (e.g., list_accounts or test_account), lacks prerequisites or side effects, and does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eventsB
Search for events across calendars with advanced filtering
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| fields | No | Fields to search in | |
| account | No | Account alias | |
| date_end | No | End date for search range | |
| date_start | No | Start date for search range | |
| max_results | No | Maximum number of results | |
| calendar_uid | No | Calendar UID to search in | |
| case_sensitive | No | Case sensitive search |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits like read-only, authorization needs, or result handling. Simply restates the tool name with 'advanced filtering'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, though slightly too minimal for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and many sibling tools, the description omits key capabilities like date range, calendar filtering, and case sensitivity, which are only revealed in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 8 parameters (100%), but the tool description adds no additional meaning or context beyond what is already in 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?
Description clearly specifies the verb 'Search', resource 'events', and qualifier 'across calendars with advanced filtering', effectively distinguishing from siblings like get_events_range.
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 use when advanced filtering is needed, but lacks explicit when-to-use or when-not-to-use guidance relative to sibling tools. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test_accountA
Test connectivity to a CalDAV account
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | Account alias to test |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It merely states 'Test connectivity' without disclosing behavioral traits such as whether the operation is read-only, requires the account to exist, or what happens on failure. This is insufficient for a tool with no 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 a single sentence that is concise and clear. It contains no unnecessary words and is well-structured for quick comprehension.
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 simplicity (one parameter) and the presence of an output schema, the description is almost complete. It states the core purpose, but could mention that the tool does not modify any data. Nevertheless, it adequately serves its purpose.
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?
The single parameter 'alias' is described in the schema as 'Account alias to test'. The description does not add any additional meaning or context beyond the schema. Since schema coverage is 100%, the baseline score is 3, and no extra value is provided.
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 purpose: 'Test connectivity to a CalDAV account'. It uses a specific verb ('test') and resource ('connectivity to a CalDAV account'), which distinguishes it from sibling tools like add_account, remove_account, etc.
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?
No explicit usage guidelines are provided. The description implies the tool is for testing connectivity, but does not specify when to use it (e.g., after adding an account) or when not to use it. There are no alternative testing tools among siblings, so the context is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_eventA
Update an existing calendar event. Only provided fields will be updated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Event end time (ISO format) | |
| start | No | Event start time (ISO format) | |
| account | No | Account alias | |
| all_day | No | Whether this is an all-day event | |
| summary | No | Event title/summary | |
| location | No | Event location | |
| event_uid | Yes | Event UID to update | |
| description | No | Event description | |
| calendar_uid | Yes | Calendar UID | |
| alarm_minutes | No | Reminder minutes before event | |
| attendees_json | No | JSON string of attendees list | |
| recurrence_rule | No | RRULE for recurring events |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It mentions partial update behavior, but lacks details on authorization, error handling, rate limits, or what happens if the event doesn't exist. Output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. However, it lacks structure (e.g., bullet points) and front-loading of critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, high schema coverage, and an output schema, the description is brief. It covers the core behavior but omits details like prerequisites, error scenarios, and output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reinforces that only provided fields are updated, but adds no new meaning 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 'Update an existing calendar event,' specifying the verb 'Update' and resource 'calendar event,' distinguishing it from create, delete, and other sibling tools.
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?
No explicit guidance on when to use this tool versus alternatives like delete+create or bulk operations. The phrase 'Only provided fields will be updated' implies partial update, but no when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_journalB
Update an existing journal entry. Only provided fields will be updated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account alias | |
| summary | No | Journal entry title/summary | |
| entry_date | No | Journal entry date (ISO format) | |
| request_id | No | ||
| description | No | Journal entry content | |
| journal_uid | Yes | Journal UID to update | |
| calendar_uid | Yes | Calendar UID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description carries full burden. It notes partial update behavior ('Only provided fields will be updated') but omits details on idempotency, authorization, or error handling.
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, no fluff. Critical 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with an output schema, the description is adequate but missing usage guidelines and behavioral details. It covers the core functionality but not enough for an agent to use it effectively in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so most parameters are already documented. The description adds the 'only provided fields' nuance, which enhances understanding but does not elaborate on individual parameters.
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 'Update an existing journal entry', providing a specific verb and resource. It distinguishes from sibling tools like create_journal or delete_journal.
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 guidance on when to use this tool vs alternatives (e.g., bulk_create_journals or update_task). No explicit when-not or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_taskA
Update an existing task. Only provided fields will be updated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| due | No | Task due date (ISO format) | |
| status | No | Task status | |
| account | No | Account alias | |
| summary | No | Task title/summary | |
| priority | No | Task priority (1-9, 1 is highest) | |
| task_uid | Yes | Task UID to update | |
| request_id | No | ||
| description | No | Task description | |
| calendar_uid | Yes | Calendar UID | |
| percent_complete | No | Completion percentage (0-100) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It conveys partial update semantics ('Only provided fields will be updated') but omits details like error handling, side effects, or authentication requirements.
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, no redundant information, and front-loaded with the primary purpose.
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 tool has 10 parameters and an output schema, but the description is brief. It covers core behavior but could benefit from additional context like return value or constraints.
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 90%, so baseline is 3. The description adds value by stating the partial update behavior, clarifying that only provided fields change, which is not explicit in 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 verb 'Update' and the resource 'existing task', distinguishing it from sibling tools like update_event and update_journal. The behavior is clarified with 'Only provided fields will be updated.'
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 does not explicitly state when to use this tool versus alternatives, such as create_task or delete_task. It implies usage by context but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
27 tool updates
v2.1.0- First observed
add_account - First observed
bulk_create_events - First observed
bulk_create_journals - First observed
bulk_create_tasks - First observed
bulk_delete_events - First observed
bulk_delete_journals - First observed
bulk_delete_tasks - First observed
create_calendar - First observed
create_event - First observed
create_journal - First observed
create_recurring_event - First observed
create_task - First observed
delete_calendar - First observed
delete_event - First observed
delete_journal - First observed
delete_task - First observed
get_events_range - First observed
list_accounts - First observed
list_calendars - First observed
list_journals - First observed
list_tasks - First observed
remove_account - First observed
search_events - First observed
test_account - First observed
update_event - First observed
update_journal - First observed
update_task
TDQS
B3.2/5.0
Scored across 27 tools
Disambiguation5/5
Each tool targets a distinct resource (account, calendar, event, journal, task) and action (create, update, delete, list, etc.). No two tools have overlapping purposes, and descriptions clearly differentiate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., add_account, create_calendar, update_event). Bulk operations use prefix 'bulk_' uniformly. No mixing of conventions.
Tool Count4/5
27 tools cover accounts, calendars, and CRUD for three resource types (events, journals, tasks) plus bulk operations and search. While slightly high, each tool serves a specific need and the count is justified by the domain scope.
Completeness4/5
The tool surface includes account management, calendar CRUD, and full CRUD plus extras (recurring events, search, bulk ops) for events, journals, and tasks. Missing calendar updates and some advanced features, but core workflows are well covered.
Maintenance
ActivityInactive
ResponsivenessUnresponsive
Related MCP Connectors
A MCP server that works with Google Calendar to manage event listing, reading, and updates.
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
A MCP server that works with Outlook Calendar to manage event listing, reading, and updates.
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server for Apple Calendar and CalDAV providers. Enables listing, creating, updating, deleting events, and checking free/busy status with per-calendar write protection.6MIT
- FlicenseNot gradedqualityCmaintenanceA production-quality MCP server for calendar management with robust timezone handling, recurrence support, and idempotency guarantees.-
- AlicenseAqualityAmaintenanceA thin, timezone-correct MCP server for scheduling against CalDAV calendars, providing tools for creating, updating, and managing events with proper timezone handling and recurrence support.111MIT