Calendar MCP Tool Annotations: What Read and Write Hints Actually Mean

An MCP client should know whether a calendar tool reads data or changes it before it asks an agent to call that tool. Tool annotations supply that signal, but they do not replace account permissions or human confirmation.

What the hints mean

The MCP tools specification defines hints such as readOnlyHint, destructiveHint, and openWorldHint. They describe expected tool behavior for the client. They are not an authorization system. A client still needs to treat the server as a trust boundary.

In CalendarMCP, list_events, get_event, and list_calendars are annotated as read-only. A create operation is a write. A delete or attendee-changing operation carries a stronger warning. The exact hints are visible in the tool definitions returned to an MCP client.

A useful client policy

1. Allow read-only discovery when the user asks a calendar question.
2. Show account, calendar, title, time, and timezone before a write.
3. Require explicit confirmation before deletion or attendee changes.
4. Enforce read/write grants on each calendar, independently of annotations.

For example, an agent can call list_calendars first, then draft a proposed change. Even if the client permits update_event, the server will reject a write to a calendar with only Read access.

The takeaway

Use annotations to choose the right approval UX, and use calendar grants to enforce access. Neither one makes a bad calendar edit safe by itself.

Sources: MCP tools specification and CalendarMCP tool documentation.