Local MCP

List Microsoft 365 Accounts

list_m365_accounts

Read-only

List the Microsoft 365 accounts connected on this computer: email (upn), id, display name, which one is the default, its state (connected, reauth_required, unavailable) and the permissions it has. Use an account's email or id as the account parameter of the Microsoft 365 and Teams tools. Add an account with connect_m365_account. 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	Default
`count`	Yes
`accounts`	Yes
`default_account`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 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"
+}

addedOutput schema / properties / accounts / items / properties / reconnect_for

Added value: +{
+  "description": "Present when the account works but must be connected again (connect_m365_account) before it can do this: \"drafts\" = m365_create_draft.",
+  "items": {
+    "enum": [
+      "drafts"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

AddedOct 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds real behavioral value beyond that: the enumeration of account states (connected, reauth_required, unavailable) and the meaning of the `permissions` map, including that missing keys do not apply. The permissions sentence is dense and references a UI path, which weakens the payoff slightly.

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 first two sentences are front-loaded and efficient. The final sentence about `permissions` is a single tangled run-on mixing true/false meanings, a UI navigation path, and a read_only exception, which costs the reader more than it delivers.

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 detail return shapes, yet it still names the key fields, states, and permission keys an agent needs to reason about. The only real gap is that the permissions true/false semantics are stated in a way that is hard to apply reliably.

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?

Zero parameters, so the baseline is 4. The description does not waste effort re-describing an empty schema and instead explains the semantics of the `account` identifier consumed by downstream M365/Teams tools, which is the only relevant parameter information.

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 Microsoft 365 accounts connected on this computer') and immediately enumerates the exact fields returned (upn, id, display name, default flag, state, permissions). An agent can distinguish this from list_accounts, list_email_accounts, or telegram_list_accounts without opening any 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?

Explicitly tells the agent how to consume the output ('Use an account's email or id as the `account` parameter of the Microsoft 365 and Teams tools') and routes account creation to connect_m365_account. It does not mention set_default_m365_account or disconnect_m365_account, which are the other obvious follow-on siblings, so the routing is clear but incomplete.

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.