Agent Mail Gateway

Send a new calendar invitation

create_event

Create a meeting and send calendar invitations to the attendees (all on allow_send_to); it appears in Outlook, Gmail and Apple Calendar.

Instructions

Create a meeting and send calendar invitations to the attendees (all on allow_send_to); it appears in Outlook, Gmail and Apple Calendar. Remember the returned id: to change or cancel the meeting use update_event or cancel_event, never create a second one. Times without offset are read in timezone or the mailbox time zone; for all-day events (holidays, absences) set all_day and give dates, and show_as free keeps calendars free; the invitation is reviewed and counts towards the send limit. Returns the event with id, UTC and local times.

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": {
      "title": "<title>",
      "start": "<start>",
      "attendees": "<attendees>"
    },
    "name": "create_event"
  }
}

Input Schema

Name	Required	Description
`end`	No	End, same format as start and after it; for all_day the last day (inclusive, defaults to start)
`start`	Yes	Start, e.g. 2026-10-05T14:00 (mailbox time zone) or with offset/Z; for all_day a date like 2026-10-05
`title`	Yes	Meeting title shown in calendars
`all_day`	No	true: all-day event over whole days; start and end are dates. Default false
`show_as`	No	How the time shows in attendees' calendars: busy (default), free, tentative or oof (out of office)
`location`	No	Place or meeting link
`timezone`	No	IANA zone for times without offset; defaults to the mailbox timezone
`attendees`	Yes	Email addresses to invite; each must be on allow_send_to
`description_markdown`	No	Agenda or notes in Markdown

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.5.0Oct 22, 2026

addedInput schema / properties / all_day

Added value: +{
+  "description": "true: all-day event over whole days; start and end are dates. Default false",
+  "type": "boolean"
+}

addedInput schema / properties / end / anyOf

Added value: +[
+  {
+    "format": "date",
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+    "type": "string"
+  },
+  {
+    "pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}(:\\d{2}(\\.\\d+)?)?(Z|[+-]\\d{2}:\\d{2})?$",
+    "type": "string"
+  }
+]

changedInput schema / properties / end / description

Previous value: -"End, same format as start; must be after start"New value: +"End, same format as start and after it; for all_day the last day (inclusive, defaults to start)"

removedInput schema / properties / end / pattern

Removed value: -"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}(:\\d{2}(\\.\\d+)?)?(Z|[+-]\\d{2}:\\d{2})?$"

removedInput schema / properties / end / type
```
Removed value: -"string"
```

addedInput schema / properties / show_as

Added value: +{
+  "description": "How the time shows in attendees' calendars: busy (default), free, tentative or oof (out of office)",
+  "enum": [
+    "busy",
+    "free",
+    "tentative",
+    "oof"
+  ],
+  "type": "string"
+}

addedInput schema / properties / start / anyOf

Added value: +[
+  {
+    "format": "date",
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+    "type": "string"
+  },
+  {
+    "pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}(:\\d{2}(\\.\\d+)?)?(Z|[+-]\\d{2}:\\d{2})?$",
+    "type": "string"
+  }
+]

changedInput schema / properties / start / description

Previous value: -"Start, e.g. 2026-10-05T14:00 (mailbox time zone) or with offset/Z"New value: +"Start, e.g. 2026-10-05T14:00 (mailbox time zone) or with offset/Z; for all_day a date like 2026-10-05"

removedInput schema / properties / start / pattern

Removed value: -"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}(:\\d{2}(\\.\\d+)?)?(Z|[+-]\\d{2}:\\d{2})?$"

removedInput schema / properties / start / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "title",
-  "start",
-  "end",
-  "attendees"
-]New value: +[
+  "title",
+  "start",
+  "attendees"
+]

Changed7 schema fields changedv0.3.2Oct 3, 2026
- addedInput schema / properties / attendees / description
```
Added value: +"Email addresses to invite; each must be on allow_send_to"
```
- addedInput schema / properties / description_markdown / description
```
Added value: +"Agenda or notes in Markdown"
```
- addedInput schema / properties / description_markdown / maxLength
```
Added value: +512000
```
- addedInput schema / properties / end / description
```
Added value: +"End, same format as start; must be after start"
```
- addedInput schema / properties / location / description
```
Added value: +"Place or meeting link"
```
- addedInput schema / properties / start / description
```
Added value: +"Start, e.g. 2026-10-05T14:00 (mailbox time zone) or with offset/Z"
```
- addedInput schema / properties / title / description
```
Added value: +"Meeting title shown in calendars"
```
First observedv0.1.0Oct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations by disclosing that attendees must be on allow_send_to, that the invitation is reviewed and counts toward the send limit, that it lands in Outlook/Gmail/Apple, and how offset-less times are resolved against timezone. These are exactly the side effects and constraints an agent needs before an openWorld, non-idempotent mutation.

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?

The critical facts (create, invite, reuse via update_event, return id) are front-loaded in the first two sentences. The remainder is one dense semicolon chain, which is efficient but slightly run-on compared with a clean bullet structure.

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?

With no output schema, the description usefully states the return shape ('the event with id, UTC and local times'), and covers the identity/allow-list, send-limit and timezone prerequisites. Nothing needed 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 baseline is 3; the description adds interpretation by tying timezone/default behavior to offset-less times and pairing all_day with date-only start/end. Much of this echoes the schema, so it is reinforcement rather than new information.

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 ('Create a meeting and send calendar invitations') and immediately distinguishes itself from siblings update_event and cancel_event. An agent can tell exactly what this does and what it is not for without opening the 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 routes the agent: use update_event or cancel_event for later changes and 'never create a second one'. It also gives conditional guidance for all-day events and for free/tentative show_as, naming the concrete cases (holidays, absences).

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

Deploy Server