Local MCP

List Accounts

list_accounts

Read-only

Lists Mail.app email accounts WITH each account's email addresses, server_name and type. type is whatever Mail reports — imap | pop | iCloud | smtp | unknown — and Mail's scripting dictionary has NO Exchange value, so Exchange (EWS) accounts always come back as unknown, flagged with type_undetermined: true and a type_note; for those read the mailbox through m365_list_emails / m365_search_emails (listed once a Microsoft 365 account is connected) or outlook_diagnose instead of routing by type. Slower — queries Mail directly. For just the account NAMES (to pass to list_emails(account=...)), prefer list_email_accounts: it's faster (cached, no Mail lock). Each entry's permissions carries only the permissions this service has (read, send, write; a key that is missing does not apply). true: allowed in the account's boxes (LMCP's icon → My apps → open the app's row → the account's Read · Send · Write) and the item accepts it. false: turned off there, or the item is read-only (read_only: true).

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`note`	No	Present when some account's type could not be determined: how many, and what to do.
`count`	Yes
`accounts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

addedOutput schema / properties / accounts / items / properties / permissions

Added value: +{
+  "properties": {
+    "read": {
+      "type": "boolean"
+    },
+    "send": {
+      "type": "boolean"
+    },
+    "write": {
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / accounts / items / properties / read_only

Added value: +{
+  "description": "true: the system reports this item as not modifiable. Absent when it cannot tell.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 10, 2026

changedOutput schema / properties / accounts / items / properties / server_name / description

Previous value: -"Host Mail connects to. The evidence for an untyped account (an Exchange host looks like outlook.office365.com or an on-prem EWS host)."New value: +"Host Mail connects to. Evidence for an untyped account when present (an Exchange host looks like outlook.office365.com or an on-prem EWS host); Mail leaves it empty for many Exchange accounts, and then type_note says so and points at the email domain instead."

Changed5 schema fields changedAug 26, 2026

addedOutput schema / properties / accounts / items / properties / server_name

Added value: +{
+  "description": "Host Mail connects to. The evidence for an untyped account (an Exchange host looks like outlook.office365.com or an on-prem EWS host).",
+  "type": "string"
+}

changedOutput schema / properties / accounts / items / properties / type / description

Previous value: -"Account type, e.g. imap | pop | iCloud."New value: +"What Mail reports: imap | pop | iCloud | smtp | unknown. Mail has no Exchange value, so an Exchange (EWS) account reports unknown — that is Mail's answer, not a failed lookup."

addedOutput schema / properties / accounts / items / properties / type_note

Added value: +{
+  "description": "Present when type_undetermined: why the type is unknowable and which tools to use for that mailbox.",
+  "type": "string"
+}

addedOutput schema / properties / accounts / items / properties / type_undetermined

Added value: +{
+  "description": "true when Mail did not name the type (typically Exchange). Branch on this instead of matching the string \"unknown\".",
+  "type": "boolean"
+}

addedOutput schema / properties / note

Added value: +{
+  "description": "Present when some account's type could not be determined: how many, and what to do.",
+  "type": "string"
+}

First observedJun 30, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover read-only safety, and the description adds real behavior beyond them: it queries Mail directly so it is slower and takes a Mail lock, Exchange accounts always return type 'unknown' with type_undetermined: true, and it explains the true/false semantics of the permissions map including the read_only override. The LMCP UI navigation path is detail beyond what an agent needs, keeping it just short of top marks.

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 and the key alternative are front-loaded, but the single dense block crams in the type caveat, the m365 fallback, the performance note and a long permissions paragraph with UI click-path instructions. The parenthetical 'LMCP's icon → My apps → open the app's row → the account's Read · Send · Write' is operational trivia that does not earn its place.

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 return values, and it instead covers the non-obvious caveats an agent needs: the Exchange/unknown type behavior and the partial permissions semantics. Coverage is essentially complete for a zero-param list tool.

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?

The tool takes zero parameters, so there is nothing to document; the baseline for a no-param tool is 4. Description correctly spends no words on input arguments.

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?

Starts with a specific verb+resource and immediately enumerates the concrete fields returned (email addresses, server_name, type). It explicitly separates itself from the sibling list_email_accounts (names only) and from m365_* tools, so an agent can pick correctly 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?

Gives explicit when-to-use-alternatives: 'For just the account NAMES ... prefer list_email_accounts: it's faster (cached, no Mail lock)'. It also states an exclusion path — for Exchange accounts, read via m365_list_emails / m365_search_emails or outlook_diagnose instead of routing by type.

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

All Local MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.