trilium-calendar-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | HTTP binding host | 0.0.0.0 |
| MCP_PATH | No | HTTP binding path | /mcp |
| MCP_PORT | No | HTTP binding port | 8102 |
| LOG_LEVEL | No | Log verbosity (logs go to stderr) | INFO |
| TRILIUM_URL | Yes | Trilium base URL (no /etapi suffix) | |
| MCP_TRANSPORT | No | Transport: stdio, streamable-http (alias http) or sse | stdio |
| TRILIUM_TIMEOUT | No | Per-request timeout (seconds) | 30 |
| TRILIUM_TIMEZONE | No | Timezone used to interpret naive datetimes | Asia/Shanghai |
| MCP_ALLOWED_HOSTS | No | Optional host:port allowlist; enables the DNS-rebinding check for binds where it is otherwise off | |
| TRILIUM_CALENDARS | Yes | Calendars to expose — comma-separated note ids, optionally named with :alias | |
| TRILIUM_CA_BUNDLE | No | Custom CA bundle path | |
| TRILIUM_VERIFY_SSL | No | Set false for a self-signed instance | true |
| MCP_ALLOWED_ORIGINS | No | Optional Origin allowlist to accompany MCP_ALLOWED_HOSTS | |
| TRILIUM_ETAPI_TOKEN | Yes | ETAPI token (Trilium → Options → ETAPI) | |
| TRILIUM_SEARCH_LIMIT | No | Max notes fetched per calendar scan | 5000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| calendar_list_calendarsA | List the calendars this server exposes. Returns each calendar's |
| calendar_list_eventsA | List events, optionally filtered by date range and text. Args:
calendar_name: Calendar to read; omit to use the default calendar.
start_date: Earliest day to return, |
| calendar_get_eventA | Get one event by its uid, including its description. Args:
calendar_name: Calendar to look in; omit to search all calendars.
event_uid: The event's |
| calendar_create_eventA | Create a calendar event. Args:
title: Event title.
start_datetime: |
| calendar_update_eventA | Update an existing event. Only the arguments you pass are changed. The returned Args:
event_uid: Uid of the event to update.
calendar_name: Calendar holding the event; omit to search all calendars.
(other arguments as in calendar_create_event; |
| calendar_delete_eventB | Delete an event by uid. Deleting an unknown uid succeeds (safe retries). Args: event_uid: Uid of the event to delete. calendar_name: Calendar holding the event; omit to search all calendars. |
| calendar_get_upcoming_eventsB | List events starting between today and N days ahead. Args: calendar_name: Calendar to read; omit for all calendars. days_ahead: How many days ahead to include (today counts as day 0). limit: Maximum number of events to return. |
| calendar_upsert_eventsA | Create or update many events at once, keyed on Use this for bulk work (a release calendar for a whole season). Each
entry is created if its identity is new and updated if it already
exists, so re-running the same list updates in place instead of
duplicating. Identity comes from Args:
events: List of event objects. Each accepts the arguments of
|
| calendar_delete_eventsA | Delete many events by uid in one call. Args: event_uids: Uids to delete; unknown uids are reported, not an error. calendar_name: Calendar to delete from; omit to search all calendars. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools have clearly distinct actions (list, get, create, update, delete, upcoming, bulk upsert/delete). Slight overlap exists between calendar_get_upcoming_events and calendar_list_events with a date range, and between calendar_create_event's event_uid idempotency and calendar_upsert_events, but descriptions clarify the intended distinctions.
All nine tools follow a consistent calendar_verb_noun pattern with snake_case throughout. Verb choices (list, get, create, update, delete, upsert) are predictable and parallel, including the plural bulk variants.
Nine tools is well-scoped for a calendar server, covering single-event CRUD plus bulk operations and an upcoming shortcut without redundancy. Each tool earns its place.
Full CRUD lifecycle is covered (list, get, create, update, delete) plus bulk upsert/delete, upcoming events, and recurrence support. No obvious calendar operations are missing.