Skip to main content
Glama

send_note_to_self

Send a message to your own Note to Self chat in Signal for reminders, bookmarks, or drafts; it syncs to all linked devices.

Instructions

Send a message to your own Note to Self chat; it syncs to all your linked Signal devices. Use for reminders, bookmarks or drafts; use send_message to message anyone else. message always supports bold, italic, strikethrough, monospace, ||spoiler|| (markers become Signal formatting) — e.g. a bold title per note. attachments: list of local file paths (e.g. a QR code); voice_note=true marks audio as a voice note. To thread a follow-up under an earlier note pass quote_author (your own number) + quote_timestamp (from a prior send_note_to_self result); quote_message, quote_mentions, quote_text_styles, quote_attachments optionally shape the quote bubble. Link preview card: preview_url (must also appear in the text), preview_title (needed for the card to render), preview_description, preview_image (local file). no_urgent=true sends without a push notification; notify_self=true delivers a normal notifying message if you are among the recipients. Combine content in one call rather than several. Not idempotent; shares the 20-sends-per-minute rate limit. Saved to the local store. Returns {status, timestamp}.

Input Schema

NameRequiredDescriptionDefault
messageYesNote text to save. Supports **bold**, *italic*, ~~strikethrough~~, `monospace`, ||spoiler||
no_urgentNoSend without the urgent flag, so the recipient gets no push notification
voice_noteNoMark audio attachments as voice notes (played inline in Signal)
attachmentsNoFile paths to attach (e.g. a QR code or screenshot)
notify_selfNoIf you are among the recipients, deliver as a normal (notifying) message instead of a silent sync message
preview_urlNoURL for a link preview card; the same URL must also appear in the message text
quote_authorNoYour own account number, to thread this note under a previous one
preview_imageNoLocal image file for the link preview thumbnail
preview_titleNoLink preview title (needed for the card to render)
quote_timestampNoTimestamp of the note being followed up on (from a prior send_note_to_self result)
preview_descriptionNoLink preview description

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.42.0
    • changedInput schema / properties / message / description
      Previous value: -"Note text to save. Supports **bold**, ~~strikethrough~~, `monospace`"New value: +"Note text to save. Supports **bold**, *italic*, ~~strikethrough~~, `monospace`, ||spoiler||"
  2. Changed7 schema fields changedv1.40.1
    • addedInput schema / properties / no_urgent
      Added value: +{
      +  "default": false,
      +  "description": "Send without the urgent flag, so the recipient gets no push notification",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / notify_self
      Added value: +{
      +  "default": false,
      +  "description": "If you are among the recipients, deliver as a normal (notifying) message instead of a silent sync message",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / preview_description
      Added value: +{
      +  "description": "Link preview description",
      +  "type": "string"
      +}
    • addedInput schema / properties / preview_image
      Added value: +{
      +  "description": "Local image file for the link preview thumbnail",
      +  "type": "string"
      +}
    • addedInput schema / properties / preview_title
      Added value: +{
      +  "description": "Link preview title (needed for the card to render)",
      +  "type": "string"
      +}
    • addedInput schema / properties / preview_url
      Added value: +{
      +  "description": "URL for a link preview card; the same URL must also appear in the message text",
      +  "type": "string"
      +}
    • addedInput schema / properties / voice_note
      Added value: +{
      +  "default": false,
      +  "description": "Mark audio attachments as voice notes (played inline in Signal)",
      +  "type": "boolean"
      +}
  3. Changed4 schema fields changedv1.34.1
    • addedInput schema / properties / attachments
      Added value: +{
      +  "description": "File paths to attach (e.g. a QR code or screenshot)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / message / description
      Previous value: -"Note text to save"New value: +"Note text to save. Supports **bold**, ~~strikethrough~~, `monospace`"
    • addedInput schema / properties / quote_author
      Added value: +{
      +  "description": "Your own account number, to thread this note under a previous one",
      +  "type": "string"
      +}
    • addedInput schema / properties / quote_timestamp
      Added value: +{
      +  "description": "Timestamp of the note being followed up on (from a prior send_note_to_self result)",
      +  "type": "integer"
      +}
  4. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false), and the description adds real context beyond them: the 20-sends-per-minute rate limit, local-store persistence, syncing across linked devices, and the {status, timestamp} return shape. 'Not idempotent' merely restates the annotation, but the rate-limit and persistence details are genuine additions.

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?

Purpose and the key routing decision are front-loaded, and the dense sentences each carry distinct information (formatting, attachments, quoting, previews, notifications, rate limit). It is long for one description, but little is wasted.

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?

For an 11-parameter mutation tool, the definition covers routing, formatting, side effects (rate limit, local persistence), the return value, and quoting/link-preview mechanics. Nothing essential to a correct call is missing despite the absence of an output schema.

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%, so the schema already documents all 11 parameters, and most of the description's per-parameter prose (preview_url must appear in text, preview_title needed to render, quote_author being your own number) duplicates it. It adds only marginal meaning, e.g. how quote_author plus quote_timestamp combine to thread a follow-up.

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 precise verb and resource ('Send a message to your own Note to Self chat') and immediately distinguishes it from the sibling send_message. An agent can select it against send_message/send_group_message 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?

Explicitly names the intended uses (reminders, bookmarks, drafts) and the alternative ('use send_message to message anyone else'). Guidance about combining content in one call also shapes invocation, so both when and how are covered.

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