Skip to main content
Glama

breeze-chms

Add an event

breeze_add_event
Destructive

WRITE: create an event on the church calendar, optionally as another instance of an existing series. Times are Unix timestamps in seconds. This server cannot delete events, so a mistaken event must be removed in the Breeze app. Breeze: GET /api/events/add.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesEvent name.
all_dayNoAll-day event; only the date of starts_on is used.
ends_onNoEnd time, Unix timestamp in seconds (default: one hour after start).
event_idNoNumeric Breeze id of the existing event series to add this instance to.
starts_onYesStart time, Unix timestamp in seconds.
category_idNoNumeric Breeze id of the calendar to place the event on (default: main).
descriptionNoEvent description (HTML allowed).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only carry destructiveHint=true, so the description must supply the rest — and it does: the 'WRITE' prefix, the timestamp unit convention, and the strong constraint that the server cannot delete events, meaning a mistaken creation must be cleaned up in the Breeze app. It stops short of stating auth/permission requirements. Minor tension with destructiveHint given the create-only, non-deleting nature, but not a contradiction.

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, front-loaded with the operation type and the resource in the first clause. Every sentence carries distinct information (what it does, the series variant, the irreversible-mistake caveat).

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?

For a 7-parameter mutation with no output schema, the description covers purpose, the series option, time encoding, and the important irreversibility constraint. It lacks guidance on required permissions or which calendar defaults apply, which leaves a small gap.

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 coverage is 100%, so the baseline is 3. The description's timestamp-unit note duplicates the schema descriptions, and 'instance of an existing series' loosely maps to event_id, but it adds no format, defaulting, or constraint detail beyond structured fields.

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?

Opens with 'WRITE: create an event on the church calendar' — specific verb plus resource — and adds the series-instance variant. This clearly separates it from siblings like breeze_add_person, breeze_add_tag, and the read-side breeze_list_events/breeze_get_event.

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?

Explains the optional series-instance path ('optionally as another instance of an existing series'), which tells the agent how this differs from a standalone event creation. It also flags an operational rule (no delete on this server), but does not explicitly name alternative tools for correcting mistakes or check-before-create workflows.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.