Skip to main content
Glama
googlarz

Signal MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_expiration_timer

Idempotent

Set or disable disappearing-message timers for Signal direct or group chats by giving expiration seconds (0 disables), so new messages auto-delete after the chosen lifetime.

Instructions

Set or turn off the disappearing-messages timer of a one-to-one or group chat. expiration_seconds (required): lifetime of new messages in seconds, 0 disables; common values 3600 (1h), 86400 (1d), 604800 (1w), 2592000 (30d). Pass recipient (E.164) for a direct chat or group_id (from list_groups) for a group; one is required, and group_id wins if both are given. Every participant is notified and the timer applies to new messages; already sent messages are unaffected. For a group this is the same as update_group with expiration_seconds. Returns status and seconds.

Input Schema

NameRequiredDescriptionDefault
group_idNoGroup ID (from list_groups) for a group conversation; wins if recipient is also given
recipientNoPhone number (E.164) for a direct conversation
expiration_secondsYesTimer in seconds (0 to disable). Common: 3600=1h, 86400=1d, 604800=1w

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.43.0
    • changedInput schema / properties / group_id / description
      Previous value: -"Group ID for a group conversation"New value: +"Group ID (from list_groups) for a group conversation; wins if recipient is also given"
    • changedInput schema / properties / recipient / description
      Previous value: -"Phone number for a direct conversation"New value: +"Phone number (E.164) for a direct conversation"
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (which only cover the safety/idempotency profile): it discloses that every participant is notified, that the timer applies only to new messages while already-sent messages are unaffected, and that the response contains status and seconds. These are non-obvious side effects an agent needs.

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?

A single dense paragraph that front-loads the action, then constraints, then side effects. Every clause carries information; slightly packed but not padded.

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?

No output schema exists, and the description compensates by stating the return ('status and seconds'). Addressing, disabling semantics, side effects, and the sibling equivalence are all covered, leaving nothing essential for correct invocation.

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?

With 100% schema coverage the baseline is 3, but the description adds real value: the semantics of 0 (disable), a unit hint, a common-value table including 30d (2592000) which is absent from the schema, and the group_id-over-recipient precedence. It stops short of 5 only because most of this is a restatement plus modest additions.

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: setting/disabling the disappearing-messages timer for a 1:1 or group chat. It distinguishes itself from neighbors by naming update_group as the equivalent path for groups, so an agent can route without opening another schema.

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 clear selection rules for its two addressing modes (recipient vs group_id, with group_id winning) and explicitly tells the agent that update_group with expiration_seconds is the equivalent operation. It lacks an explicit 'do not use when...' exclusion, 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.

Deploy Server

Other Tools