MCP Calendar Tools
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_scheduleA | List all events for a specific date from the local calendar |
| create_eventC | Create a new event in the local calendar |
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 2 tools
The two tools serve clearly distinct purposes: one reads/queries events while the other creates new ones. There is no ambiguity between them, and each has a single unambiguous responsibility.
Both tools follow a consistent verb_noun pattern (get_schedule, create_event), using snake_case throughout. Minor inconsistency exists in noun phrasing (schedule vs event) but the pattern is otherwise predictable and readable.
Two tools feels very thin for a calendar server. A calendar domain typically warrants at least update/delete operations and date-range queries, making this extremely sparse for its apparent purpose.
The surface is severely incomplete. It covers only retrieving events for a single date and creating an event, but lacks update_event, delete_event, list_all_events, searching by range, and any management capabilities. This severely limits what agents can accomplish.