Skip to main content
Glama
tmgr-dev

tmgr-notify

Official
by tmgr-dev

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TMGR_URLNoAPI base URL, default https://api.tmgr.dev. Override it for a self-hosted or local TMGR. A base that already ends in /api is normalized.https://api.tmgr.dev
TMGR_NOTIFY_TOKENYesThe tmgrn_... token. Sent as Authorization: Bearer <token>.
TMGR_NOTIFY_STOP_MIN_MINUTESNoMinimum turn duration in minutes before hook stop sends a "finished" push. Default 5.5

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
notify_userC

Send a phone push notification to the user via TMGR agent notifications.

alarmA

Only for incidents that need the human NOW (production down, data loss, security). Rings the owner's phone: silent push to the app alarm, then a voice call if not acknowledged. Prefer notify_user for everything else. Calls repeat up to callAttempts times (default 3) until acknowledged. You decide when/whether to retry; one call = one escalation.

alarm_statusA

Check an alarm created by the alarm tool. With waitSeconds (max 50) it long-polls until the status changes. Use it to re-check after the alarm call timed out or was started with waitForResult=false.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation4/5

notify_user and alarm both push to the user's phone, so there is some surface overlap, but the descriptions sharply delineate when to use each (routine vs. urgent incident escalation). alarm_status is clearly a distinct read/check operation tied to the alarm tool.

Naming Consistency3/5

notify_user follows a verb_noun pattern, but alarm is a bare noun and alarm_status is noun_noun. The convention is mixed, though all names remain readable and inferable from their descriptions.

Tool Count4/5

Three tools is a tight, well-scoped set for a notification/escalation service: one soft notify, one hard escalation, one status check. It is slightly lean but each tool clearly earns its place.

Completeness3/5

The core lifecycle (notify, escalate, check status) is covered, but there is no tool to cancel/resolve an alarm, explicitly acknowledge it, or list past notifications/alarms. Agents must rely on out-of-band phone interaction to close out an escalation.