Skip to main content
Glama

m365_calendar_create

Create calendar events in a default or selected mailbox calendar, optionally as Teams meetings; include attendees to send invitations or omit them for a personal appointment.

Instructions

Create a new event in your default or selected mailbox calendar, optionally as a Teams meeting. Supplying attendees sends invitation emails; omit them for a personal appointment. Use m365_calendar_update to edit an event or m365_calendar_availability to check free/busy first. Returns the event ID and available links. Repeated calls can create duplicate events; check m365_calendar_list before resubmitting after an uncertain outcome.

Input Schema

NameRequiredDescriptionDefault
endYesEnd date-time (ISO 8601), using the same timezone conventions as start
bodyNoEvent notes; HTML by default
startYesStart date-time (ISO 8601); omit the offset to use the configured timezone, or include Z/an offset for an exact instant
subjectYesEvent title
isOnlineNoCreate a Teams meeting when true; requires Teams support in the selected calendar
locationNoEvent location
attendeesNoComma-separated email addresses; supplying attendees sends meeting invitations
calendarIdNoOptional ID of a calendar in your mailbox; omit for the default calendar. Does not grant shared-calendar access
bodyContentTypeNoFormat of the supplied bodyhtml

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.2.1
    • changedInput schema / properties / attendees / description
      Previous value: -"Attendee emails, comma-separated"New value: +"Comma-separated email addresses; supplying attendees sends meeting invitations"
    • changedInput schema / properties / calendarId / description
      Previous value: -"Optional calendar ID; omit for the default calendar"New value: +"Optional ID of a calendar in your mailbox; omit for the default calendar. Does not grant shared-calendar access"
    • changedInput schema / properties / end / description
      Previous value: -"End datetime (ISO 8601)"New value: +"End date-time (ISO 8601), using the same timezone conventions as start"
    • changedInput schema / properties / isOnline / description
      Previous value: -"Create as Teams meeting"New value: +"Create a Teams meeting when true; requires Teams support in the selected calendar"
    • changedInput schema / properties / start / description
      Previous value: -"Start datetime (ISO 8601)"New value: +"Start date-time (ISO 8601); omit the offset to use the configured timezone, or include Z/an offset for an exact instant"
  2. Changed3 schema fields changedv1.2.0
    • changedInput schema / properties / body / description
      Previous value: -"Event description (HTML)"New value: +"Event notes; HTML by default"
    • addedInput schema / properties / bodyContentType
      Added value: +{
      +  "default": "html",
      +  "description": "Format of the supplied body",
      +  "enum": [
      +    "text",
      +    "html"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / calendarId
      Added value: +{
      +  "description": "Optional calendar ID; omit for the default calendar",
      +  "minLength": 1,
      +  "type": "string"
      +}
  3. First observedv1.0.7

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly=false, openWorld=true and idempotentHint=false; the description goes beyond them by explaining the concrete side effect (attendee emails are sent), the Teams dependency for isOnline, the non-idempotent duplicate-event risk, and the return payload. That is exactly the extra context annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, each carrying distinct information: purpose, attendee branching, sibling routing, and failure recovery. The most decision-critical content (what it creates, what it sends) is front-loaded with no filler.

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 9-parameter mutation tool with no output schema, the description still covers the return value ('event ID and available links'), the invitation side effect, the duplicate risk, and the alternatives. Nothing an agent needs in order to call this safely is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all nine parameters, including the timezone conventions for start/end and the calendarId shared-access caveat. The description adds only light framing ('personal appointment', 'optionally as a Teams meeting') beyond what the schema states, so the baseline of 3 applies.

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 new event ... in your default or selected mailbox calendar') and immediately names its distinguishing modifier ('optionally as a Teams meeting'). An agent can separate it from m365_calendar_update, m365_calendar_cancel and m365_calendar_list 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?

Gives explicit routing rules: 'Use m365_calendar_update to edit an event or m365_calendar_availability to check free/busy first', plus a recovery procedure ('check m365_calendar_list before resubmitting after an uncertain outcome'). It also states the branch condition that changes behavior (supply attendees vs. omit them).

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