Skip to main content
Glama

Alerts Edit

alerts_edit
Destructive

Partial update of one of the user's alerts. Only the fields you pass are modified; pass alert_id to identify which one (get it from alerts_list). Use is_active=false to pause an alert without deleting it. address replaces the alert's wallet condition (one per alert; same rules as alerts_create); address='' removes it; address_role alone moves the existing address to that side. The fields mean what they mean in alerts_create, and a Hyperliquid alert (its type cannot change) is re-validated whole after the edit: '' or [] clears an optional field such as token_symbol or pnl_cohorts, and a field its type does not use is an error. channels replaces the list (email or webhook; Discord is off); [] leaves a Hyperliquid or Polymarket alert feed-only, read with alerts_events.

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": {
      "alert_id": "<alert_id>"
    },
    "name": "alerts_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
bandNohl_cohort_bias and hl_liq_proximity: hysteresis, greater than 0 (default 0.1). A bias alert fires when the index reaches threshold + band (up) or threshold - band (down); a proximity alert fires when the ratio reaches threshold and re-arms below threshold - band.
chainNo
indexNohl_cohort_bias only, required: the index watched for token_symbol. smi = long share of smart wallets minus long share of rekt wallets; wsi = long share of whales minus long share of shrimp; smart_bias / whale_bias = (long - short) / (long + short) of that cohort; smi_wsi_gap = smi - wsi. Ratios run -1..1 (smi_wsi_gap -2..2).
labelNo
walletNoOne 0x + 40-hex address. Hyperliquid: the account to watch, required for hl_wallet and hl_liq_proximity, optional for hl_liquidation. Polymarket: the proxy wallet (the address of its vike.io/polymarket/wallet page and of polymarket_tape rows), required for pm_wallet_trade.
actionsNohl_wallet only: which fills notify. Default: open, close, flip, increase ('add' is accepted for increase); reduce is opt-in.
addressNo0x + 40-hex EVM address; '' removes the wallet condition.
alert_idYesThe alert ID (from alerts_list).
channelsNo
directionNohl_cohort_bias: which crossings notify. pm_price_move: which moves of the market's first outcome (Yes on a yes/no market) notify. Default both.
is_activeNo
thresholdNohl_cohort_bias: the index level to cross (default 0). hl_liq_proximity: the share of the way from entry price to liquidation price, strictly between 0 and 1 (default 0.8).
min_amountNoWhole tokens of token_symbol; '' or 0 removes the amount floor.
pnl_cohortsNohl_cohort_fill and hl_liquidation: only wallets in these realised-PnL cohorts (the ladder runs from '3x smart' = top 1% to '3x rekt' = bottom 5%). hl_cohort_fill REQUIRES at least one PnL or size cohort; for hl_liquidation empty = any cohort.
address_roleNo
condition_idNoPolymarket only: the market, its 0x + 64-hex condition id. Required for pm_market_trade, pm_price_move and pm_resolution; optional for pm_wallet_trade (one market of that wallet).
size_cohortsNohl_cohort_fill and hl_liquidation: only wallets in these account-size cohorts (the ladder runs from '4x whale' = $10M+ to 'shrimp' = under $1k). hl_cohort_fill REQUIRES at least one PnL or size cohort; for hl_liquidation empty = any size.
token_symbolNo
max_value_usdNo
min_value_usdNo
cooldown_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / min_amount
      Added value: +{
      +  "description": "Whole tokens of token_symbol; '' or 0 removes the amount floor.",
      +  "type": [
      +    "number",
      +    "string"
      +  ]
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / condition_id
      Added value: +{
      +  "description": "Polymarket only: the market, its 0x + 64-hex condition id. Required for pm_market_trade, pm_price_move and pm_resolution; optional for pm_wallet_trade (one market of that wallet).",
      +  "type": "string"
      +}
    • changedInput schema / properties / direction / description
      Previous value: -"hl_cohort_bias only: which crossings notify. Default both."New value: +"hl_cohort_bias: which crossings notify. pm_price_move: which moves of the market's first outcome (Yes on a yes/no market) notify. Default both."
    • changedInput schema / properties / wallet / description
      Previous value: -"Hyperliquid account to watch: one 0x + 40-hex address. Required for hl_wallet and hl_liq_proximity, optional for hl_liquidation."New value: +"One 0x + 40-hex address. Hyperliquid: the account to watch, required for hl_wallet and hl_liq_proximity, optional for hl_liquidation. Polymarket: the proxy wallet (the address of its vike.io/polymarket/wallet page and of polymarket_tape rows), required for pm_wallet_trade."
  3. Changed9 schema fields changed
    • addedInput schema / properties / actions
      Added value: +{
      +  "description": "hl_wallet only: which fills notify. Default: open, close, flip, increase ('add' is accepted for increase); reduce is opt-in.",
      +  "items": {
      +    "enum": [
      +      "open",
      +      "close",
      +      "flip",
      +      "increase",
      +      "reduce"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / band
      Added value: +{
      +  "description": "hl_cohort_bias and hl_liq_proximity: hysteresis, greater than 0 (default 0.1). A bias alert fires when the index reaches threshold + band (up) or threshold - band (down); a proximity alert fires when the ratio reaches threshold and re-arms below threshold - band.",
      +  "type": [
      +    "number",
      +    "string"
      +  ]
      +}
    • changedInput schema / properties / channels / items / enum
      Previous value: -[
      -  "email",
      -  "discord"
      -]New value: +[
      +  "email",
      +  "webhook"
      +]
    • addedInput schema / properties / direction
      Added value: +{
      +  "description": "hl_cohort_bias only: which crossings notify. Default both.",
      +  "enum": [
      +    "up",
      +    "down",
      +    "both"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / index
      Added value: +{
      +  "description": "hl_cohort_bias only, required: the index watched for token_symbol. smi = long share of smart wallets minus long share of rekt wallets; wsi = long share of whales minus long share of shrimp; smart_bias / whale_bias = (long - short) / (long + short) of that cohort; smi_wsi_gap = smi - wsi. Ratios run -1..1 (smi_wsi_gap -2..2).",
      +  "enum": [
      +    "smi",
      +    "wsi",
      +    "smart_bias",
      +    "whale_bias",
      +    "smi_wsi_gap"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / pnl_cohorts
      Added value: +{
      +  "description": "hl_cohort_fill and hl_liquidation: only wallets in these realised-PnL cohorts (the ladder runs from '3x smart' = top 1% to '3x rekt' = bottom 5%). hl_cohort_fill REQUIRES at least one PnL or size cohort; for hl_liquidation empty = any cohort.",
      +  "items": {
      +    "enum": [
      +      "3x smart",
      +      "2x smart",
      +      "smart",
      +      "3x winner",
      +      "2x winner",
      +      "winner",
      +      "loser",
      +      "2x loser",
      +      "3x loser",
      +      "rekt",
      +      "2x rekt",
      +      "3x rekt"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / size_cohorts
      Added value: +{
      +  "description": "hl_cohort_fill and hl_liquidation: only wallets in these account-size cohorts (the ladder runs from '4x whale' = $10M+ to 'shrimp' = under $1k). hl_cohort_fill REQUIRES at least one PnL or size cohort; for hl_liquidation empty = any size.",
      +  "items": {
      +    "enum": [
      +      "4x whale",
      +      "3x whale",
      +      "2x whale",
      +      "whale",
      +      "2x shark",
      +      "shark",
      +      "2x dolphin",
      +      "dolphin",
      +      "2x fish",
      +      "fish",
      +      "2x shrimp",
      +      "shrimp"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / threshold
      Added value: +{
      +  "description": "hl_cohort_bias: the index level to cross (default 0). hl_liq_proximity: the share of the way from entry price to liquidation price, strictly between 0 and 1 (default 0.8).",
      +  "type": [
      +    "number",
      +    "string"
      +  ]
      +}
    • addedInput schema / properties / wallet
      Added value: +{
      +  "description": "Hyperliquid account to watch: one 0x + 40-hex address. Required for hl_wallet and hl_liq_proximity, optional for hl_liquidation.",
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the destructiveHint and non-idempotent annotations, the description explains exactly what changes: only passed fields are modified, address='' removes the wallet condition, '' or [] clears optional fields, channels replaces the entire list, and Hyperliquid alerts are re-validated whole after the edit. It also discloses that an alert type cannot change and that using a field the type does not support is an error.

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 description is dense but front-loaded with the key purpose and partial-update rule. Every sentence contributes operational detail, though the long paragraph could be easier to scan if split into short bullets for clearing rules, channel behavior, and validation behavior.

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 complex 21-parameter mutation tool with no output schema, the description covers the highest-risk behaviors: partial updates, field clearing, list replacement, address handling, Hyperliquid revalidation, and feed-only alerts. It relies on alerts_create for many field definitions, which is reasonable, but an agent still needs that sibling context to understand every parameter.

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 only 57%, so some parameters lack descriptions, but the description adds important meaning for mutation semantics: address replacement and removal, address_role moving the existing address, channels replacement, empty-array clearing, and alert_id sourcing from alerts_list. It also efficiently delegates unchanged field meanings to alerts_create, though parameters such as chain, label, max_value_usd, and cooldown_minutes remain unexplained.

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 description opens with a specific verb and resource: 'Partial update of one of the user's alerts.' It immediately clarifies the partial-update semantics and distinguishes the tool from creation, deletion, and read siblings by focusing on modifying existing alert fields.

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?

It gives clear usage context: pass alert_id from alerts_list, use is_active=false to pause without deleting, and consult alerts_create for field meanings. It does not explicitly say when to choose this over alerts_create or alerts_delete, but the partial-update framing and pause alternative provide strong practical guidance.

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.