Skip to main content
Glama

Watch & alert: price, wallet balance, whale transfers, filings, sanctions or site status, by poll or signed webhook

watch_create

Use when an agent needs to be told when something changes without polling. Input: type (price, balance, stablecoin_transfer, filing, sanctions, web_status), its target and condition, days 7-30, optional https webhook. Output: id, one-time secret, poll URL. Checked every 5-60 min; events by poll or HMAC-signed webhook. $0.002/day ($0.004 web_status), paid once. Best-effort, no SLA; not refunded. Example: POST {"type":"price","symbol":"ETH","below":2000} Price: $0.014–$0.12 USDC via x402.

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": {
      "type": "<type>"
    },
    "name": "watch_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
cikNofiling: SEC Central Index Key (alternative to ticker)
urlNoweb_status: site to check every 15 min; fires on up/down or status change
corpNofiling: Korean company (DART corp_code, stock code or kr-dart- id) instead of ticker
daysNoWatch length in days, 7-30 (default 7); price = days × daily rate
typeYesWhat to watch. Without type the request is a price probe (402 at the 7-day minimum)
aboveNoprice/balance: fire when the value rises above this (USD for price, token units for balance); give above or below, not both
belowNoprice/balance: fire when the value falls below this
chainNobalance: base, ethereum, arbitrum, monad; stablecoin_transfer: ethereum, base, arbitrum
itemsNofiling (SEC): only 8-Ks with these item codes, e.g. 2.02,5.02
tokenNobalance: token symbol from the default set (e.g. USDC) or NATIVE (default); any change fires when no above/below
symbolNoprice: one ticker (BTC, ETH, SOL, …; DEX-priced like /v1/crypto/price)
tickerNofiling: US ticker or use cik (SEC EDGAR); fires on each new filing
addressNobalance: wallet (0x…); sanctions: any crypto address; stablecoin_transfer: optional from/to filter
min_usdNostablecoin_transfer: minimum transfer size in USD (default 100000)
webhookNoOptional https URL (port 443, public host) for signed POSTs: header x-1gateway-signature t=…,v1=HMAC-SHA256(key=hex(SHA-256(secret)), `${t}.${body}`)

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?

With no annotations, the description carries the full burden and does so: 5-60 min check cadence, delivery by poll or HMAC-signed webhook, $0.002/day ($0.004 web_status) paid once, 7-30 day duration, and an explicit 'best-effort, no SLA; not refunded' reliability warning. It also discloses the return shape (id, one-time secret, poll URL), which is the key operational detail for a secret-bearing subscription.

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 when-to-use clause, then input/output/behavior/cost in a tight telegraphic block. Every sentence carries information, though the pricing fragment ('$0.014–$0.12 USDC via x402') is slightly cryptic about how the total is derived and could be clearer.

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 15-parameter tool with no output schema, the description covers return values, cadence, pricing, and reliability. It omits how a watch is cancelled, renewed, or what happens at the 30-day expiry, and does not clarify the 402 payment handshake implied by the schema's 'price probe' note.

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 baseline is 3, but the description adds a worked example payload ({type: price, symbol: ETH, below: 2000}) that shows how the conditional fields compose, plus the 7-30 day bound and the type vocabulary. It does not explain the interplay of the mutually exclusive above/below or chain-per-type rules beyond what the schema already documents.

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 capability: 'be told when something changes without polling', then enumerates the six watch types (price, balance, stablecoin_transfer, filing, sanctions, web_status). This clearly distinguishes it from the polling siblings (crypto_price, web_check, sanctions_address) that an agent would otherwise call.

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?

The opening 'Use when an agent needs to be told when something changes without polling' gives a concrete selection condition against the polling tools, and the type list maps intents to targets. It stops short of explicitly naming which sibling to use for a one-off check instead, so the exclusion is implied rather than stated.

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.

Resources