mailmcp

List mail accounts

list_accounts

Read-onlyIdempotent

Lists all configured mailboxes with their addresses, allowed actions, and backend details. Optionally checks each login connection.

Instructions

Lists the mailboxes: ids, addresses and permitted operations. backend "graph" is Outlook (string ids; labels are categories); reauth_by: when the owner must sign in to Microsoft again (setup page); plan: the mailmcp plan and, near expiry, how to renew. protection: verification emails hidden from you.

Input Schema

Name	Required	Description	Default
`check_connection`	No	Also test every login (slower)

Output Schema

Name	Required	Description	Default
`accounts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.13.12Oct 16, 2026

changedInput schema / properties / check_connection / description

Previous value: -"Also test the login of every account: IMAP, or the Microsoft sign-in (slower)."New value: +"Also test every login (slower)"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "accounts": {
+      "items": {},
+      "type": "array"
+    }
+  },
+  "required": [
+    "accounts"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv0.8.1Sep 23, 2026

changedInput schema / properties / check_connection / description

Previous value: -"Also test the IMAP login of every account (slower)."New value: +"Also test the login of every account: IMAP, or the Microsoft sign-in (slower)."

First observedv0.1.0Sep 16, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description does add genuinely useful behavioral context the annotations cannot: that 'graph' backends are Outlook with string ids and category labels, that reauth_by signals re-authentication via a setup page, and notably that 'protection' hides verification emails from the agent. That is real disclosure, though it is framed as output-field semantics rather than operation behavior.

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?

Purpose is front-loaded in the first clause, but the remainder is a dense backtick glossary whose phrasing is uneven (e.g. '`plan`: the mailmcp plan and, near expiry, how to renew'). It is compact but cryptic in places.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not have spent most of its length re-explaining return fields, and it leaves the actual gap — when to call this tool and when to enable check_connection — unfilled. Adequate but with clear gaps for a read-only listing tool.

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 description coverage is 100% for the single check_connection parameter, so the schema fully documents it ('Also test every login (slower)'). The description says nothing about this parameter and adds no syntax or timing detail, so baseline 3 applies.

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 opening sentence gives a specific verb and resource ('Lists the mailboxes: ids, addresses and permitted operations'), which is clearly distinguishable from sibling list_* tools such as list_folders or list_templates. However, it never explicitly frames itself as the accounts-level listing versus those siblings, so differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance at all: nothing says when to call list_accounts, when to prefer list_folders, or when to set check_connection=true. The rest of the text is a field glossary, so the agent gets no routing help.

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