Skip to main content
Glama

WhatsMCP: MCP for WhatsApp

List AI Voice-Agent Calls

wa_ai_list_calls
Read-only

List this workspace's AI voice-agent calls, newest first: outbound calls started with wa_ai_call_start and inbound WhatsApp calls answered by a preset whose answers_inbound is true (direction says which; from is the caller of an inbound call). Use a call_ref with wa_ai_call_get for the transcript and recording link.

Input Schema

NameRequiredDescriptionDefault
limitNohow many to return, 1-100; defaults to 25
beforeNoa call_ref from the previous page, to list older calls; omit for the newest

Output Schema

NameRequiredDescriptionDefault
nextNopass as before for the next, older page; absent on the last page
callsYesAI calls, newest first — outbound ones you started and inbound ones an answering preset took; each call_ref works with wa_ai_call_get
refusalNopresent only when the request was declined

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / refusal / properties / candidates
      Added value: +{
      +  "description": "on an account_ambiguous refusal: the accounts to choose from — retry with one of these as account_id",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "account_id": {
      +        "description": "the id to retry with as account_id",
      +        "type": "string"
      +      },
      +      "name": {
      +        "description": "the account's WhatsApp display name",
      +        "type": "string"
      +      },
      +      "phone": {
      +        "description": "the account's phone number, E.164",
      +        "type": "string"
      +      },
      +      "status": {
      +        "description": "whether the number works right now — live, connecting, or why not, as wa_list_accounts reports it",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "account_id"
      +    ],
      +    "type": "object"
      +  },
      +  "type": [
      +    "null",
      +    "array"
      +  ]
      +}
  2. Changed3 schema fields changed
    • addedOutput schema / properties / refusal / properties / account_status
      Added value: +{
      +  "description": "when the number is not working: its status — starting, not_running, whatsapp_down, suspended, pairing, unlinked or locked",
      +  "type": "string"
      +}
    • addedOutput schema / properties / refusal / properties / account_status_reason
      Added value: +{
      +  "description": "the detail of account_status, e.g. no_egress, stopped, no_plan",
      +  "type": "string"
      +}
    • addedOutput schema / properties / refusal / properties / since
      Added value: +{
      +  "description": "when the number stopped working, RFC3339, when known",
      +  "type": "string"
      +}
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint=false, so safety is covered; the description adds real context beyond that: newest-first ordering, pagination via a call_ref from the previous page, and how to interpret the direction and from fields on inbound calls. It does not discuss whether the full history or only a recent window is available, which is the one remaining behavioral unknown.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste, and the decisive information (what is listed, ordering) is front-loaded before the follow-up routing hint. Dense but every clause carries meaning.

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?

A read-only lister with an output schema, 100% parameter coverage, and annotations covering safety; the description supplies scope, ordering, pagination pattern, and the next-step tool. Nothing needed to invoke it correctly is missing.

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% and both parameters are documented in the schema (limit 1-100 default 25; before as a call_ref from the previous page). The description's mention of 'newest first' and the cursor-style paging corroborates but does not extend the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ('List this workspace's AI voice-agent calls, newest first') and then defines exactly which calls qualify: outbound calls started with wa_ai_call_start and inbound WhatsApp calls answered by a preset with answers_inbound true. This scope definition is what separates it from the generic wa_list_calls, so an agent can distinguish it without opening either 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 routes the agent forward: 'Use a call_ref with wa_ai_call_get for the transcript and recording link.' That is clear context for the natural follow-up. It does not, however, state when to prefer the sibling wa_list_calls (non-AI calls) or anything about what is excluded, leaving one plausible routing question unanswered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources