Skip to main content
Glama
marlonluo2018

Microsoft Graph MCP Server

manage_event_as_attendee

Respond to invitations for events organized by others: accept, decline, tentatively accept, propose new time, delete cancelled events, or email attendees.

Instructions

Manage calendar events where you are an attendee (events organized by others). Actions: accept, decline, tentatively_accept, propose_new_time, delete_cancelled, email_attendees. WORKFLOW: Use cache_number from browse_events or search_events results. Returns: Response confirmation message with action status and updated event information. Note: If event is already responded to, returns appropriate error message. IMPORTANT: accept/decline/tentatively_accept/propose_new_time actions will automatically handle events where the organizer didn't request responses. For accept: updates the event to showAs='busy' and enables reminders. For tentatively_accept: updates the event to showAs='tentative' and enables reminders. For decline: deletes the event from your calendar. For propose_new_time: deletes the event from your calendar and instructs you to contact organizer directly (since proposals require responses). This matches Outlook's behavior. The delete_cancelled action is specifically for removing a CANCELLED event from your calendar (ONLY use when organizer has cancelled the event - do NOT use to decline invitations). The email_attendees action sends email to event attendees (to=required attendees, cc=optional attendees, organizer excluded from recipients).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoList of 'cc' recipient email addresses for email_attendees action (optional, defaults to optional event attendees)
toNoList of 'to' recipient email addresses for email_attendees action (optional, defaults to required event attendees)
bodyNoEmail body content for email_attendees action (optional, defaults to event body content)
actionYesAction to perform: 'accept' to accept event invitation, 'decline' to decline event invitation, 'tentatively_accept' to tentatively accept event invitation, 'propose_new_time' to decline and propose new time to organizer (if responses aren't requested, deletes the event and instructs to contact organizer directly), 'delete_cancelled' to remove a CANCELLED event from your calendar (ONLY use when organizer has cancelled the event - do NOT use to decline invitations), 'email_attendees' to send email to event attendees (to=required attendees, cc=optional attendees, organizer excluded from recipients)
seriesNoFor accept/decline/tentatively_accept actions on recurring events: set to true to accept/decline entire series, or false (default) for single occurrence only
commentNoOptional comment for accept, decline, tentatively_accept, propose_new_time actions
cache_numberYesCache number from browse_events or search_events (required for all actions, e.g., 1, 2, 3)
email_subjectNoEmail subject for email_attendees action (optional, default: 'Re: Event')
send_responseNoWhether to send response to organizer for accept, decline, tentatively_accept actions (optional, default: true)
propose_new_timeNoPropose a new time when using propose_new_time action (required for propose_new_time action). Note: If the organizer hasn't requested responses, the event will be deleted and you'll need to contact the organizer directly to suggest the new time.
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: automatic handling for events without response requests, specific effects for each action (e.g., 'updates the event to showAs='busy''), and error behavior for already responded events. No contradictions.

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 long but well-structured with sections, bullet points, and important notes. It front-loads purpose and action list. Every sentence adds value, though slight conciseness improvements could be made without losing clarity.

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?

Given the complexity (10 parameters, multiple actions, no output schema), the description covers workflow, action effects, parameter usage, error conditions, and return value information. It is comprehensive for an AI agent to correctly invoke the tool.

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 baseline is 3. The description adds value by explaining workflow (e.g., cache_number usage) and clarifying propose_new_time behavior, but does not significantly exceed schema-level detail.

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 clearly states it manages calendar events where the user is an attendee. It lists specific actions and distinguishes from 'manage_event_as_organizer' sibling. The phrase 'events organized by others' makes the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides workflow instructions (use cache_number from browse_events or search_events) and explains when to use each action, including specific warnings like 'do NOT use delete_cancelled to decline invitations'. It lacks explicit alternative tool guidance but the context of 'as an attendee' implies differentiation.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/marlonluo2018/microsoft_graph_mcp_server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server