Skip to main content
Glama
Sign In
Microsoft 365 MCP Server

Microsoft 365 MCP Server

by Softeria
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

add-calendar-event-attachment

add-calendar-event-attachment
Destructive

Add a file attachment under 3 MB to an existing calendar event so attendees can receive it. Use for small files; larger attachments require an upload session.

Instructions

Use this API to add an attachment to an existing event. This operation limits the size of the attachment you can add to under 3 MB. If an organizer adds an attachment to a meeting event, the organizer can subsequently update the event to send the attachment and update the event for each attendee as well.

šŸ’” TIP: Under 3MB only. Body requires @odata.type: {"@odata.type": "#microsoft.graph.fileAttachment", "name": "file.pdf", "contentBytes": ""}. At 3MB and above use create-calendar-event-attachment-upload-session.

Input Schema

NameRequiredDescriptionDefault
bodyYes
confirmNoFor destructive operations when the confirm gate is enabled (MS365_MCP_REQUIRE_CONFIRM=true; off by default). Set to true only after the user has explicitly approved this action. When the gate is on, calls without confirm: true return { error: "confirmation_required" } without touching user data.
eventIdYesValue for the 'eventId' path segment. Pass it under the name 'eventId', not as 'id'. Use the 'id' field of the event object as returned by Microsoft Graph.
includeHeadersNoInclude response headers (including ETag) in the response metadata
excludeResponseNoExclude the full response body and only return success or failure indication

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.176.1
    • removedInput schema / properties / body / properties / lastModifiedDateTime / description
      Removed value: -"The Timestamp type represents date and time information using ISO 8601 format and is always in UTC time. For example, midnight UTC on Jan 1, 2014 is 2014-01-01T00:00:00Z"
  2. Addedv0.166.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare that this is a non-read-only, open-world, destructive-capable mutation. The description adds important behavioral context beyond annotations: the 3 MB size cap and the organizer's ability to later update the event so attendees receive the attachment. It does not discuss the confirm gate or auth/permission nuances, but the schema covers confirm.

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 description is short and front-loads the core action and size limit. The size cap is repeated in the TIP section, which is slightly redundant but still useful because that section also contains the exact body format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nested-body mutation with no output schema, the description covers the key operational details: size limit, body shape, and the large-attachment alternative. It omits return behavior and confirmation-gate behavior, but the confirm parameter is well documented in the schema.

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 high at 80%, so most parameters are already documented. The description adds critical meaning not present in the schema: the body must include @odata.type set to #microsoft.graph.fileAttachment and contentBytes as base64, which is essential for correct invocation.

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 description states a specific verb and resource: add an attachment to an existing calendar event. It also explicitly distinguishes the small-attachment path from the upload-session sibling for attachments of 3 MB and above.

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 a clear usage condition: under 3 MB use this tool, and at 3 MB or above use create-calendar-event-attachment-upload-session. This directly routes the agent to the correct sibling without needing to infer limits from the schema.

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

Deploy Server

Other Tools