Turbo Notify: WhatsApp for AI agents

Edit a calendar event already sent

edit_calendar_event

Destructive

Correct a calendar event this number already sent.

name and start_at are always required, plus whatever else the event has: description, end_at, join_link, location, has_reminder with reminder_offset_sec, and extra_guests_allowed. This REPLACES the whole event: anything you leave out is removed from it, including its location, reminder and guest setting, so send again every detail you want to keep. The event keeps its place in the chat and the guests keep the answer they already gave.

Use an edit to fix a mistake (a typo, the description, a link). When the date, time or place change and the guests must accept again, do not edit: cancel the event with cancel_calendar_event and send a new one with send_calendar_event, because the old answer does not carry over to a new event. Neither an edit nor a cancel changes the entry a guest already added to their own calendar with the card's "Add to calendar" button. It stays on the old date, and adding again creates a second entry, which only the guest can delete.

Only a calendar event can be edited here. Using this tool on any other message answers invalid_request: message_not_editable.

Only a message sent THROUGH Turbo Notify can be edited. One typed on the phone itself belongs to the same number but cannot be edited here, and neither can a message received from someone else.

The 15-minute limit does not apply to a calendar event.

The edit is accepted at once and the outcome arrives as an event: message.edited when it worked, message.edit.failed when WhatsApp or the platform could not apply it. Read them with list_events.

The number first appears online and its unread messages in that conversation are marked as read, then the edit happens. Opening the conversation this way is automatic and uses no quota of its own.

Input Schema

Name	Required	Description	Default
`name`	Yes	The event's title, up to 200 characters.
`end_at`	No	When the event ends. ISO 8601 with an offset, and later than `start_at`.
`location`	No	Where the event takes place: a map pin with an optional name and address.
`start_at`	Yes	When the event starts. ISO 8601 with an offset, for example `2026-09-10T14:00:00Z`. A time without an offset is rejected.
`join_link`	No	A link guests can open to join, for example a video call.
`message_id`	Yes	Message id (`msg_…`), as returned by a send or by `list_messages`.
`description`	No	Details shown on the event, up to 2000 characters.
`has_reminder`	No	Set to true to remind guests before the event. Off when left out.
`number_alias`	No	Which of the organization's WhatsApp numbers this acts on: `main`, the alias of an extra number, or the number's `id` (`num_…`), which stays the same when the alias is renamed. Call `list_numbers` to see them. Defaults to the main number.	main
`reminder_offset_sec`	No	How many seconds before the event the reminder goes off, for example 600 for ten minutes. Only takes effect together with `has_reminder`.
`extra_guests_allowed`	No	Set to true to let guests bring extra people. Off when left out.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and non-idempotency, but the description adds far more: the edit is a full replacement that silently drops omitted fields, guests keep their prior answers, the guest's own 'Add to calendar' entry is not updated, and the 15-minute edit limit does not apply. It also discloses the async outcome events (message.edited / message.edit.failed) and the exact error for ineligible messages.

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 core action and the replacement rule, then decision guidance, then edge cases. Dense and mostly waste-free, though the closing paragraph about the number coming online and unread messages is tangential to the edit itself and slightly dilutes focus.

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 destructive, async, 11-parameter mutation with rich sibling overlap, the description covers eligibility, replacement semantics, guest-side side effects, error behavior and result delivery. The return shape is covered by the output schema, so nothing an agent needs is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the description contributes semantics the schema cannot express: name and start_at are always required, and because the operation REPLACES the whole event, every optional field omitted is removed — so callers must resend all desired details. That materially changes how the 11 parameters are used.

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 and resource ("Correct a calendar event this number already sent") and clearly delineates it from edit_text_message, edit_media_caption, send_calendar_event and cancel_calendar_event, the latter two named explicitly. An agent can route correctly from the first line alone.

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 an explicit decision rule: use an edit for a typo, description or link fix; use cancel plus send when the date, time or place change so guests must re-accept. Also names the exclusion cases (non-calendar messages, messages typed on the phone, received messages) and the sibling tools to use instead.

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

All Turbo Notify: WhatsApp for AI agents 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.