Skip to main content
Glama
hhopke
by hhopke

Icu Duplicate Events

icu_duplicate_events

Duplicate existing calendar events forward by a set number of weeks and create multiple copies, letting you repeat workouts on future dates without rebuilding each event.

Instructions

COPY existing events forward in time by N weeks.

Use when the user says "repeat this workout for the next 4 weeks", "duplicate Monday's run on the next 3 Mondays". Reuses the existing events' payloads — different from icu_create_event / icu_bulk_create_events, which both build NEW events from scratch.

Input Schema

NameRequiredDescriptionDefault
event_idsYesJSON array of event IDs to duplicate (e.g., '[123, 456]')
athlete_idNoAthlete ID (for coaches managing multiple athletes)
num_copiesNoNumber of copies to create
weeks_betweenNoWeeks between each copy

Output Schema

NameRequiredDescriptionDefault
resultYes

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: copies reuse the source payloads rather than constructing new ones. It stops short of saying what happens if an event already exists on a target date, or how partial failures across a multi-ID input are handled.

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 short sentences, all front-loaded: the operation first, then when to use it, then the disambiguation. No filler and nothing that repeats structured fields verbatim.

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?

With an output schema present, return values need no explanation, and the mutation semantics are covered by annotations plus the payload-reuse note. The one residual gap is collision/overwrite behavior when a copy lands on a date that already has an event, which matters for a non-idempotent write tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so event_ids, athlete_id, num_copies, and weeks_between are already documented. The "N weeks" and "next 4 weeks / next 3 Mondays" examples loosely illustrate weeks_between and num_copies, but they do not add precision beyond the schema defaults.

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?

"COPY existing events forward in time by N weeks" gives a specific verb (copy/duplicate), the resource (existing events), and the transformation (shift forward by weeks). It explicitly distinguishes itself from icu_create_event and icu_bulk_create_events, both of which appear in the sibling list.

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?

Provides two concrete user phrasings that should trigger the tool ("repeat this workout for the next 4 weeks", "duplicate Monday's run on the next 3 Mondays") and names the alternative tools with the condition that separates them (reuse existing payloads vs build new events).

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

Deploy Server

Other Tools