Skip to main content
Glama
googlarz

Signal MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

update_account

DestructiveIdempotent

Change Signal account attributes such as username, device name, and privacy settings like discoverability and number sharing. Updates take effect immediately on the server.

Instructions

Change account attributes stored on Signal's servers for this account. All six parameters are optional and only the ones you pass are sent: device_name (string) renames this device as shown in list_devices on your other devices; discoverable_by_number (boolean) whether people who have your number can find you on Signal; number_sharing (boolean) whether your phone number is shown to people you message; unrestricted_unidentified_sender (boolean) true lets anyone, not only contacts, send you sealed-sender messages; username (string, without @) claims a Signal username; delete_username (boolean) removes the current one and takes precedence over username if both are given. Takes effect immediately on the real account; setting a username that is taken or invalid fails with an error. Returns {status: 'account updated'} (the resulting username is not echoed). Use update_configuration for read receipts, typing indicators and link previews, update_profile for your name, about text and avatar.

Input Schema

NameRequiredDescriptionDefault
usernameNoSet a Signal username (without @) as an alias for your number
device_nameNoName for this device shown in linked devices list
number_sharingNoShare your phone number when sending messages
delete_usernameNoDelete your current Signal username
discoverable_by_numberNoAllow others to find your account by phone number
unrestricted_unidentified_senderNoAllow sealed-sender messages from anyone (not just contacts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.2
    • changedInput schema / properties / delete_username / description
      Previous value: -"Delete the current username"New value: +"Delete your current Signal username"
    • changedInput schema / properties / device_name / description
      Previous value: -"Name shown on linked-device list"New value: +"Name for this device shown in linked devices list"
    • changedInput schema / properties / discoverable_by_number / description
      Previous value: -"Allow others to find you by phone number"New value: +"Allow others to find your account by phone number"
    • changedInput schema / properties / number_sharing / description
      Previous value: -"Share your number when sending messages"New value: +"Share your phone number when sending messages"
    • changedInput schema / properties / unrestricted_unidentified_sender / description
      Previous value: -"Allow sealed-sender from anyone"New value: +"Allow sealed-sender messages from anyone (not just contacts)"
    • changedInput schema / properties / username / description
      Previous value: -"Set a Signal username (without @)"New value: +"Set a Signal username (without @) as an alias for your number"
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (destructiveHint=true, idempotentHint=true), and the description adds substantial context beyond them: changes take effect immediately on the real account, invalid/taken usernames fail with an error, delete_username takes precedence over username, and the return payload is {status: 'account updated'} with the username not echoed.

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?

The purpose and the alternative-tool routing are front-loaded, and every sentence carries information. It is, however, a dense unbroken block rather than a structured parameter list, which slightly hurts scanability for a six-parameter tool.

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?

Despite having no output schema, the description states the exact return shape and the notable omission (username not echoed), covers error behavior, precedence, and cross-tool routing. Nothing an agent needs to call this 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 baseline is 3, but the description goes further: it explains what each flag means in user terms (device_name appears in list_devices on other devices; discoverable_by_number governs number-based discovery), specifies the username format (without @), and documents the delete_username-over-username precedence rule that the schema does not.

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 ('Change account attributes stored on Signal's servers for this account') and explicitly routes the agent away from siblings: update_configuration for receipts/typing/link previews and update_profile for name/about/avatar. An agent can distinguish it from every related tool without opening a 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?

Names the two alternatives and the exact conditions that select them, plus notes that all six parameters are optional and only passed ones are sent. This tells the agent both when to use this tool and when to use a neighbor instead.

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