Skip to main content
Glama

Nolio

by io.nolio
OverviewDiscussionsAdmin

Delete a calendar event or a template

delete_event
Destructive

Delete one event from either calendar (planned or realized workout, competition, cycle, note, quiz, applied plan) or one library template (workout, note, quiz, competition, message, exercise, plan). The id says what it is, so pass the id you read back and nothing else. Deleting an applied plan or a plan template takes its whole content with it. This operation is destructive, always confirm with the user first. One event per call, never in a loop: several deletions of planned events or templates go in one POST batch/ (dry run first). Use recurrence_action only for planned events. If a request expands to more than 3 write operations, list the computed dates/targets and get explicit confirmation before writing.

Input Schema

NameRequiredDescriptionDefault
idYesPublic id of the event to delete.
planNoPlan template id (pfr_…), only to delete an item INSIDE that plan. Without it, the same id is read as an event of the planned calendar.
groupNoGroup id (grp_…) carrying this event, for a workout planned on a whole group you manage. Omit it for an individual event. Never together with `athlete`.
athleteNoAthlete id (usr_…), required to delete an event that belongs to an athlete you coach: the same id you passed to read it. Omit it for your own events.
confirmYesTwo-step safety: must be true, and only after the user explicitly confirmed this exact deletion in the conversation.
event_typeNoOptional cross-check, the id already carries the type: "planned" for a planned-calendar event, "frame" for a library template. Omit it unless you want the call to fail when the id is not what you expect.
recurrence_actionNoOccurrences concerned: only this one, this one and following ones, or the whole series. On a read, following or all previews the occurrences (count, ids) the write would touch: state that number to the user before asking.one

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare destructiveHint=true, but the description adds what the annotations cannot: deleting an applied plan or plan template destroys its whole content, the user must confirm first, and bulk paths should be batched/dry-run. It also discloses the two-step confirm parameter's conversational precondition.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then the id-only guidance, then the destructive/confirmation constraints and batching rules. Dense but each sentence adds operational value; the long parenthetical entity enumeration is slightly bulky.

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?

Covers destruction scope, confirmation, batching, and recurrence handling — the key risks for a destructive multi-param delete. It does not mention the undo_deletion/list_recent_deletions siblings as recovery paths, which would round out the operational picture.

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 baseline is 3. The description goes beyond it by explaining that the id alone identifies type and that extra scoping params should be omitted, plus constraining recurrence_action to planned events, though it leaves the plan/group/athlete disambiguation to the schema.

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?

States a specific verb (delete) with an enumerated set of resources: one event from the planned/realized calendar or one library template, listing the concrete entity types (workout, note, quiz, competition, message, exercise, plan). This clearly separates it from siblings such as update_planned_event or create_library_category.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when/when-not rules: 'one event per call, never in a loop', several deletions go in one POST batch after a dry run, recurrence_action is only for planned events, and more than 3 writes require listing targets and explicit confirmation. An agent has a complete routing decision without inference.

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

All Nolio toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources