Skip to main content
Glama

Create a Custom Alert

alerts_create_custom

Creates a Custom Alert in the signed-in member's account from an indicator's condition on one market and timeframe: either a Vela built-in indicator (indicator: RSI crosses above 70, MACD crosses above its signal line, price crosses below the lower Bollinger Band…) or an open-source LuxAlgo Library indicator (library: its slug, from library_search, firing on one of its alert conditions or on its alerts). It first replays the alert over recent history and says how often it would have fired ("12 times, about 0.4 per day"); with preview_only it stops there and creates nothing, which is the way to try a condition before the member decides. Paid Library indicators cannot run as alerts. It notifies the member in-app when the account has that channel; the result says plainly which channel it notifies, or that it notifies no one. Previews are limited to about 10 a minute. Use alerts_create_price for a plain price level. How many alerts the member may have on comes from their LuxAlgo plan: at a limit the call answers with the limit and where to upgrade, and nothing is created. It changes the member's account, so the chat app may ask the user to confirm first. Requires signing in with a LuxAlgo account (OAuth).

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": {
      "symbol": "<symbol>",
      "context": "<context>"
    },
    "name": "alerts_create_custom"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoThe alert's name; default describes the condition.
symbolYesThe market, a market as source:TICKER, e.g. "binance:BTCUSDT", "hyperliquid:BTC", "coinbase:BTC-USD", "edgx:AAPL" (US stocks and ETFs; "NASDAQ:AAPL" works too), "fx:EURUSD", "commodities:XAUUSD", "cme:ES1!". A bare stablecoin pair ("BTCUSDT") is read as Binance and a bare "ES1!" as CME.
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
libraryNo
frequencyNoHow often it fires: once (then it stops), once_per_bar (at most once per bar of `timeframe`), once_per_bar_close (when a bar of `timeframe` closes with the condition met), every_time (each time, spaced by min_interval_seconds).once_per_bar_close
indicatorNo
timeframeNoThe bars the indicator runs on.1h
preview_onlyNoOnly replay it over history and say how often it would have fired; create nothing.
min_interval_secondsNoevery_time only: the least time between two fires, in seconds (default 60).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only supply readOnlyHint=false and destructiveHint=false, so the description does the heavy lifting and delivers: historical replay preview with a sample output, in-app notification behavior including the 'notifies no one' case, a preview rate limit of about 10/minute, and a plan-limit response that creates nothing. It slightly undersells the failure/partial paths but covers far more than the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, which is good, but it is a single dense run-on paragraph mixing creation semantics, preview output, notification channels, rate limits, plan limits, auth, and confirmation. Every fact is useful, yet the lack of sectioning makes it harder to scan for a long-schema tool.

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?

For a 9-parameter tool with nested objects and no output schema, the description covers the otherwise-missing return semantics (replay frequency message, which channel notifies or none), an alternative tool, auth, rate limits, and account-limit behavior. An agent has enough to call this correctly and safely.

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 78%, so the baseline is a 3, and the description earns the bump by explaining the indicator-vs-library branching, that settings use Vela's names and default when omitted, and that `than` can be a number, 'price', or another line. It does not extend parameter meaning much beyond that.

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 ('Creates a Custom Alert') plus the exact trigger model: an indicator condition on one market and timeframe. It explicitly separates the two indicator sources (Vela built-in `indicator` vs LuxAlgo Library `library`) and names a sibling, alerts_create_price, for the plain price case.

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?

Gives explicit routing ('Use alerts_create_price for a plain price level') and a concrete recommended workflow: run with `preview_only` to try a condition before the member commits. It also states prerequisites (OAuth sign-in, paid Library indicators cannot run as alerts) and what happens at a plan limit.

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.