Skip to main content
Glama
Sign In
Commonpost MCP for Thunderbird

Commonpost MCP for Thunderbird

by commonpost
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

List Events

listEvents
Read-onlyIdempotent

Retrieve calendar events within a date range from one or all Thunderbird calendars, including recurring occurrences and key details such as title, time, location, and status.

Instructions

List events in a date range (default: next 30 days) from all calendars or one, by start time; recurring events come as occurrences sharing the series id, with a recurrenceId. At most maxResults, no paging: narrow the range for more. Rows: id, calendarId, title, start, end (all-day: the last day), location, description, status, categories, reminders, onlineMeetingURL.

Input Schema

NameRequiredDescriptionDefault
formatNo'table' returns { columns, rows }
endDateNoISO 8601 end (default: start + 30 days); date-only includes the whole day
reviewIdNoFrom createEvent: that dialog's state instead (open, saved + eventId, closed unsaved, failed)
startDateNoISO 8601 start (default: now)
calendarIdNoCalendar ID (from listCalendars); omit for all
maxResultsNoMax events

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / reviewId
      Added value: +{
+  "description": "From createEvent: that dialog's state instead (open, saved + eventId, closed unsaved, failed)",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.19.2
    • changedInput schema / properties / calendarId / description
      Previous value: -"Calendar ID to query (from listCalendars). If omitted, queries all calendars."New value: +"Calendar ID (from listCalendars); omit for all"
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description adds real substance beyond them: recurring events are returned as occurrences sharing the series id with a recurrenceId, there is a hard cap with no paging, and all-day end dates mean the last day. It omits timezone handling, which matters a lot for a date-range event query.

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 range and source, then recurrence, then the cap, then row fields — a sensible order with no filler sentences. The trailing 'Rows:' enumeration is long but earns its place because there is no output schema to document the return shape.

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 zero-required-parameter read tool with no output schema, the description covers defaults, ordering, recurrence representation, result capping, and the returned fields — everything an agent needs to call it and interpret the result. Timezone behavior is the only notable omission and is minor relative to what is covered.

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, but the description adds genuine meaning: it explains that the range defaults to the next 30 days, that an all-day 'end' is the last day, and that maxResults is a hard ceiling rather than a page size. It also implicitly maps 'all calendars or one' to calendarId, though reviewId is left entirely to the schema.

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 ('List events'), the scope ('in a date range (default: next 30 days)'), the source ('from all calendars or one'), and the ordering ('by start time'). An agent can distinguish this read/list operation from siblings like updateEvent, deleteEvent, and listCalendars without opening the schema.

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?

Gives clear operating context: defaults to the next 30 days when no range is supplied, and explicitly instructs 'no paging: narrow the range for more' when results exceed maxResults. It does not name an alternative sibling for cases this tool cannot serve, but no obvious competing event-search tool exists here, so the gap is small.

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