Remove a Google Calendar event by ID, optionally choosing the calendar and update notifications. Use it to cancel or clean up events via AI assistants.
Delete an event by id.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | ||
| calendar_id | No | primary | |
| send_updates | No | none |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for a destructive mutation and falls short. It never states that deletion is permanent/irreversible, what permissions are needed, whether notifications are sent, or what the response contains.
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?
A single well-formed sentence with the action front-loaded, but it is under-specified rather than concise. Every word earns its place, yet there is too little information for a 3-parameter destructive tool.
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 zero annotations, zero schema descriptions, a destructive operation, and an enum parameter governing attendee notifications, the definition is materially incomplete. An agent cannot determine notification side effects or safety requirements before calling it.
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 0% and the description only covers event_id ('by id'). The calendar_id parameter with its 'primary' default and the send_updates enum (all/externalOnly/none, default none) are left entirely unexplained in both description and 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?
States a specific verb (Delete) and resource (event), with the lookup key (id) identified. It is distinguishable from siblings create_event/update_event/get_event/list_events by the verb alone, though it does not explicitly contrast itself with any of 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 versus update_event or when deletion is appropriate, no prerequisites, no warnings about irreversibility. The only usage signal is the implicit 'by id' lookup requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.