Turbo Notify: WhatsApp for AI agents

Send a calendar event

send_calendar_event

Send a calendar event invitation.

Set exactly one recipient: number, group_id, or contact_id.

start_at and end_at are ISO 8601 with an offset, for example 2026-09-10T14:00:00Z. A timestamp without one is rejected: the recipient's phone renders the event in their own timezone, so an ambiguous instant would show the wrong hour on their screen.

When set, end_at must be after start_at; an event that ends before (or exactly when) it starts is rejected.

location pins where it happens (latitude and longitude, with an optional name and address). has_reminder reminds guests, and reminder_offset_sec says how many seconds before the event; extra_guests_allowed lets guests bring extra people.

To fix a mistake later (a typo, the description, a link), use edit_calendar_event: guests keep their answer. When the date, time or place change and guests must accept again, cancel the event with cancel_calendar_event and send a new one with this tool. The entry a guest added to their own calendar with the card's "Add to calendar" button never follows an edit or a cancel: it stays on the old date and adding again creates a second entry, so tell guests to delete the old one. To see who said they are coming, use get_message_responses.

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`.
`number`	No	Recipient phone number in E.164 form, digits only, country code first (e.g. `5511999999999`). Set exactly one of `number`, `group_id` or `contact_id`.
`group_id`	No	Recipient group id (`grp_…`), from `list_groups`. A group id belongs to one number: an id from one inbox does not address the same group in another. Set exactly one of `number`, `group_id` or `contact_id`. Addressing a group needs a plan that includes group messaging: without it the call answers `payment_required: feature_not_available`, and retrying will not change that.
`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.
`contact_id`	No	Recipient contact id (`ct_…`), from `list_contacts`. A contact id belongs to one number: an id from one inbox does not address the same person in another. Set exactly one of `number`, `group_id` or `contact_id`.
`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
`idempotency_key`	No	Any printable ASCII text you choose, 1 to 255 characters, for example the id of the event you are answering. Reusing it for the same number suppresses a duplicate if you retry. Without it, retrying after a timeout may deliver the message twice, and the recipient sees both.
`quoted_message_id`	No	Quote an earlier message (`msg_…`) so it appears above yours. Do this only when your text depends on something said a while ago, yours or theirs; do not quote the message you are answering right now, send a normal message instead.
`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.6/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false) it discloses real validation behavior: exactly one recipient, offsetless timestamps rejected, end_at must be strictly after start_at. It also warns of a non-obvious side effect the annotations cannot express — a guest's own 'Add to calendar' entry never follows an edit or cancel and re-adding duplicates it. Missing only delivery/response behavior, which the output schema covers.

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 purpose, then recipient, then timing, then location/reminder, then sibling routing — a sensible order with short paragraphs and backticked field names. Some content duplicates the schema's own parameter descriptions, so it is slightly longer than strictly necessary.

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 15-parameter mutation tool with an output schema, the description covers the risky decisions an agent must make: recipient exclusivity, timestamp offset, ordering, and the edit-versus-cancel fork. Return values are handled by the output schema, so nothing essential is left out.

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 description coverage is 100%, so a 3 is the floor; the description still adds the why behind the offset requirement (the recipient's phone renders in its own timezone, so an ambiguous instant shows the wrong hour). It restates a few rules already present in the schema (reminder_offset_sec, location pin), which caps it below 5.

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 opening line names a specific verb and resource ('Send a calendar event invitation') and the description immediately positions it against cancel_calendar_event and edit_calendar_event. An agent can tell this apart from the other event tools 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?

It gives explicit routing rules: use edit_calendar_event for typos/description/link fixes, but cancel and re-send when date, time or place change so guests must re-accept. It also points to get_message_responses for RSVPs, so each alternative tool is tied to a concrete condition.

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.