Skip to main content
Glama
Sign In

LFG Alarm

by gm.lfg
OverviewDiscussionsAdmin

Find a prediction market

find_market
Read-onlyIdempotent

Finds open prediction markets on Polymarket and Novig by words or by a pasted Polymarket or Novig link. Novig is sports only. A Kalshi or sportsbook link (DraftKings, FanDuel) finds the same event on those two. For looking up a market before a price alarm on its odds; it sets nothing. Returns up to 4 events, each with its open markets and every outcome's current odds and the token id, outcome and question a price alarm takes. No match returns a note.

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": {
      "query": "<query>"
    },
    "name": "find_market"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesWhat they are waiting on, "fed cuts in december", "T1 vs Bilibili", or a polymarket.com, novig, kalshi.com or sportsbook link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"What they are waiting on, \"fed cuts in december\", \"T1 vs Bilibili\", or a polymarket.com, kalshi.com or novig link."New value: +"What they are waiting on, \"fed cuts in december\", \"T1 vs Bilibili\", or a polymarket.com, novig, kalshi.com or sportsbook link."
  2. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"What they are waiting on, \"fed cuts in december\", \"T1 vs Bilibili\", or a polymarket.com or kalshi.com link."New value: +"What they are waiting on, \"fed cuts in december\", \"T1 vs Bilibili\", or a polymarket.com, kalshi.com or novig link."
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent and non-destructive behavior, yet the description still adds real context: it caps results at 4 events, describes the payload shape (open markets, per-outcome odds, the token id/outcome/question a price alarm consumes), and defines the no-match case. The explicit 'it sets nothing' removes any ambiguity about side effects.

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?

Content is front-loaded on what it finds and by what inputs, with return details last; nearly every clause carries information. The sentence 'For looking up a market before a price alarm on its odds; it sets nothing' is clipped and grammatically awkward, slightly hurting scannability.

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?

With no output schema, the description carries the return burden and does: result cap, contents, ID fields needed downstream, and the empty-result note. Combined with a single fully documented parameter and complete annotations, nothing an agent needs to invoke it correctly 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 already 100%, so the baseline would be 3; the description earns above that by explaining that the query accepts free words or a pasted link and that Kalshi or sportsbook (DraftKings, FanDuel) URLs are translated to the same event on the two supported venues. That link-translation rule is meaningful semantics the schema field text does not spell out.

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 ('Finds open prediction markets') and names both supported venues, Polymarket and Novig, with the qualifier that Novig is sports only. It also clarifies an input mode siblings do not share, the pasted market link, so an agent can separate it from find_lottery or find_token without inspecting the 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?

'For looking up a market before a price alarm on its odds; it sets nothing' gives a concrete when-to-use plus a when-not, steering the agent away from alarm-setting tools and toward a later alarm call. It stops short of naming the alarm sibling explicitly and does not cover cases where a keyword search would be preferable to a link.

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