Turbo Notify: WhatsApp for AI agents

Cancel a calendar event already sent

cancel_calendar_event

Destructive

Cancel a calendar event this number already sent.

The event stays in the chat marked as canceled, and WhatsApp tells the guests. Send the same name and start_at the event has, plus the details you want the canceled card to still show (description, end_at, join_link, location, has_reminder with reminder_offset_sec, extra_guests_allowed): the canceled event is shown with what you send here, and anything you leave out disappears from it.

Cancel when the date, time or place change and the guests must accept again: cancel the old event here, then send the new one with send_calendar_event, because the old answer does not carry over to a new event. To correct a mistake (a typo, the description, a link) use edit_calendar_event instead, and the guests keep their answer. A cancel does not change 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 canceled. Using this tool on any other message answers invalid_request: message_not_editable; to take back a message of another kind, use delete_message.

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

The 15-minute limit for a text or a caption does not apply to a calendar event.

The cancel 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 cancel 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.8/5.0

Behavior5/5

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

Far beyond the annotations, it discloses that the card stays in the chat marked canceled, that WhatsApp notifies guests, that omitted fields disappear from the canceled card, and that a guest's own 'Add to calendar' entry is not updated and re-adding duplicates it. It also names the failure mode (`invalid_request: message_not_editable`), the eligibility limits (only messages sent through Turbo Notify), and the asynchronous outcome events (`message.edited` / `message.edit.failed`) readable via `list_events`. The side effect of bringing the number online and marking unread messages as read is a genuinely non-obvious behavior worth surfacing.

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 required-field rule, then layered by concern (alternatives, guest-calendar caveat, error cases, async outcome). It is long, and the closing paragraph on going online / unread messages is somewhat tangential, but nearly every sentence carries operational information for a destructive, non-idempotent operation.

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 an 11-parameter destructive mutation with an output schema, the description covers the omission semantics, eligibility restrictions, error code, async completion path, and downstream effects on guest calendars. Nothing an agent needs to call this 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 100%, so the baseline is 3, but the description adds meaning the schema does not: `name` and `start_at` must match the existing event, and the optional fields must be resent because anything left out disappears from the canceled card. That re-send semantic is the key invocation detail an agent could otherwise get wrong.

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 a specific verb and resource ('Cancel a calendar event this number already sent') plus the scope constraint that it must be a message this number sent. It is immediately distinguishable from edit_calendar_event and delete_message, both of which are named explicitly.

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 explicit when-to-use ('Cancel when the date, time or place change and the guests must accept again'), explicit when-not ('To correct a mistake (a typo, the description, a link) use `edit_calendar_event` instead'), and an alternative for non-calendar messages (`delete_message`). The cancel-then-resend workflow with `send_calendar_event` is spelled out with its rationale.

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.