Skip to main content
Glama

Set a post alarm

set_post_alarm

Sets an alarm that rings on the person's phone when an X account posts something matching what the person described, or when a Twitch or YouTube channel goes live or posts a video. For an account's posts or streams; a token's price, a trader's trades and an event link are different alarms. watch_for applies to X only (LFG reads each new post against it); moment applies to Twitch and YouTube only. A channel name that cannot be found returns an error. Returns the alarm and its link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoA note from the person about the alarm, in their words, shown under its trigger on the alarm's page and in the Daily drop. Up to 500 characters; an empty note clears it.
vibeNoThe feel of the alarm in a few words, "fun poppy anime", "calm", "a simple bell", "hype for a token launch". LFG picks a sound and a drawn look from its library to match; wallpaper words or colours given here win over the look.
reachNoWho can join: private (only the person), friends (people on its list, or with its link), public (anyone; listed in Discover).private
themeNoA picture theme: the alarm gets one of the theme's pictures as its wallpaper and a song in its moods, and a new alarm a title written for it. A wallpaper, title or vibe given as well is kept instead. One of: birthday (Birthday), love (Love), night_out (Night out), shopping (Shopping), winter (Winter), christmas (Christmas), hanukkah (Hanukkah), diwali (Diwali), halloween (Halloween), thanksgiving (Thanksgiving), friendsgiving (Friendsgiving), new_years (New Year's Eve).
titleNoShort name for the alarm. When absent, LFG names it.
momentNoFor Twitch or YouTube: going live, or posting a video. Twitch defaults to live.
accountYesThe account's handle or profile link, "elonmusk" or "https://x.com/elonmusk".
platformNoWhere the account is.x
surpriseNoFor a friends alarm: keep it a surprise. People who join see a curtain instead of its title, picture, sound and note until it rings. Free on every plan.
watch_forNoFor X: what in a post should ring the alarm, in plain words, "any post about a new token" or "anything at all". Not used for Twitch or YouTube.
add_groupsNoFor a friends alarm: names of the person's friend groups whose members to let in, "Family". Members get a notification.
add_peopleNoFor a friends alarm: up to 20 people to let in, as usernames of the person's LFG friends or as email addresses. Friends get a notification; an email address with no LFG account gets an invitation. Any other username is refused.
button_linkNo
words_colorNoColour of the words as hex, "#D7FF00".
hide_triggerNoNeeded with surprise, true or false: whether to also keep back when and why it rings, so people who join only know that it will. A surprise is not made until it is given.
snooze_timesNoHow many times it can be snoozed: 3, 10 or unlimited.
silent_snoozeNotrue to snooze without the spoken roast LFG plays by default.
snooze_minutesNoMinutes each snooze lasts: 5, 10, 15, 30 or 60.
wallpaper_colorNoWallpaper background colour as hex, "#5B2BFF".
wallpaper_wordsNoWords drawn on the wallpaper, "WAKE UP"; a line break starts a new line.
people_confirmedNoWhether the person has confirmed the people and groups being added. Nobody is added or told without it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, open-world, non-idempotent write. The description adds useful context beyond them: a nonexistent channel returns an error, the return is the alarm and its link, and the watch_for/moment parameters are platform-scoped. It does not address permissions, side effects on existing alarms, or rate limits, but the annotation coverage lowers the bar.

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?

Front-loads the core behavior (what rings the alarm and for which platforms) before moving to differentiation and platform-scoped caveats. Each sentence carries distinct information with no filler, though the platform-scoping sentence is slightly dense and could be tighter.

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 supplies the missing return information (the alarm and its link) plus error behavior for unresolvable channels. With 21 parameters at 95% schema coverage and a clear platform/trigger model, an agent has enough to select and invoke this tool correctly.

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 95%, so parameter meaning is largely carried by the schema, but the description contributes cross-field semantics the schema does not state: watch_for is honored only for X, and moment only for Twitch/YouTube. That conditional coupling between the account/platform parameter and the trigger parameters is genuinely additive.

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 (sets an alarm) plus the exact trigger condition (X account posts something matching, Twitch/YouTube goes live or posts a video). It explicitly distinguishes itself from the sibling alarm tools by naming the other alarm domains: "a token's price, a trader's trades and an event link are different alarms."

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?

Clearly states the condition under which this alarm applies (X posts, Twitch/YouTube live/video) and routes other cases away from it by naming the competing alarm categories. It also states per-platform applicability of watch_for and moment. It stops short of naming the sibling tools (set_price_alarm, etc.) directly, so the routing is category-level rather than tool-level.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources