Skip to main content
Glama

Turbo Notify: WhatsApp for AI agents

Get one number and its connection status

get_number
Read-onlyIdempotent

Check one number: its phone number, status, and when that status began.

id (num_…) is the number's permanent identifier. The alias can be renamed, the id cannot. Either one works as number_alias.

connected means it can send right now. connecting means a connection was just requested and is being set up; check again in a few seconds. reconnecting means the number lost its connection and Turbo Notify is bringing it back by itself: there is nothing to do but wait and check again. Until it is connected again, sends are refused with number_not_connected. disconnected means the link to the phone still exists but the number is offline, so connect_number brings it back. inactive is the same for a number that was linked and has not been brought online yet: connect_number brings it online too. pending means the number was never linked to a phone, and no_main_number (what a brand-new account gets for main, and list_numbers is empty) means there is no number at all yet: either way a person has to link it from the Numbers page of the dashboard, so tell them and do not retry the send meanwhile. revoked means the phone unlinked the device, or another connection took it over. failed means a pairing did not complete, and reason says why (for example pairing_timeout when the code or QR code was not used in time, paired_phone_mismatch when another WhatsApp used it). Either one has to be paired again by a person holding that phone: from the dashboard (main or extra number) or, for an extra number, through the API's pairing endpoint, by code or by QR code. No tool here pairs a number: it needs a person with the phone.

pairing means a person is pairing the number right now. The code or QR code they use is not part of this answer: it belongs to that person. Check again later; the status moves to connected, or to failed with a reason.

Input Schema

NameRequiredDescriptionDefault
number_aliasNoWhich of the organization's WhatsApp numbers this acts on: `main`, the alias of an extra number, or the number's `id` (`num_…`), which stays the same when the alias is renamed. Call `list_numbers` to see them. Defaults to the main number.main

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare it as a safe, idempotent read; the description goes far beyond by mapping every status value to its operational meaning, disclosing the downstream failure mode (`number_not_connected` refusals), and stating that pairing requires a human with the phone. That is exactly the context an agent needs to interpret the result rather than just fetch it.

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

Conciseness3/5

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

The status-by-status enumeration is organized but roughly 350 words for a one-parameter read tool, and much of it re-describes values that an output schema already carries. The leading sentence is well front-loaded, but the body is longer than the decision requires.

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?

Nothing an agent needs to call and interpret this tool is missing: the identifier forms, the default of `main`, every status value, and the correct follow-up action for each. Given annotations and an output schema already cover safety and shape, this is fully sufficient.

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 the schema already explains `main` vs alias vs `num_…` id, including that the id survives renames. The description restates the same fact ("The alias can be renamed, the `id` cannot") without adding format, validation, or edge-case detail beyond it, 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 specific verb and resource plus the exact fields returned: "Check one number: its phone number, status, and when that status began." The single-resource scope is clearly distinct from the sibling `list_numbers`, which the description references.

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?

Gives strong action-oriented guidance per state: wait for `reconnecting`, use `connect_number` for `disconnected`/`inactive`, and tell a person to link from the dashboard for `pending`/`no_main_number`/`revoked`/`failed`. It also rules out retrying sends and notes "No tool here pairs a number." It does not explicitly state when to pick this over `list_numbers` for a single lookup, which keeps it short of a 5.

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.