Skip to main content
Glama
googlarz

Signal MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_user_status

Read-onlyIdempotent

Check whether phone numbers or usernames are registered on Signal in one batch query, so you can verify recipients before sending messages. Returns UUID and isRegistered per input.

Instructions

Check whether phone numbers and/or usernames are registered on Signal, in one batch query to Signal's servers. recipients: list of E.164 phone numbers; usernames: list of Signal usernames or username links; at least one of the two is required. Returns one entry per input with recipient, number or username, uuid (null if not registered) and isRegistered. Use it before messaging an unknown number; numbers that hide their discoverability can show as unregistered. For a contact's name or details use find_contact or get_profile.

Input Schema

NameRequiredDescriptionDefault
usernamesNoList of Signal usernames or username links to check
recipientsNoList of phone numbers (E.164) to check

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.40.1
    • addedInput schema / properties / usernames
      Added value: +{
+  "description": "List of Signal usernames or username links to check",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • removedInput schema / required
      Removed value: -[
-  "recipients"
-]
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the return shape (one entry per input with recipient, number/username, uuid null when unregistered, isRegistered) and the discoverability caveat — both absent from annotations. It stops short of describing pagination or rate limiting, hence not a 5.

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 dense sentences with zero filler: purpose and batching first, parameter formats and the at-least-one constraint second, return shape and usage caveat third. Every sentence carries distinct information and the purpose is front-loaded.

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?

There is no output schema, so the description carries the burden of explaining return values and does so (uuid null when unregistered, isRegistered). Combined with the required-parameter constraint, the alternatives for contact lookup, and the discoverability caveat, an agent has everything needed to call and interpret this tool.

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 baseline is 3, but the description adds meaning the schema does not encode: it restates the formats (E.164 for recipients, usernames or username links) and states the cross-parameter constraint 'at least one of the two is required', which the schema cannot express since required is empty.

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 ('Check whether phone numbers and/or usernames are registered on Signal') plus the scope ('in one batch query to Signal's servers'), and explicitly routes away from find_contact/get_profile for other needs. An agent can distinguish it from list_contacts or get_profile without opening any schema.

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 an explicit trigger ('Use it before messaging an unknown number') and names the alternatives for adjacent needs ('For a contact's name or details use find_contact or get_profile'). It also warns about a false-negative case (numbers that hide discoverability), which is exactly the kind of when-not guidance an agent needs.

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

Deploy Server

Other Tools