Skip to main content
Glama

LFG Alarm

by gm.lfg
OverviewDiscussionsAdmin

Set an event alarm

set_event_alarm

Sets an alarm for an event from its Luma or Partiful link: LFG reads the event's name, start time, place, picture and description, and the alarm rings that long before it starts. Only for Luma and Partiful event links; any other moment on the clock is a time alarm. The picture becomes its wallpaper, the event page its button link, and the description its note unless a note is given. A link whose start time cannot be read, or an event too soon for the chosen lead, returns an error. Returns the alarm and its link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linkYesThe event's Luma or Partiful link.
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, the event's name. Up to 60 characters; it reads best under about 25.
sourceNoThe event in another app this alarm is for, such as a meeting in the person's calendar. With the same source again, the person's existing alarm for it is changed (its time and title) instead of a second one being made.
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.
time_zoneYesThe person's IANA time zone, "America/New_York".
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
ring_beforeNoHow long before the start the alarm rings.1_hour
words_colorNoColour of the words as hex, any colour, "#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, any colour, "#5B2BFF".
wallpaper_wordsNoWords drawn on the wallpaper, "WAKE UP"; a line break starts a new line. Up to 40 characters; it looks best as 1 to 4 short words, since the words are drawn as large as the square allows.
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. Changed1 schema field changed
    • changedInput schema / properties / words_color / description
      Previous value: -"Colour of the words as hex, any colour, \"#D7FF00\". Pick one that stands out from the background."New value: +"Colour of the words as hex, any colour, \"#D7FF00\"."
  2. Changed6 schema fields changed
    • changedInput schema / properties / title / description
      Previous value: -"Short name for the alarm. When absent, the event's name."New value: +"Short name for the alarm. When absent, the event's name. Up to 60 characters; it reads best under about 25."
    • changedInput schema / properties / title / maxLength
      Previous value: -120New value: +60
    • changedInput schema / properties / wallpaper_color / description
      Previous value: -"Wallpaper background colour as hex, \"#5B2BFF\"."New value: +"Wallpaper background colour as hex, any colour, \"#5B2BFF\"."
    • changedInput schema / properties / wallpaper_words / description
      Previous value: -"Words drawn on the wallpaper, \"WAKE UP\"; a line break starts a new line."New value: +"Words drawn on the wallpaper, \"WAKE UP\"; a line break starts a new line. Up to 40 characters; it looks best as 1 to 4 short words, since the words are drawn as large as the square allows."
    • changedInput schema / properties / wallpaper_words / maxLength
      Previous value: -80New value: +40
    • changedInput schema / properties / words_color / description
      Previous value: -"Colour of the words as hex, \"#D7FF00\"."New value: +"Colour of the words as hex, any colour, \"#D7FF00\". Pick one that stands out from the background."
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only cover safety/idempotency (readOnly=false, destructive=false, idempotent=false, openWorld=true); the description goes further by disclosing what is scraped from the link, how event data maps onto wallpaper/button/note, and two concrete failure modes (unreadable start time, event too soon for the chosen lead). It still omits auth requirements, rate limits, and what happens to a pre-existing alarm for the same link.

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?

Four sentences, front-loaded with the core action and scope before the derivation rules, error cases and return value. Dense but no obvious filler; a touch of the mapping detail arguably belongs in the field docs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 21-parameter, nested-object, no-output-schema tool, the description covers purpose, scope, derived defaults, failure modes and the return value ('Returns the alarm and its link'), which is what an agent needs at selection time. The elaborate friends/surprise/theme mechanics are left to the schema, which is appropriate.

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 95% across 21 parameters, so the schema already carries the semantics and a 3 is the baseline. The description only adds cross-parameter defaulting for a couple of fields (event description becomes the note unless a note is given; event page becomes the button link), which is genuinely useful but thin against the parameter set.

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 ('Sets an alarm for an event from its Luma or Partiful link') and immediately scopes it against the sibling family: 'any other moment on the clock is a time alarm.' An agent can distinguish this from set_time_alarm, set_trader_alarm and set_post_alarm without opening any 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 a clear inclusion rule ('Only for Luma and Partiful event links') and routes the out-of-scope case to the time alarm alternative. It does not name the sibling tool precisely (set_time_alarm) nor mention the other alarm-setting siblings, so routing is clear but not fully exhaustive.

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

All LFG Alarm toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources