Skip to main content
Glama

List mail senders

well_list_mail_senders
Read-only

List the member's newsletter senders from live email records in the requested window. It returns counts, the last received date, a recent subject, the member's own saved choice and observed coverage. Each sender row carries person, the id of the single live person of the workspace holding the sender address, or null when no person or more than one holds it; never present a null person as a known person. To name that person, open it with well_get_entity on root "people" and its person_id, and never show the id itself as the person. It never reads a live mailbox. It covers list mail marked by the provider; Promotions, Social and Forums are not ingested. mailbox is the address of the member's own connected Gmail in this workspace, or null when none is connected, so an answer can name the account. status says whether the read ran: read (it ran, so an empty senders is a real "nothing there"), unavailable (it did not run: say the mail could not be read and offer to look again, never "no newsletters"). error holds the underlying text for a log, never for the person. 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.

Input Schema

NameRequiredDescriptionDefault
limitNo
window_daysNo
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
errorNo
statusYes
mailboxYes
sendersYes
successYes
coverageYes
truncatedYes
window_daysYes
total_sendersYes
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. Changed2 schema fields changed
    • addedOutput schema / properties / status
      Added value: +{
      +  "enum": [
      +    "read",
      +    "unavailable"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "mailbox",
      -  "senders",
      -  "total_senders",
      -  "window_days",
      -  "truncated",
      -  "coverage",
      -  "success"
      -]New value: +[
      +  "status",
      +  "mailbox",
      +  "senders",
      +  "total_senders",
      +  "window_days",
      +  "truncated",
      +  "coverage",
      +  "success"
      +]
  2. Changed10 schema fields changed
    • removedOutput schema / properties / coverage / properties / newest_note_at / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / coverage / properties / newest_note_at / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / coverage / properties / oldest_note_at / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / coverage / properties / oldest_note_at / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / mailbox / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / mailbox / 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"
      +]
    • removedOutput schema / properties / senders / items / properties / latest_subject / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / senders / items / properties / latest_subject / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  3. Changed2 schema fields changed
    • addedOutput schema / properties / senders / items / properties / person
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": false,
      +      "properties": {
      +        "person_id": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "person_id"
      +      ],
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • changedOutput schema / properties / senders / items / required
      Previous value: -[
      -  "address",
      -  "namespace",
      -  "count",
      -  "last_received",
      -  "latest_subject",
      -  "choice"
      -]New value: +[
      +  "address",
      +  "namespace",
      +  "count",
      +  "last_received",
      +  "latest_subject",
      +  "choice",
      +  "person"
      +]
  4. 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."
  5. Changed2 schema fields changed
    • addedOutput schema / properties / mailbox
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "senders",
      -  "total_senders",
      -  "window_days",
      -  "truncated",
      -  "coverage",
      -  "success"
      -]New value: +[
      +  "mailbox",
      +  "senders",
      +  "total_senders",
      +  "window_days",
      +  "truncated",
      +  "coverage",
      +  "success"
      +]
  6. Added

TDQS

A4.1/5.0
Behavior5/5

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

Well beyond the readOnly/openWorld annotations, it discloses the status contract (`read` vs `unavailable`), forbids the misleading "no newsletters" answer on unavailable reads, explains that `error` is log-only, and pins down the null-person convention and how to resolve a person via well_get_entity. These are exactly the failure modes an agent would otherwise fall into.

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?

Purpose is front-loaded and most sentences carry real behavioral content (status semantics, person resolution, scope exclusions). It is still a dense wall of text with some duplication of the workspace_id and conversation_id schema descriptions that could be cut.

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?

With an output schema present the description need not explain returns, yet it usefully covers the fields that need interpretation (person, mailbox, status, error) and the workspace-selection path. Remaining gaps are the undocumented limit and window_days bounds, which the schema already constrains.

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 coverage is 60% and the description adds little: `workspace_id` handling is restated from its own schema description, and `limit` and `window_days` (the two parameters with no schema description) are only alluded to as "the requested window." Per the coverage rule, baseline 3 is right.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb and resource ("List the member's newsletter senders from live email records in the requested window") and even enumerates the returned fields, so the operation is unambiguous. It never differentiates itself from closely named siblings such as well_get_mail_sender_choices, so it stops short of a 5.

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?

It gives clear conditional routing for workspace authorization: call directly when the token covers one workspace, pass workspace_id when it covers several. It also states scope limits (no live mailbox reading; Promotions/Social/Forums not ingested) that tell the agent when this tool will not answer. No alternative sibling tool is named, so it is not a full when/when-not/alternatives 5.

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