Skip to main content
Glama
Sign In

LFG Alarm

by gm.lfg
OverviewDiscussionsAdmin

Add your own rule to a stack

set_stack_trigger

Adds the person's own rule to someone else's alarm (a stack) from its link: when the rule comes true, it rings the person's phone alone, never the other riders. For "I like this alarm but only tell me when..." on a link the person pasted. The rule has to read what the stack already watches; a rule that needs another page, account or wallet watched, or faster checks, is refused with why (that would be the stack's own copy, which is coming). Joins the alarm when the person is not on it yet. Returns what was added and the alarm.

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>",
      "rule": "<rule>"
    },
    "name": "set_stack_trigger"
  }
}

Input Schema

NameRequiredDescriptionDefault
linkYesThe alarm's link (lfg.gm/a/...), the message it came in, or its code.
ruleYesThe rule in the person's words: "only when three of these wallets buy the same token within 30 minutes", "ring me at $200 instead".
quietNotrue when the rule should not ring: what it finds lands in the daily drop instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations cover safety (readOnly=false, destructive=false, openWorld=true, idempotent=false), and the description adds real context beyond them: the rule rings only the owner's phone and never other riders, out-of-scope rules are refused with a reason, and the call auto-joins the alarm as a side effect. That side effect and the refusal semantics are not recoverable from the annotations alone.

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-loaded with the core action and scope, then layered constraints; no filler sentences. Slightly dense with parentheticals ('a stack', 'that would be the stack's own copy, which is coming') that cost a little scanability.

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?

No output schema exists, and the description compensates by stating what is returned ('what was added and the alarm') plus the failure mode for ineligible rules. What remains unstated is how a partially valid rule is reported or how the added rule is identified on the returned alarm, but nothing critical to invoking it is missing.

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 100%, so the baseline is 3, but the description adds genuine semantics: the 'link' must be one the person pasted, and the 'rule' is constrained to what the stack already watches, with faster checks or extra sources refused. These constraints tell the agent how to shape input in ways maxLength/minLength cannot.

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 ('Adds the person's own rule to someone else's alarm (a stack) from its link'), with a clarifying scope that separates it from the set_*_alarm siblings that create one's own alarm. The 'someone else's' framing immediately distinguishes it from remix_alarm and set_price_alarm.

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 concrete trigger scenario ('I like this alarm but only tell me when...' on a link the person pasted) and an eligibility constraint (the rule must read what the stack already watches). It also tells the agent what happens when the person isn't yet on the alarm ('Joins the alarm when the person is not on it yet'), implicitly covering the join_alarm overlap, but never names an explicit alternative tool or exclusion.

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