Skip to main content
Glama
Sign In

LFG Alarm

by gm.lfg
OverviewDiscussionsAdmin

Join an alarm

join_alarm
Idempotent

Joins someone else's alarm from its link or code, so it rings on the person's phone too. For an alarm someone else made, by its link or code; a referral code is not an alarm. A friends alarm the person is not on can't be joined; with ask set, its creator is sent a request to let them in. An alarm that already rang for the last time can't be joined. Returns the alarm's name, creator and when it rings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "link": "<link>"
    },
    "name": "join_alarm"
  }
}

Input Schema

NameRequiredDescriptionDefault
askNoFor a friends alarm the person is not on: send its creator a request to let them in.
linkYesThe alarm's link (lfg.gm/a/...), the message it came in, or its code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare idempotent/not-destructive/openWorld; the description goes well beyond them by disclosing the side effect on a third party (the creator receives a join request), the eligibility failures (not-yet-a-friend, alarm already expired), and the returned fields. That is exactly the external-effect context annotations cannot carry.

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?

The core effect is front-loaded and no sentence is filler. However the phrasing is fragmented and slightly repetitive (the link/code clause appears twice), which costs a point on structure.

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?

With no output schema, the description usefully states what is returned, and it covers the main failure modes. It leaves minor gaps: what happens if the person already joined the alarm, and whether joining requires any existing relationship beyond the ask flow.

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 already 100%, so baseline is 3; the description still adds meaning by clarifying that the identifier may be a link, an incoming message, or a code, and by ruling out referral codes. It does not explain the interaction between ask and link further, so not a 5.

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 first sentence gives a precise verb, resource and observable effect ('joins someone else's alarm... so it rings on the person's phone too'), which is genuinely different from the set_*_alarm siblings that create one's own alarms. It also separates itself from use_invite_code by noting 'a referral code is not an alarm'. An agent can pick this tool 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('for an alarm someone else made, by its link or code') and explicit when-not ('a referral code is not an alarm', 'an alarm that already rang for the last time can't be joined'). It also explains the escalation path via the ask parameter when the person isn't on a friends alarm.

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