Skip to main content
Glama

oracle_watch

Ongoing cross-oracle risk signal for an asset: current consensus deviation, agreement, quorum, outliers and staleness condensed into a NORMAL / CAUTION / DANGER verdict with a proceed / proceed_with_caution / halt recommendation. Agents should gate long-running strategies (yield, keeper, portfolio) on this signal, not just one-off trades. Pair it with pre_trade_safety_check for the decision moment.

Input Schema

NameRequiredDescriptionDefault
chainNoOptional blockchain filter
symbolYesAsset symbol, e.g. BTC, ETH

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / chain / enum
      Previous value: -[
      -  "ethereum",
      -  "arbitrum",
      -  "optimism",
      -  "polygon",
      -  "solana",
      -  "avalanche",
      -  "fantom",
      -  "cronos",
      -  "juno",
      -  "cosmos",
      -  "osmosis",
      -  "bnb-chain",
      -  "base",
      -  "scroll",
      -  "zksync",
      -  "aptos",
      -  "sui",
      -  "gnosis",
      -  "mantle",
      -  "linea",
      -  "celestia",
      -  "injective",
      -  "sei",
      -  "tron",
      -  "ton",
      -  "near",
      -  "aurora",
      -  "celo",
      -  "starknet",
      -  "blast",
      -  "cardano",
      -  "polkadot",
      -  "kava",
      -  "moonbeam",
      -  "moonriver",
      -  "metis",
      -  "starkex",
      -  "stellar",
      -  "flare",
      -  "supra-chain",
      -  "bandchain"
      -]New value: +[
      +  "ethereum",
      +  "arbitrum",
      +  "optimism",
      +  "polygon",
      +  "solana",
      +  "avalanche",
      +  "fantom",
      +  "cronos",
      +  "juno",
      +  "cosmos",
      +  "osmosis",
      +  "bnb-chain",
      +  "base",
      +  "scroll",
      +  "zksync",
      +  "aptos",
      +  "sui",
      +  "gnosis",
      +  "mantle",
      +  "linea",
      +  "celestia",
      +  "injective",
      +  "sei",
      +  "tron",
      +  "ton",
      +  "near",
      +  "aurora",
      +  "celo",
      +  "starknet",
      +  "blast",
      +  "cardano",
      +  "polkadot",
      +  "kava",
      +  "moonbeam",
      +  "moonriver",
      +  "metis",
      +  "starkex",
      +  "stellar",
      +  "flare",
      +  "supra-chain",
      +  "bandchain",
      +  "monad"
      +]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it enumerates the inputs to the verdict (consensus deviation, agreement, quorum, outliers, staleness) and the output shape (verdict plus proceed/proceed_with_caution/halt recommendation), which is effectively the missing output schema. It does not disclose auth needs, rate limits, caching, or how quickly the signal refreshes.

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

Conciseness5/5

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

Three tight sentences, front-loaded with the capability and its condensed output, followed by usage gating and the sibling pairing. No filler or restatement of the tool name.

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 read-only signal tool with no output schema, the description covers purpose, output composition, usage context and the sibling relationship, which is close to complete. It leaves minor gaps around how the optional chain filter changes results and whether the signal is cached or computed per call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters, and the description adds no syntax or semantics for 'symbol' or the optional 'chain' filter. Baseline 3 applies when the schema does the heavy lifting.

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 names a specific capability: a cross-oracle risk signal for an asset that condenses deviation, agreement, quorum, outliers and staleness into a NORMAL/CAUTION/DANGER verdict. It is clearly distinguishable from siblings like compare_oracle_deviation (single comparison) and pre_trade_safety_check (one-off decision moment).

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?

It states explicitly when to use it ('gate long-running strategies (yield, keeper, portfolio)') and when not to lean on it alone ('not just one-off trades'), then routes the agent to the complementary tool: 'Pair it with pre_trade_safety_check for the decision moment.'

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