Click on "Install 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., "@TimeTree MCP Server list my calendars"
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.
⚠️ DISCLAIMER: This is an UNOFFICIAL TimeTree MCP server for PERSONAL USE ONLY. Not affiliated with TimeTree, Inc. May break at any time. See DISCLAIMER.md for full details.
Use Claude, Codex, Cursor, Windsurf, and other MCP clients to read and manage your TimeTree calendars, events, memos, comments, labels, and members — locally, with credentials kept in your MCP client configuration.
Credits: This project was inspired by and uses API insights from TimeTree-Exporter by @eoleedi.
📅 List Calendars - Get all your TimeTree calendars
📆 Get Events - Retrieve events from any calendar with automatic pagination
➕ Create Events - Add new events to your calendars
✏️ Update Events - Modify existing events
🗑️ Delete Events - Remove events from your calendars
🗒️ Manage Memos - List, create, update, and delete TimeTree memos
💬 Manage Comments - Add, list, update, and delete event comments
🏷️ Calendar Metadata - Read/update labels and inspect members/virtual members
🔐 Secure Authentication - Email/password authentication (stored only in MCP config)
⚡ Rate Limiting - Token bucket algorithm to prevent API overload
🔄 Auto Pagination - Automatically fetches all events across multiple pages
🛡️ Error Handling - Comprehensive error handling with user-friendly messages
📝 Structured Logging - Detailed logs with sensitive data masking
Node.js >= 18.0.0
Git (for installation)
A TimeTree account
An MCP-compatible client (Claude Desktop, Claude Code, Codex, Antigravity, Cline, etc.)
Copy this prompt into Codex, Claude Code, or another coding agent:
Clone
https://github.com/ehs208/TimeTree-MCP, enter the cloned directory, runnpm ci && npm run build, then configure my MCP client with a server namedtimetreethat runsnode /absolute/path/to/TimeTree-MCP/dist/index.js(use the real cloned path). StoreTIMETREE_EMAILandTIMETREE_PASSWORDonly in the MCP client environment configuration, and never hardcode or print secrets.
If this saved you time, please star the repo: https://github.com/ehs208/TimeTree-MCP
One-line installation - Automatically clones, builds, attempts optional npm link, and prints client configuration examples:
curl -fsSL https://raw.githubusercontent.com/ehs208/TimeTree-MCP/main/TimeTree-MCP-install.sh | bashThis project is installed from a GitHub clone, not the npm registry. The script builds the local clone, optionally runs npm link, then prints configuration instructions with absolute node/dist/index.js paths for all supported MCP clients. Just copy the config for your client and add your TimeTree credentials.
Clone and build:
git clone https://github.com/ehs208/TimeTree-MCP.git
cd TimeTree-MCP
npm ci
npm run buildConfigure your MCP client:
See the Configuration section below to set up your MCP client.
Quick Example (Claude Desktop - macOS):
Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"timetree": {
"command": "node",
"args": ["/absolute/path/to/TimeTree-MCP/dist/index.js"],
"env": {
"TIMETREE_EMAIL": "your-email@example.com",
"TIMETREE_PASSWORD": "your-password"
}
}
}
}Replace the path with your cloned repository path. If a GUI client cannot find node, use the absolute path from command -v node as command. Then restart Claude Desktop (Cmd+Q and reopen).
📖 For all MCP clients (Claude Desktop Windows, Claude Code CLI, Codex, Antigravity, VS Code editors, etc.): → See docs/MCP_CLIENTS.md for detailed configuration instructions
To update to the latest version:
cd /path/to/TimeTree-MCP # or your installation path
git pull origin main
npm ci
npm run buildThen restart your MCP client.
📖 For detailed update instructions and troubleshooting: → See docs/UPDATING.md
📖 See COMMANDS.md for detailed usage examples and workflows
list_calendars - List all calendars with participating users
get_events - Get events from a calendar with auto-pagination
get_updated_events - Get events updated after a specific timestamp (efficient incremental sync)
create_event - Create a new event in a calendar (supports alerts, recurrences, attendees, checklist)
update_event - Update an existing event
delete_event - Delete an event from a calendar
list_memos / create_memo / update_memo / delete_memo - Manage TimeTree memos
add_event_comment / list_event_comments / update_event_comment / delete_event_comment - Manage event comments
get_calendar_labels / update_calendar_labels - Read or merge-update calendar labels
get_calendar_members / get_calendar_virtual_members - Read calendar member metadata
📖 See COMMANDS.md for parameters and usage details.
# Build the project
npm run build
# Watch mode (auto-rebuild on changes)
npm run devUnofficial API: May break if TimeTree changes their internal API
Rate Limited: 10 requests/second (with automatic retry for 429 errors)
No Official Support: TimeTree does not officially support this tool
CSRF Token Required: Write operations require CSRF token (automatically extracted from TimeTree web page)
Credentials are stored only in your local MCP configuration
Session cookies are stored in memory only (never persisted to disk)
Passwords and session IDs are automatically masked in logs
All communication uses HTTPS
Make sure TIMETREE_EMAIL and TIMETREE_PASSWORD are set in your MCP configuration.
Verify your email and password are correct
Check if you can log in to TimeTree web app
TimeTree might have changed their authentication API
Verify you have calendars/events in your TimeTree account
Check the logs for detailed error messages
The API might have changed
Contributions are welcome! Please:
Fork the repository
Create a feature branch
Make your changes
Submit a pull request
MIT License - see LICENSE file for details.
If this project helps you, please consider giving it a GitHub Star. It helps others discover the project.
See DISCLAIMER.md for important legal and usage information.
NOT AFFILIATED WITH TIMETREE, INC.
This is an independent, community-maintained project.
Add a comment to a TimeTree event using the verified event activity endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| silent | No | Whether to avoid push notifications when supported (default: true) | |
| content | Yes | Comment content | |
| event_uuid | Yes | The event UUID to comment on | |
| calendar_id | Yes | The calendar ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the action without disclosing side effects, permissions, or response behavior. Minimal behavioral info beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with purpose, no unnecessary words, and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not mention return values or behavior. For a simple creation tool, it is adequate but lacks specifics like what is returned upon success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description adds no extra meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'a comment to a TimeTree event', distinguishing it from siblings like update_event_comment and delete_event_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like update_event_comment or list_event_comments. Missing context on preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new event in a TimeTree calendar. Requires CSRF token (automatically managed). Returns the created event with UUID. Label colors (label_id 1-10): 1=Emerald green, 2=Modern cyan, 3=Deep sky blue, 4=Pastel brown, 5=Midnight black, 6=Apple red, 7=French rose, 8=Coral pink, 9=Bright orange, 10=Soft violet. Supports checklist, attendees, virtual attendees, alerts, RRULE recurrence strings, and category override.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Related URL | |
| note | No | Event notes/description | |
| title | Yes | Event title (required) | |
| alerts | No | Notification offsets in minutes before the event, e.g. [5, 30] | |
| end_at | Yes | Event end time as Unix timestamp in milliseconds. For all-day events, TimeTree uses an inclusive end date. | |
| all_day | No | Whether this is an all-day event (default: false). TimeTree uses inclusive end dates for all-day events. | |
| category | No | Event category (default: 1; memos use category=2) | |
| label_id | No | Color label ID (1-10). 1=Emerald, 2=Cyan, 3=Blue, 4=Brown, 5=Black, 6=Red, 7=Rose, 8=Pink, 9=Orange, 10=Violet | |
| location | No | Event location | |
| start_at | Yes | Event start time as Unix timestamp in milliseconds. For all-day events, use midnight of the start date. | |
| attendees | No | Calendar user IDs attending this event | |
| checklist | No | Checklist items to attach to the event | |
| file_uuids | No | Attached file UUIDs if already uploaded | |
| calendar_id | Yes | The calendar ID to create the event in (use list_calendars to get valid IDs) | |
| recurrences | No | RRULE strings, e.g. ["RRULE:FREQ=DAILY;COUNT=2"] | |
| end_timezone | No | End timezone (default: UTC) | |
| start_timezone | No | Start timezone (default: UTC). Examples: "Asia/Seoul", "America/New_York" | |
| virtual_user_attendees | No | Virtual member IDs/names attending this event |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool creates an event, requires a CSRF token (automatically managed), returns the created event with UUID, and supports various features (checklist, attendees, alerts, recurrences). It also explains label color mappings and inclusive end dates for all-day events, providing comprehensive 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences long, front-loading the core purpose. Every sentence provides essential information (returns, CSRF, label colors, supported features) without redundancy. It is efficiently structured and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, 4 required, no output schema) and the context of sibling tools, the description is complete. It covers all major aspects: purpose, return value, required context (CSRF), and supported features. The input schema handles parameter details, so the description does not need to repeat them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by clarifying TimeTree's inclusive end date behavior for all-day events, recommending midnight timestamps for all-day start_at, and listing color mappings for label_id. These details are not present in the schema descriptions and enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new event in a TimeTree calendar', specifying the verb (create), resource (event), and platform (TimeTree). It further distinguishes from sibling tools like create_memo and update_event by explicitly mentioning features like label colors, checklist, attendees, etc., which are unique to event creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes notes about CSRF token auto-management and the return of the created event with UUID, which aids usage. However, it does not explicitly state when to use this tool over alternatives (e.g., update_event or create_memo) or provide exclusion criteria, leaving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a TimeTree memo in a calendar using the verified category=2 event payload.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional related URL | |
| date | No | Optional memo date in YYYY-MM-DD; defaults to today UTC | |
| note | No | Memo body text | |
| title | Yes | Memo title | |
| label_id | No | Color label ID (1-10) | |
| location | No | Optional memo location | |
| checklist | No | Checklist items for the memo | |
| calendar_id | Yes | The calendar ID to create the memo in | |
| virtual_user_attendees | No | Virtual member IDs/names related to the memo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as idempotency, permissions required, error handling, or side effects. The phrase 'verified category=2 event payload' is opaque and does not clarify behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it includes a cryptic phrase ('verified category=2 event payload') that may reduce clarity. It could be more straightforward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 9 parameters, the description is minimal. It lacks behavioral context and usage guidance. Without an output schema, the description should provide more detail about what the tool returns or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 9 parameters with descriptions, so schema_description_coverage is 100%. The description adds no additional meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and the resource (TimeTree memo). It differentiates from siblings like create_event and add_event_comment by specifying 'memo'. However, the phrase 'using the verified category=2 event payload' is unclear and may confuse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_memo or list_memos. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an event from a TimeTree calendar. This action cannot be undone. Requires CSRF token (automatically managed).
| Name | Required | Description | Default |
|---|---|---|---|
| event_uuid | Yes | The UUID of the event to delete (from get_events) | |
| calendar_id | Yes | The calendar ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It mentions irreversibility and CSRF token requirement, which is good, but lacks detail on permissions, cascade effects, or notification behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, then key warnings. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with no output schema, the description covers purpose, irreversibility, and authentication. It is mostly complete, though could mention if deletion is permanent or any prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both parameters (calendar_id and event_uuid). The description adds no further meaning beyond what the schema 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an event from a TimeTree calendar', specifying the verb and resource. It distinguishes from siblings like create_event and update_event by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as update_event or delete_event_comment. The warning 'cannot be undone' is the only contextual note, but no explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a TimeTree event comment by comment/activity ID.
| Name | Required | Description | Default |
|---|---|---|---|
| comment_id | Yes | The comment/activity ID | |
| event_uuid | Yes | The event UUID | |
| calendar_id | Yes | The calendar ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the deletion action without disclosing side effects, irreversibility, permission requirements, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. However, it could be expanded to include critical usage details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimally adequate for a simple delete operation, but lacks information about success/failure responses, error handling, and authorization requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all parameters. The description adds no additional semantic value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (TimeTree event comment) and specifies the identifier (comment/activity ID). It distinguishes from siblings like add_event_comment and update_event_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It lacks context about prerequisites, error conditions, or when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a TimeTree memo. This action cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| memo_uuid | Yes | The memo UUID (same as event UUID) | |
| calendar_id | Yes | The calendar ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It mentions irreversibility ('cannot be undone') but lacks details on auth requirements, side effects, or return value. Minimal beyond the implied destruction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no unnecessary words. Front-loaded with purpose and immediate irreversibility warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple delete tool with no output schema, the description covers the essential: what it does and a key behavioral note. Lacks definition of 'memo' vs 'event' but contextually complete for the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the input schema (100% coverage), and the tool description adds no extra semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and resource 'TimeTree memo', distinguishing it from sibling tools like delete_event or delete_event_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as delete_event or update_memo. No when-not-to-use or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TimeTree calendar labels (IDs, names, colors, ordering).
| Name | Required | Description | Default |
|---|---|---|---|
| calendar_id | Yes | The calendar ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It correctly implies this is a read operation ('Get'), but does not explicitly state it has no side effects, requires no special permissions, or has rate limits. For a simple read tool, this is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (6 words) that efficiently conveys the tool's purpose without extraneous information. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the returned fields (IDs, names, colors, ordering) but does not specify the data structure (e.g., array of objects, flat list) or any pagination. Since there is no output schema, more detail on the return format would be helpful. However, for a simple label resource, the current level is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'calendar_id' parameter, and the schema already describes it as 'The calendar ID'. The tool description adds minimal context by referencing 'TimeTree calendar labels', which implies the parameter identifies which calendar. This aligns with the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('TimeTree calendar labels'), and lists the specific attributes returned (IDs, names, colors, ordering). This distinguishes it from siblings like 'list_calendars' (which fetches calendars) and 'update_calendar_labels' (which modifies them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., when to call 'get_calendar_labels' vs 'update_calendar_labels' or 'list_calendars'). A simple note about its read-only nature or typical use case (before updating labels) would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TimeTree calendar members from the verified v2 users endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| calendar_id | Yes | The calendar ID | |
| include_deactivated | No | Include deactivated members (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states it gets members but does not disclose authentication needs, rate limits, or behavior regarding the include_deactivated parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It front-loads the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description is adequate but does not explain the return format or potential side effects. It is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for both parameters. The description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get TimeTree calendar members', specifying the resource (calendar members) and verb (Get). It also indicates the source endpoint, distinguishing it from siblings like get_calendar_labels and get_calendar_virtual_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_calendar_virtual_members). There are no prerequisites or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TimeTree virtual members for a calendar from the verified virtual_users endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| calendar_id | Yes | The calendar ID | |
| include_deactivated | No | Include deactivated virtual members (default: false) |
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 of behavioral disclosure. It only states the tool retrieves virtual members from an endpoint, implying a read operation, but does not explicitly confirm safety or disclose any side effects, rate limits, or authorization requirements. The lack of detail is a significant gap for a tool with zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the core purpose. It is concise, front-loaded, and contains no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two parameters and no output schema, the description is minimally adequate. However, it does not cover expected behavior like response format, error handling, or pagination. Given the lack of annotations, a bit more detail would be beneficial, but it is not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters having basic descriptions. The tool description itself does not add any parameter-related information beyond the schema. According to guidelines, high coverage leads to a baseline of 3, and there is no additional value contributed by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('TimeTree virtual members'), and the scope ('for a calendar'). It effectively distinguishes itself from sibling tools like 'get_calendar_members' by specifying 'virtual members'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, such as when to choose it over 'get_calendar_members'. There is no mention of prerequisites, context, or exclusions. The bare description leaves the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all events from a specific TimeTree calendar. Automatically handles pagination to fetch all events. Returns event details including title, start/end times, location, notes, label color, and more. Label colors (label_id 1-10): 1=Emerald green, 2=Modern cyan, 3=Deep sky blue, 4=Pastel brown, 5=Midnight black, 6=Apple red, 7=French rose, 8=Coral pink, 9=Bright orange, 10=Soft violet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional limit on number of events to return. | |
| calendar_id | Yes | The calendar ID to fetch events from | |
| start_after | No | Optional Unix timestamp in milliseconds. Only return events starting after this time. If user provides a date like "2026-02-01", convert it to Unix timestamp (e.g., 1769904000000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description covers behavior: auto-pagination, returned fields (title, times, location, notes, label color). Includes label color mapping. Does not mention side effects or rate limits, but is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences. Front-loaded with core purpose and auto-pagination. Label color details are relevant and appended without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description lists key return fields. Lacks details on pagination mechanics and full return structure, but adequate for a simple fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value for 'start_after' by advising on date-to-timestamp conversion. Other parameters are sufficiently described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get all events from a specific TimeTree calendar', specifying the resource (events) and action (get). It distinguishes from siblings like 'get_updated_events' by mentioning automatic pagination to fetch all events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., 'get_updated_events' for partial updates). Usage context is implied but not directly compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get events from a specific TimeTree calendar that were updated after a specified time. Useful for finding recently modified events. Returns event details including title, start/end times, location, notes, label color, and more. Label colors (label_id 1-10): 1=Emerald green, 2=Modern cyan, 3=Deep sky blue, 4=Pastel brown, 5=Midnight black, 6=Apple red, 7=French rose, 8=Coral pink, 9=Bright orange, 10=Soft violet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional limit on number of events to return. | |
| calendar_id | Yes | The calendar ID to fetch updated events from | |
| updated_after | Yes | Unix timestamp in milliseconds. Only return events updated after this time. If user provides a date like "2026-02-01", convert it to Unix timestamp (e.g., 1769904000000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It mentions returned fields (title, times, location, etc.) but lacks details on inclusion/exclusion of updated_after, pagination, or rate limits. The label color mapping adds some context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a compact list of label colors. No redundant information. Could potentially separate the color list, but it remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so missing return structure. No mention of pagination, error handling, or behavior under edge cases. Adequate for basic usage but not fully comprehensive for a tool with 3 parameters and many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by explaining how to convert dates to timestamps for 'updated_after', and restates the purpose for 'calendar_id'. The label color mapping is a bonus beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', resource 'events from a specific TimeTree calendar', and filter 'updated after a specified time'. It distinguishes from siblings like 'get_events' (which likely lacks time filter) and other mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Useful for finding recently modified events', providing a usage context. However, it does not explicitly compare to alternatives like 'get_events' or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active TimeTree calendars for the authenticated user. Returns calendar ID, name, alias code, and participating users. Use this to identify which calendar to query when the user mentions a specific person (e.g., "events with [name]").
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits like auth requirements, rate limits, or return format beyond listing fields. Basic read operation implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, description covers return fields and a practical use case, fully adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds no extra parameter meaning, but baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'list all active TimeTree calendars' with specific verb and resource, and it distinguishes from sibling tools by focusing on calendars rather than events or memos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context on when to use (identify calendar when user mentions a person), though lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List comments for a TimeTree event. Filters activity feed entries to comment activities only.
| Name | Required | Description | Default |
|---|---|---|---|
| event_uuid | Yes | The event UUID | |
| calendar_id | Yes | The calendar ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the action (list comments) without mentioning read-only nature, pagination, permissions, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with the main action. The second sentence is somewhat redundant but does not significantly harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fails to mention what the response contains (e.g., list of comment objects, fields). It also omits context about sorting, filtering, or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds minimal extra meaning beyond identifying that it lists comments for an event, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'comments for a TimeTree event', distinguishing it from sibling tools like add_event_comment. The second sentence about filtering activity feed is slightly confusing but does not detract from the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it or suggest other tools for mutating comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List TimeTree memos in a calendar. Memos are category=2 all-day events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional limit on number of memos returned | |
| calendar_id | Yes | The calendar ID to list memos from | |
| updated_after | No | Only return memos updated after this Unix timestamp in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only notes that memos are all-day events. It does not mention pagination, rate limits, sorting, or how many memos are returned. The agent lacks critical 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential: first states the action and resource, second clarifies the meaning of memos. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not explain return values or structure. It provides the key fact that memos are all-day events, but omits usage context, fallback behaviors, and output format, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra information about the parameters (calendar_id, updated_after, limit) beyond the schema descriptions. It does not explain how parameters interact or affect results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'TimeTree memos in a calendar', and adds specificity by defining memos as category=2 all-day events. However, it does not explicitly differentiate from sibling tools like list_events or get_events, though the focus on memos provides implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as create_memo or update_memo, nor any prerequisites or exclusions. The agent must infer usage context from the tool name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update TimeTree calendar label names/colors. The tool first reads existing labels and merges supplied labels so omitted labels are preserved.
| Name | Required | Description | Default |
|---|---|---|---|
| labels | Yes | Labels to update/merge. Omitted labels are preserved. | |
| calendar_id | Yes | The calendar ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool first reads existing labels and then merges supplied ones, providing key behavioral context beyond what the input schema offers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the action, the second explains the merge behavior. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description is fairly complete. It explains the merge process adequately, though it could add details about validation or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, mainly reinforcing the merge behavior already stated in the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: updating TimeTree calendar label names and colors. It distinguishes itself from sibling tools like create_event or delete_event by focusing on label updates with a specific merge strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the merge behavior, implying when to use this tool for partial updates while preserving omitted labels. However, it does not explicitly state when not to use it or mention alternatives like get_calendar_labels for reading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing event in a TimeTree calendar. Only provide the fields you want to change. Requires CSRF token (automatically managed). Returns the updated event. Supports checklist, attendees, virtual attendees, alerts, RRULE recurrence strings, and category override.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | New related URL | |
| note | No | New event notes | |
| title | No | New event title | |
| alerts | No | Replace notification offsets in minutes; use [] to clear | |
| end_at | No | New end time as Unix timestamp in milliseconds | |
| all_day | No | Whether this is an all-day event | |
| category | No | New event category | |
| label_id | No | New color label ID (1-10) | |
| location | No | New event location | |
| start_at | No | New start time as Unix timestamp in milliseconds | |
| attendees | No | Replace calendar user attendee IDs | |
| checklist | No | Replace event checklist items. Use [] to clear checklist. | |
| event_uuid | Yes | The UUID of the event to update (from get_events) | |
| file_uuids | No | Replace attached file UUIDs | |
| calendar_id | Yes | The calendar ID | |
| recurrences | No | Replace recurrence RRULE strings | |
| end_timezone | No | New end timezone | |
| start_timezone | No | New start timezone (e.g., "Asia/Seoul") | |
| virtual_user_attendees | No | Replace virtual member attendees. Use [] to clear. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses CSRF token management and that it returns the updated event. However, it omits side effects (e.g., notifications, recurrence handling) and error conditions, which are important for a mutation tool with 19 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff: purpose, partial update hint, and a bullet list of supported features. Front-loaded and efficiently conveys essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 19 parameters, no output schema, and many siblings, the description covers key behavioral aspects (partial update, return value). It lacks details on error handling or specific parameter constraints, but the schema fills many gaps, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is described. The description adds value by explaining partial update behavior ('Only provide the fields you want to change') and summarizing supported parameter groups (checklist, attendees, etc.), which aids in understanding which parameters are relevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing event in a TimeTree calendar', providing a specific verb and resource. Among siblings like create_event and delete_event, this tool is uniquely identified for event updates, and the partial update hint distinguishes it further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Only provide the fields you want to change' implies partial update semantics. It lists supported features (checklist, attendees, etc.), helping agents decide when to use this tool. However, it does not explicitly contrast with create_event or mention prerequisites like event existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a TimeTree event comment by comment/activity ID.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | New comment content | |
| comment_id | Yes | The comment/activity ID | |
| event_uuid | Yes | The event UUID | |
| calendar_id | Yes | The calendar ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as whether the update is a full replacement, idempotency, or authorization requirements. Significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with the action front-loaded. Concise but could benefit from more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks context about how to obtain the comment/activity ID or relationship to event and calendar. No output schema or behavioral details, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. Description adds no additional meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (update), resource (event comment), and method (by comment/activity ID). Distinguishes from sibling tools like add_event_comment and delete_event_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like add_event_comment or delete_event_comment. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a TimeTree memo. Only provide the fields you want to change.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | New related URL | |
| note | No | New memo body text | |
| title | No | New memo title | |
| label_id | No | New color label ID (1-10) | |
| location | No | New memo location | |
| checklist | No | Replace checklist items; use [] to clear | |
| memo_uuid | Yes | The memo UUID (same as event UUID) | |
| calendar_id | Yes | The calendar ID | |
| virtual_user_attendees | No | Replace virtual member attendees; use [] to clear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'update' and partial update behavior. Does not disclose permissions, side effects, idempotency, or error handling. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description is too sparse. Does not explain return values, error conditions, or prerequisites for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters. The description adds only the partial update hint, which is already implied by optional fields. No additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states the verb 'Update' and resource 'TimeTree memo'. Distinguishes from create_memo and other sibling tools by specifying it's for updating an existing memo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context: use when you need to modify a memo. No explicit when-not-to-use or alternative tools mentioned, but the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0add_event_commentcreate_eventcreate_memodelete_eventdelete_event_commentdelete_memoget_calendar_labelsget_calendar_membersget_calendar_virtual_membersget_eventsget_updated_eventslist_calendarslist_event_commentslist_memosupdate_calendar_labelsupdate_eventupdate_event_commentupdate_memoEach tool targets a distinct resource-action combination: events, memos, comments, calendar metadata, and labels are clearly separated. The difference between events and memos is well explained, and get_events vs get_updated_events serve different purposes.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_event, update_calendar_labels, list_calendars), making the API predictable and easy to navigate.
18 tools is slightly above typical but justified by the breadth of operations covering events, memos, comments, labels, and members. Each tool has a clear purpose and no obvious redundancy.
The surface covers CRUD for events and memos, comments, label management, and member retrieval. Missing calendar creation or search functionality, but core workflows are well supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server that works with Google Calendar to manage event listing, reading, and updates.
MCP server providing attendance data queries via the CloudTime API.
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
The official Planning Center MCP server for interacting with your ministry's data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ehs208/TimeTree-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
