Skip to main content
Glama

List calendars

well_list_calendars
Read-only

List the calendars connected to this workspace, with their owner. Use it to pick the calendar for a new event: events can only be created on a calendar with is_mine true, and the user's main calendar has is_primary true. owner_person_id is the member whose own calendar it is. It is null on a calendar shared with a member: that member can read it but does not own it, and Well does not know who owns it, so never name an owner for it. Only the public events of a shared calendar can be read, and it cannot be changed through Well. account_email is the Google account the caller's own calendar syncs from (null on another member's calendar), so an answer can name the account. It also gives the calendar_id that well_list_calendar_events takes to read one calendar. If the result has a note, give it to the user as it is: it invites them to connect their own calendar.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Read the calendar. Write the from and to of a range with the user's UTC offset from well_convert_time, never an offset you worked out.

Input Schema

NameRequiredDescriptionDefault
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

NameRequiredDescriptionDefault
noteYes
errorNo
successYes
calendarsYes
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • removedOutput schema / properties / calendars / items / properties / account_email / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / calendars / items / properties / account_email / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / calendars / items / properties / owner_person_id / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / calendars / items / properties / owner_person_id / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / calendars / items / properties / timezone / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / calendars / items / properties / timezone / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / note / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / note / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed2 schema fields changed
    • addedOutput schema / properties / calendars / items / properties / owner_person_id / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / calendars / items / properties / owner_person_id / type
      Removed value: -"string"
  3. Changed1 schema field changed
    • changedOutput schema / properties / newly_connected / description
      Previous value: -"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."New value: +"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."
  4. Changed2 schema fields changed
    • addedOutput schema / properties / calendars / items / properties / account_email
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • changedOutput schema / properties / calendars / items / required
      Previous value: -[
      -  "calendar_id",
      -  "name",
      -  "is_primary",
      -  "timezone",
      -  "is_mine",
      -  "owner_person_id"
      -]New value: +[
      +  "calendar_id",
      +  "name",
      +  "is_primary",
      +  "timezone",
      +  "is_mine",
      +  "owner_person_id",
      +  "account_email"
      +]
  5. Changed1 schema field changed
    • addedInput schema / properties / workspace_scope
      Added value: +{
      +  "description": "Restrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.",
      +  "enum": [
      +    "family"
      +  ],
      +  "type": "string"
      +}
  6. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/openWorldHint false, but the description adds substantial semantics beyond them: owner_person_id is null on shared calendars and Well does not know the owner, so an agent must never name one; only public events of a shared calendar are readable and it cannot be modified through Well; account_email is null on another member's calendar; and any returned note must be relayed verbatim. These are exactly the behavioral constraints an agent could not infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the workspace_id rule are front-loaded and well organized, but the body is dense and drifts into field-by-field output narration. The final sentence about from/to range offsets is leftover text from an events-listing tool and does not earn its place here, weakening an otherwise tight structure.

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?

An output schema exists, so return values needn't be explained, yet the description covers the workspace-selection behavior, shared-calendar limits, and the required note relay, which is what an agent actually needs to act correctly. The only gap is the stray range/offset instruction that has no corresponding parameter, leaving a small ambiguity about whether this tool takes a time range.

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, and the description adds real value on workspace_id by explaining the multi-workspace failure mode (the read "will not guess which one you mean"). However, it never mentions conversation_id, and the closing line about writing "the from and to of a range with the user's UTC offset from well_convert_time" refers to parameters this tool does not have, which can mislead an agent into looking for range inputs.

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 and resource: "List the calendars connected to this workspace, with their owner." It also distinguishes itself from the closely named sibling well_list_calendar_events by noting it supplies the calendar_id that tool takes, so an agent can separate the two without opening schemas.

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?

Explicitly states the driving use case ("Use it to pick the calendar for a new event"), gives the selection rule (only calendars with is_mine true can receive events; is_primary marks the main one), and routes the agent onward to well_list_calendar_events for reading. It also gives conditional guidance for workspace_id: call directly when the token authorizes one workspace, pass workspace_id when it authorizes several.

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