DOS AI

List the members of a WhatsApp group

dosai_get_wa_group_participants

Read-onlyIdempotent

Members of one WhatsApp group of the project's number (jid from dosai_list_wa_groups): phone, name, saved_name (how the owner saved them in the phone's contacts), is_admin, is_owner (the group creator). The bot does not need to be on in the group. WhatsApp hides the number of some members in groups: then phone is null and phone_hidden is true (hidden_phones counts them). Needs the number connected.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "jid": "<jid>"
    },
    "name": "dosai_get_wa_group_participants"
  }
}

Input Schema

Name	Required	Description	Default
`jid`	Yes	Group id like 120363...@g.us from dosai_list_wa_groups.
`project_id`	Yes	Project id, as returned by dosai_list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses genuinely useful behavior: the bot does not have to be a group member, and WhatsApp may mask numbers, in which case phone is null, phone_hidden is true, and hidden_phones counts them. That is exactly the kind of edge case an agent could otherwise misreport as a data error.

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?

The description is short, front-loaded, and every clause carries information (field list, prerequisite, hidden-number caveat). The first sentence is a dense run-on list of fields, which is slightly harder to parse but not wasteful.

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 no output schema, the description compensates by enumerating the returned fields and explaining the hidden-phone case. Combined with the connection prerequisite, an agent has everything needed to call it and interpret the result.

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 100% and both parameters are documented in the schema itself, including the jid pattern and the project_id source. The description only echoes the jid provenance already stated in the schema, so it adds little semantic value beyond it.

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 ('Members of one WhatsApp group of the project's number') and enumerates the returned fields, so an agent knows exactly what the call yields. It also implicitly separates itself from dosai_list_wa_groups by naming that sibling as the source of the jid.

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 tells the agent where the required jid comes from (dosai_list_wa_groups) and states the prerequisite 'Needs the number connected', plus the reassuring condition that the bot need not be in the group. There is no explicit when-not guidance, but the context for correct use is clear.

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

All DOS AI 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.

Resources

Need Help?