Local MCP

WhatsApp List Accounts

whatsapp_list_accounts

Read-only

List the WhatsApp accounts linked to Local MCP on this Mac: each one's id (wa1, wa2, …), the label the user gave it, which one is the default, whether a link is stored, and a linked phone masked to its country code and last 4 digits. Pass an id or label as the account parameter of any whatsapp_* tool; without it they use the default account. Add another account with whatsapp_connect (add_account: true). 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
`count`	Yes
`accounts`	Yes
`default_account`	No	The default account's label.
`default_account_id`	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 / phone_masked

Added value: +{
+  "description": "The linked phone's country code and last 4 digits (+54 ••• 1234), to tell accounts apart. Never the full number. Absent when not linked or not known.",
+  "type": "string"
+}

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

AddedOct 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint false, and openWorldHint false, so the safety profile is covered. The description adds real behavioral context beyond that: phone numbers are masked to country code plus last four digits, and the `permissions` map is per-service with absent keys meaning 'does not apply' and false covering both disabled and read-only items. It does not address failure modes (e.g., no linked accounts), which keeps it off a 5.

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 and returned fields are front-loaded, followed by downstream usage and the account-adding path. The permissions sentence is dense and nests a UI breadcrumb (icon → My apps → row → Read · Send · Write), which is informative but the bulkiest part of an otherwise efficient definition.

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

Completeness5/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 document return shape, and it still explains the non-obvious permission semantics and phone masking. Annotations carry the read-only profile, there are no parameters to document, and the downstream `account` usage is spelled out, so an agent has everything needed to call and interpret this 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 the baseline is 4; the input schema is empty and nothing is left ambiguous. The description's discussion of the `account` parameter belongs to downstream whatsapp_* tools rather than this one, so it does not count as added parameter meaning here.

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?

The description opens with a specific verb and resource (list the WhatsApp accounts linked to Local MCP on this Mac) and enumerates the fields returned (id, label, default flag, link status, masked phone). It is unmistakable against siblings such as list_accounts, telegram_list_accounts, or whatsapp_connect.

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?

It states exactly how the output is consumed: pass an id or label as the `account` parameter of any whatsapp_* tool, and otherwise the default account is used. It also routes the agent to the alternative path for adding an account (whatsapp_connect with add_account: true), so no inference is needed.

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.