Insight Pre-Trade Safety

oracle_watch_window_begin

Buy a 24h Oracle Watch window for one asset and return the one-time control token. Use it when an agent will poll throughout a window instead of paying per snapshot. Do not use it repeatedly for the same window and never share the token. Returns windowId, the oww_ token, the covered expiry and the credits charged. Deprecated alias: prefer oracle_watch_window with op "begin". Removed on 2027-01-06.

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>"
    },
    "name": "oracle_watch_window_begin"
  }
}

Input Schema

Name	Required	Description	Default
`chain`	No	Chain-name filter (e.g. "ethereum", "base", "hyperevm"); not a numeric chain id
`symbol`	Yes	Asset to monitor for the window

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / chain / description

Added value: +"Chain-name filter (e.g. \"ethereum\", \"base\", \"hyperevm\"); not a numeric chain id"

Changed6 schema fields changedNov 6, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / chain / description

Removed value: -"Optional chain scope fixed for the coverage"

removedInput schema / properties / chain / enum

Removed 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"
-]

changedInput schema / properties / symbol / description

Previous value: -"Asset monitored for the whole coverage, e.g. ETH"New value: +"Asset to monitor for the window"

addedInput schema / properties / symbol / maxLength
```
Added value: +20
```
addedInput schema / properties / symbol / minLength
```
Added value: +1
```

AddedNov 3, 2026

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 full burden and does substantial work: it discloses that the token is one-time and must not be shared, that calling repeatedly for the same window is discouraged, what fields come back (windowId, oww_ token, covered expiry, credits charged), and a removal date. It stops short of stating cost magnitude, auth/permission requirements, or what error occurs on a duplicate begin call.

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?

Four short sentences, front-loaded with the action and its return value, then usage, cautions, and deprecation. No filler and no repetition of schema content; each sentence carries distinct information.

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 two-parameter, no-output-schema purchase tool, the description covers purpose, when to use, return fields, token hygiene, and lifecycle/deprecation. The remaining gap is that it doesn't quantify charges or describe failure on a repeated call, which matters for a paid mutation with no annotations.

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 both parameters (symbol, chain) are already documented, and the description adds only the loose notion of 'one asset' without clarifying symbol format or the chain filter's behavior. 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?

States a specific verb and resource with scope: 'Buy a 24h Oracle Watch window for one asset and return the one-time control token.' It also explicitly contrasts with the per-snapshot sibling (oracle_watch) and names the preferred replacement tool, so an agent can distinguish it without opening any schema.

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 an explicit positive condition ('when an agent will poll throughout a window instead of paying per snapshot'), an explicit exclusion ('Do not use it repeatedly for the same window'), a token-handling caution, and a migration path ('prefer oracle_watch_window with op "begin"'). Alternative selection is fully determined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Insight Pre-Trade Safety tools Inspect

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.