Skip to main content
Glama

WhatsMCP: MCP for WhatsApp

List Blocked Contacts

wa_list_blocked
Read-only

List every contact one of your accounts has blocked. Each entry carries the contact's number, the name this account's address book has for them — absent for someone not saved on the phone — and the country the number belongs to. WhatsApp does not report when a contact was blocked, so no date is available.

Input Schema

NameRequiredDescriptionDefault
account_idYesthe account whose blocklist to read, as returned by wa_list_accounts

Output Schema

NameRequiredDescriptionDefault
statusYesok (the operation succeeded) or refused (nothing was done)
blockedNoevery contact on the account's blocklist (wa_list_blocked only)
contactNothe contact that was blocked or unblocked (wa_block_contact only)
refusalNopresent only when status is refused

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. Changed1 schema field changed
    • changedOutput schema / properties / contact / description
      Previous value: -"the contact that was blocked or unblocked (wa_block_contact and wa_unblock_contact only)"New value: +"the contact that was blocked or unblocked (wa_block_contact only)"
  4. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the read-only safety profile, and the description goes further by disclosing data limitations an agent would otherwise probe for: the name field is absent for unsaved numbers, and block timestamps are unavailable because WhatsApp doesn't report them. The one gap is that idempotentHint=false is unexplained for what reads like a stable list operation.

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?

Three short sentences, front-loaded with the action, then the return shape, then the caveat that pre-empts a wrong assumption. No sentence is filler.

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 single-parameter list tool with an output schema and safety annotations needs little more; the description still covers scope, entry contents, and the missing-timestamp caveat. Nothing required to invoke it correctly is absent.

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?

There is a single parameter with 100% schema description coverage, and the schema already explains it is the account whose blocklist is read. The description adds no further parameter semantics, so the baseline 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 concrete verb and resource — list the contacts a given account has blocked — which cleanly separates it from wa_list_contacts and wa_block_contact without needing the schema opened. The scope qualifier 'one of your accounts' makes the per-account nature explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the 'blocked' qualifier but the description never states when to reach for this instead of wa_list_contacts, nor any prerequisite such as pairing status. The tool-chaining hint ('as returned by wa_list_accounts') lives in the schema, not the description.

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