killbottleneck-mcp

Official

Overview Schema Source Related Servers Discussions Admin

create_events

Create multiple calendar events at once for schedules, seminars, or training plans, with all-or-nothing validation and duplicate skipping.

Instructions

Create SEVERAL calendar events at once — e.g. every date of a lecture schedule, a seminar invitation or a training plan ("every Tuesday until January" = list each date). All or nothing: when one item is invalid nothing is written and the error names the item. An event that is already in the calendar (same title, day and time) is skipped and reported. calendar, participants and remind_before_min apply to all items. Max 30 items; time off goes one by one via create_event.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "create_events"
  }
}

Input Schema

Name	Required	Description
`items`	Yes
`calendar`	No	name or id of a shared calendar for all items; omit = personal
`participants`	No	e-mails of instance members invited to all items
`remind_before_min`	No	reminder N minutes before each start

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.1Nov 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations present, the description carries the full burden and does so: it declares all-or-nothing atomicity, that the error names the offending item, that duplicates (same title, day and time) are silently skipped and reported, and the 30-item ceiling. These are exactly the write-safety and side-effect facts an agent needs before calling a mutation tool.

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?

Four tightly packed sentences, front-loaded with the batch scope, then constraints, then the sibling alternative. No filler; the quoted example clarifies the enumeration requirement efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batched mutation tool with no annotations and no output schema, the description covers atomicity, dedup/skip reporting, item limit, shared-field scope, and the alternative for singles. Nothing essential to correct invocation is missing.

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 75%, so field-level meanings are largely documented already; the description's value-add is stating that calendar, participants and remind_before_min apply uniformly to every item, which the schema's property descriptions do not convey. It does not add format hints for the nested item fields, but those are already covered in 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?

The description leads with a specific verb and resource ("Create SEVERAL calendar events at once") and immediately contrasts with the singular sibling ("time off goes one by one via create_event"). The batch scope plus concrete examples (lecture schedule, seminar invitation, training plan) make the tool's identity unambiguous.

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?

It names concrete when-to-use scenarios (recurring dates that must be enumerated) and gives an explicit when-not plus alternative: single time-off entries go through create_event one by one. An agent can route between the two tools without further inference.

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