Prubex

Change an event

calendar_update_event

Destructive

Changes an event: only the fields you pass change, and moving start alone keeps the duration. Use it to reschedule or edit an event, or to add or remove attendees (add_attendees, remove_attendees; everyone else stays). An occurrence's event_id changes that occurrence only; to change the whole series, pass the occurrence's series_id as event_id. Attendees are sent the update. If is_organizer is false, ask the organiser for a new time with calendar_respond_to_event (proposed_start) instead. It can return pending_approval: tell the user a person must approve it in Prubex, and do not retry. Times are ISO 8601: with an offset (2026-11-02T09:00:00+02:00), or without one to mean time_zone; all-day events use dates, and their end is the day after the last day. Example: { "event_id": "evt_…", "start": "2026-11-03T11:00:00+02:00" }.

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": {
      "event_id": "<event_id>"
    },
    "name": "calendar_update_event"
  }
}

Input Schema

Name	Required	Description
`end`	No	ISO 8601 date-time (with an offset, or local to `time_zone`), or YYYY-MM-DD for all-day events.
`start`	No	ISO 8601 date-time (with an offset, or local to `time_zone`), or YYYY-MM-DD for all-day events.
`title`	No	A new title.
`all_day`	No	Make it an all-day event, or not.
`event_id`	Yes	An event id (`evt_…`) from calendar_list_events, or an occurrence’s `series_id` to act on the whole series.
`location`	No	A new location.
`time_zone`	No	IANA time zone for dates in and out, e.g. "Africa/Johannesburg". Defaults to the workspace time zone, which prubex_overview returns as `time_zone`.
`description`	No	New notes.
`add_attendees`	No	People to invite as well.
`idempotency_key`	No	Any unique string. Retrying with the same key within 24 h never repeats the action.
`remove_attendees`	No	Addresses to remove; they are told.

Output Schema

Name	Required	Description
`event`	No
`status`	Yes
`message`	Yes	What happened, in words for the user.
`warnings`	No	Accounts that failed or timed out; results from the others are still here.
`account_id`	Yes
`expires_at`	No	When held: when the request expires.
`review_url`	No	When held: where a person approves it in Prubex.
`approval_id`	No	When held: pass it to approvals_get later.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only flag destructive/openWorld/non-idempotent; the description goes well beyond by stating that unpassed fields are untouched, that moving `start` alone preserves duration, that attendees are notified, and that `pending_approval` must not be retried. The approval/notification consequences are exactly the kind of behavior an agent cannot infer from structured fields.

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 the most decision-relevant rule and every sentence carries information, including a concrete example payload. It is delivered as one dense paragraph with heavy parentheticals, which costs a little parseability but wastes no words.

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?

An output schema and full annotations already cover return shape and safety profile, and the description still supplies the non-structural essentials: partial-update semantics, series vs occurrence targeting, attendee notifications, the approval dead-end, and time-format rules. Nothing an agent needs to invoke it correctly 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 already 100%, so the baseline is 3; the description adds genuinely non-derivable meaning — duration preservation when only `start` is sent, the all-day rule that `end` is the day after the last day, and offset-vs-`time_zone` resolution. It does not address how a field is cleared (empty string vs null), which is the one open ambiguity for a partial-update tool.

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?

"Changes an event: only the fields you pass change" gives a specific verb, resource, and the crucial partial-update semantic in one clause. It is immediately distinguishable from calendar_create_event, calendar_delete_event, and calendar_get_event without opening 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 Guidelines5/5

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

Explicitly names the use cases (reschedule, edit, add/remove attendees) and routes the agent away from this tool when `is_organizer` is false, pointing at calendar_respond_to_event with `proposed_start`. It also disambiguates occurrence vs series via `event_id` vs `series_id`, leaving nothing to inference.

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

All Prubex tools Inspect

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

Need Help?