Skip to main content
Glama
Dominic-DK

Askew

by Dominic-DK
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

askew_notify

Send a lock-screen notification to phone and Apple Watch, preserving full text in results box. Use title for clear text, body for short visible line, content for long text; replies not supported.

Instructions

Send a lock-screen notification to the user's phone (mirrored to Apple Watch) and keep the full text in the app's results box. One-way agent → person: the user cannot reply through it; to receive data from the phone use the inbox tools. title is sent in clear text, body and content are end-to-end encrypted. Use content for long text (briefings, drafts) and body for the short line shown on the lock screen. Returns the delivery ids. Use ref to group related notifications.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNoOptional reference (≤200 chars) to group deliveries in the results box, e.g. 'morning-briefing' or an inbox item id you are answering.
bodyNoShort notification body shown on the lock screen and Apple Watch. End-to-end encrypted; the relay only carries an encrypted hint.
titleYesNotification title, 1–200 chars. Sent to the phone in clear text, so keep sensitive details in body/content.
contentNoLonger text kept in the app's results box (e.g. a full briefing or draft). End-to-end encrypted. Markdown is shown as plain text.
deviceIdNoSend to one device only (id from askew_list_routes). Default: every registered device.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / body / description
      Added value: +"Short notification body shown on the lock screen and Apple Watch. End-to-end encrypted; the relay only carries an encrypted hint."
    • addedInput schema / properties / content / description
      Added value: +"Longer text kept in the app's results box (e.g. a full briefing or draft). End-to-end encrypted. Markdown is shown as plain text."
    • addedInput schema / properties / deviceId / description
      Added value: +"Send to one device only (id from askew_list_routes). Default: every registered device."
    • addedInput schema / properties / ref / description
      Added value: +"Optional reference (≤200 chars) to group deliveries in the results box, e.g. 'morning-briefing' or an inbox item id you are answering."
    • addedInput schema / properties / title / description
      Added value: +"Notification title, 1–200 chars. Sent to the phone in clear text, so keep sensitive details in body/content."
  2. First observedv0.1.2

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden and succeeds: it reveals one-way delivery, Apple Watch mirroring, clear-text `title`, end-to-end encryption for `body` and `content`, and that delivery ids are returned. These are behavioral facts an agent needs beyond the schema.

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?

Four dense sentences front-load the core action and then layer security, field guidance, return value, and grouping without filler. Every sentence earns its place.

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?

Given the tool's complexity, no annotations, and no output schema, the description is remarkably complete: it covers routing, encryption, one-way nature, return value, and `ref` grouping. The only omitted details, like auth or error behavior, are not essential for an agent to call this notify tool correctly.

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 description coverage is 100%, so the baseline is 3. The description reinforces role distinctions between `body` and `content` and warns about `title` being clear text, but these are already present in the schema's parameter descriptions—so the added semantic value is modest.

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?

The description opens with a specific verb and resource: sending a lock-screen notification to the user's phone and keeping full text in the app's results box. It clearly separates this send-oriented tool from the sibling inbox tools by framing it as one-way agent-to-person communication.

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?

It explicitly states when-not to use this tool ('the user cannot reply through it') and names the alternative for the opposite direction ('to receive data from the phone use the inbox tools'). It also gives practical field-selection guidance: use `content` for long text and `body` for the short lock-screen line.

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