Skip to main content
Glama

event_delete

Destructive

Remove a calendar event by artist or title. If multiple events match, it lists them numbered and asks you to confirm which one to delete by picking a number.

Instructions

Delete one calendar event by artist or title. When several match, the tool lists them with numbers and asks the user; when the user answers with a number, call this again with pick set to that number. If the result starts with NO_REPLY, answer exactly NO_REPLY.

Input Schema

NameRequiredDescriptionDefault
dateNoDay of the event as YYYY-MM-DD when known.
pickNoAfter the tool listed numbered matches and the user answered with a number, pass that number here, e.g. "2", and leave title empty.
titleNoArtist or event title to remove, e.g. "Zed Fox".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

destructiveHint=true already flags the write; the description adds behavior annotations can't express — the multi-turn disambiguation loop and the contract that a NO_REPLY-prefixed result must be answered exactly NO_REPLY. It doesn't state whether deletion is permanent or requires confirmation, which is the remaining 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?

Three sentences, zero filler, with the core action front-loaded and the flow and sentinel rules following in priority order.

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?

No output schema exists, and the description covers the two result shapes that matter (numbered match listing and NO_REPLY sentinel). It leaves unstated what a successful deletion returns, a minor omission for a 3-param tool.

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 coverage is 100%, so the baseline is 3, but the description adds workflow meaning the schema lacks: pick only makes sense on a re-invocation after a numbered listing. That relational timing is the real added value.

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?

Uses a specific verb and resource ("Delete one calendar event") and states the lookup key (artist or title). An agent can distinguish it from calendar_add and concert_add without reading any schema.

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?

Gives an explicit procedural condition: when several matches exist the tool lists them numbered and asks the user, and the follow-up call must pass that number as pick. It doesn't name alternatives or say when not to use it, which keeps it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.