Skip to main content
Glama

Get whatsapp link

well_get_whatsapp_link
Read-only

Read the WhatsApp number linked to a Well login: the masked number, the workspace it was proven in, whether WhatsApp reaches that person in this workspace, and the link that opens the WhatsApp chat with Well. Call it when the user asks whether their WhatsApp is connected, which number is linked, or before well_delete_whatsapp_link when they want to check what would be unlinked.

Omit person_id for the user's own link. An owner or admin may pass a member's person_id to read the number that member proved in this workspace; anyone else is refused.

The result is linked false with link null when no number is linked; phone_on_file then says whether the person has a number on file to link. reached_from_another_workspace true means the member's number still reaches this workspace through a link they proved in another workspace: an unlink here does not stop it, so say so before an owner or admin unlinks.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
person_idNoThe person whose link to read, for an owner or admin asking about another member. Omit it for the user's own link.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

NameRequiredDescriptionDefault
linkNoThe linked number; null when none is linked. Absent on failure.
errorNo
linkedNoWhether a WhatsApp number is linked. Absent on failure.
successYes
phone_on_fileNoSet only when no number is linked: whether the person has a phone number on file that a link would prove. Never write the number or say where it came from. Absent on failure.
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
reached_from_another_workspaceNoThe member's number reaches this workspace through a link proven in another workspace; unlinking here leaves that reach. Absent on failure.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / link / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "enabled_here": {
      -        "description": "A WhatsApp message from the number reaches the member's seat in this workspace.",
      -        "type": "boolean"
      -      },
      -      "link_id": {
      -        "description": "The public id of the link that proved the number.",
      -        "type": "string"
      -      },
      -      "linked_here": {
      -        "description": "The number was proven in this workspace.",
      -        "type": "boolean"
      -      },
      -      "linked_workspace_id": {
      -        "description": "The workspace the number was proven in.",
      -        "type": "string"
      -      },
      -      "linked_workspace_name": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ]
      -      },
      -      "phone_display": {
      -        "description": "The linked number, masked: its first digits and last two stay readable.",
      -        "type": "string"
      -      },
      -      "whatsapp_chat_url": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ],
      -        "description": "Opens the WhatsApp chat with Well; null when no Well number is set."
      -      }
      -    },
      -    "required": [
      -      "link_id",
      -      "phone_display",
      -      "linked_workspace_id",
      -      "linked_workspace_name",
      -      "linked_here",
      -      "enabled_here",
      -      "whatsapp_chat_url"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "enabled_here": {
      +        "description": "A WhatsApp message from the number reaches the member's seat in this workspace.",
      +        "type": "boolean"
      +      },
      +      "link_id": {
      +        "description": "The public id of the link that proved the number.",
      +        "type": "string"
      +      },
      +      "linked_here": {
      +        "description": "The number was proven in this workspace.",
      +        "type": "boolean"
      +      },
      +      "linked_workspace_id": {
      +        "description": "The workspace the number was proven in.",
      +        "type": "string"
      +      },
      +      "linked_workspace_name": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "phone_display": {
      +        "description": "The linked number, masked: its first digits and last two stay readable.",
      +        "type": "string"
      +      },
      +      "whatsapp_chat_url": {
      +        "description": "Opens the WhatsApp chat with Well; null when no Well number is set.",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      }
      +    },
      +    "required": [
      +      "link_id",
      +      "phone_display",
      +      "linked_workspace_id",
      +      "linked_workspace_name",
      +      "linked_here",
      +      "enabled_here",
      +      "whatsapp_chat_url"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed1 schema field changed
    • addedOutput schema / properties / phone_on_file
      Added value: +{
      +  "description": "Set only when no number is linked: whether the person has a phone number on file that a link would prove. Never write the number or say where it came from. Absent on failure.",
      +  "type": "boolean"
      +}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly, non-destructive, closed-world, and the description goes well beyond them: it discloses the refusal behavior for non-privileged callers and the subtle cross-workspace reachability case where "an unlink here does not stop it." It also documents the multi-workspace token behavior (no guessing, workspace_id required).

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?

Front-loads purpose and fields, then proceeds in scannable paragraphs (usage, permissions, result semantics, workspace routing). Dense but nearly every sentence carries operational information; slightly verbose in the multi-workspace closing paragraph.

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?

Even though an output schema exists, the description explains the meaningful result states (linked=false with null link, phone_on_file, reached_from_another_workspace) that an agent must interpret to advise the user. Nothing needed to call or interpret it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter logic not obvious from the schema: person_id is omitted for self, workspace_id is only required when the token spans multiple workspaces. It doesn't add much on conversation_id or workspace_scope beyond the schema text, so not a 5.

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 ("Read the WhatsApp number linked to a Well login") and enumerates exactly what comes back: masked number, workspace, reachability, and the chat link. It is clearly distinguishable from the sibling well_delete_whatsapp_link, which it names as the destructive counterpart.

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?

Gives explicit triggering conditions (user asks whether WhatsApp is connected, which number is linked) and a concrete pre-flight use ("before well_delete_whatsapp_link ... check what would be unlinked"). It also spells out the permission model: omit person_id for self, owner/admin may pass a member's person_id, anyone else is refused.

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