MoveSurge

Explained price moves

explained_moves

Read-only

Abnormal price moves that MoveSurge detected first and then investigated, each with the cause it found, the evidence, a confidence level and how the move followed through. Use for 'why did oil / the Nasdaq / a stock suddenly move' when no single headline explains it. Only moves whose cause was established with medium or high confidence are published.

Input Schema

Name	Required	Description
`asset`	No	Restrict to one instrument symbol, e.g. WTI or NQ.
`hours`	No	Look back 1-1440 hours; default 72. Older results are historical investigations.
`limit`	No	Max results (1-50, default 10).
`end_utc`	No	Exclusive end timestamp with timezone. Overrides the relative look-back window.
`start_utc`	No	Inclusive start timestamp with timezone, e.g. 2026-10-14T00:00:00-04:00.

Output Schema

Name	Required	Description	Default
`count`	Yes
`error`	No
`moves`	Yes
`as_of_utc`	No
`data_note`	No
`data_status`	No
`query_window`	No
`window_hours`	No
`withheld_rows`	No
`returned_counts`	No
`availability_note`	No
`newest_result_utc`	No
`latest_published_investigation_utc`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 19, 2026

addedInput schema / properties / end_utc

Added value: +{
+  "description": "Exclusive end timestamp with timezone. Overrides the relative look-back window.",
+  "type": "string"
+}

changedInput schema / properties / hours / description

Previous value: -"Look-back window in hours (1-336, default 72)."New value: +"Look back 1-1440 hours; default 72. Older results are historical investigations."

addedInput schema / properties / start_utc

Added value: +{
+  "description": "Inclusive start timestamp with timezone, e.g. 2026-10-14T00:00:00-04:00.",
+  "type": "string"
+}

addedOutput schema / properties / availability_note
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / error
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / latest_published_investigation_utc
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / query_window
```
Added value: +{
+  "type": "object"
+}
```
addedOutput schema / properties / withheld_rows
```
Added value: +{
+  "type": "object"
+}
```

Changed6 schema fields changedOct 18, 2026
- addedOutput schema / properties / as_of_utc
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / data_note
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / data_status
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / moves / items / properties / url
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / newest_result_utc
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / returned_counts
```
Added value: +{
+  "type": "object"
+}
```
AddedOct 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish read-only, non-destructive, non-open-world behavior, and the description adds a real disclosure beyond them: only moves with medium or high confidence are published, and the investigative pipeline is retrospective ('detected first and then investigated'). It does not mention coverage-universe limits, which matters given openWorldHint=false.

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: what it is, when to use it, and the publication threshold. The most decision-relevant information (the resource and its distinctive investigated-cause framing) is front-loaded with no filler.

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?

With an output schema covering return values and annotations covering safety, the description supplies the remaining decision-critical context: confidence-gated publication and the investigative framing. The only gap is that it never states the asset/coverage universe the tool actually covers.

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 all five parameters (asset, hours, limit, end_utc, start_utc) are already documented in the schema, including the end_utc override and the 72-hour default. The description adds no parameter-level meaning beyond that, so baseline 3 applies.

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 resource (abnormal price moves MoveSurge detected and investigated) plus the payload it returns (cause, evidence, confidence, follow-through). This cleanly separates it from raw-mover siblings like top_movers and narrative siblings like search_headlines.

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?

Gives a concrete triggering question ('why did oil / the Nasdaq / a stock suddenly move') and a negative condition ('when no single headline explains it'), which implicitly routes headline-driven questions to search_headlines. It stops short of naming the alternative tool explicitly.

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

All MoveSurge 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.

Resources

Need Help?