Skip to main content
Glama

Accept or decline an invitation

calendar_respond_to_event
Destructive

Answers a meeting invitation: accept, tentative or decline. Use it once the user has decided; to reschedule a meeting this account organises, use calendar_update_event. With tentative or decline you can propose another time by passing both proposed_start and proposed_end, on Microsoft accounts only (elsewhere it answers PROVIDER_UNSUPPORTED: suggest the time in comment instead). If the event's allows_new_time_proposals is false (the organiser turned proposals off), a proposal answers INVALID_INPUT: answer without it and suggest the time in comment. A comment or a proposed time is sent to the organiser, so either one makes the answer a send. It can return pending_approval: tell the user a person must approve it in Prubex, and do not retry. An answer with neither is never held. On Microsoft, declining also removes the event from the user's calendar. Example: { "event_id": "evt_…", "response": "accept" }.

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": {
      "event_id": "<event_id>",
      "response": "<response>"
    },
    "name": "calendar_respond_to_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
commentNoA note to the organiser (counts as a send).
event_idYesAn event id (`evt_…`) from calendar_list_events, or an occurrence’s `series_id` to act on the whole series.
responseYesThe answer.
time_zoneNoIANA time zone for dates in and out, e.g. "Africa/Johannesburg". Defaults to the workspace time zone, which prubex_overview returns as `time_zone`.
proposed_endNoThe end of the proposed time, after proposed_start, in the same format. Pass both or neither.
proposed_startNoWith tentative or decline, on Microsoft accounts: the start of the time you propose instead, an ISO 8601 date-time (with an offset, or local to `time_zone`). Pass proposed_end too. Counts as a send.
idempotency_keyNoAny unique string. Retrying with the same key within 24 h never repeats the action.

Output Schema

NameRequiredDescriptionDefault
eventNo
statusYes
messageYesWhat happened, in words for the user.
warningsNoAccounts that failed or timed out; results from the others are still here.
account_idYes
expires_atNoWhen held: when the request expires.
review_urlNoWhen held: where a person approves it in Prubex.
approval_idNoWhen held: pass it to approvals_get later.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds substantial context the annotations cannot convey: a comment or proposal is delivered to the organiser and makes the answer a send, decline removes the event from the Microsoft calendar, and `pending_approval` must be surfaced to the user with no retry. These are exactly the operational facts an agent needs before invoking a destructive, 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?

Front-loaded with purpose and the sibling contrast, then layered constraints, then a compact example. It is dense and runs long for a single tool, but nearly every clause carries an actionable failure mode or side effect rather than 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 7-parameter destructive mutation with an output schema present, the description covers the error paths (PROVIDER_UNSUPPORTED, INVALID_INPUT, pending_approval), the side effects, and the approval workflow. Nothing an agent needs to call it correctly or handle its response 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 100%, so the baseline is 3; the description goes beyond by explaining that `comment` and a proposed time both count as a send and that proposed_start/proposed_end must be passed together and only on Microsoft. It says nothing extra about `time_zone` or `idempotency_key`, which remain schema-only.

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?

Opens with a specific verb+resource: 'Answers a meeting invitation: accept, tentative or decline.' It also explicitly contrasts with calendar_update_event for rescheduling, so the agent can distinguish it from the nearest sibling without opening a 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?

States the trigger condition ('once the user has decided') and the alternative for the reschedule case. It also gives concrete routing rules for edge cases: propose a time only on Microsoft accounts, fall back to `comment` on PROVIDER_UNSUPPORTED, and drop the proposal when `allows_new_time_proposals` is false.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources