Loading ToolBench
Wraps the localhost HTTP bridge (ClaudeChartObserver.dll on 127.0.0.1:5555) as MCP tools so a Claude Code session can read the active Quantower chart natively.
Four tools with complete input schemas and detailed descriptions. Naming follows verb_noun pattern (get_*). Descriptions are comprehensive (194 - 392 chars, well above baseline 194 avg), explaining WHAT, WHEN, and WHAT-RETURNS. All parameters have types and descriptions. Output schemas documented in descriptions. However, no error handling guidance, no recovery hints, and no tool annotations (readOnlyHint missing despite all tools being read-only). Composition is sound, each tool has one responsibility. No security issues (read-only, no secrets). Schemas are well-formed JSON Schema with proper constraints (enums for period, min/max for count).
Fetch just the drawings array from the Quantower chart (lighter payload than get_state when you only need drawn objects). Returns each drawing's type (Line, FibonacciRetracement, ...), id, lock state, and point coordinates (timestamp + price). Reads the cached snapshot.
Fetch historical OHLCV bars from the Quantower chart in chronological order (oldest first; the LAST bar is the live forming bar during market hours). Three paths: - Count, no `period`: slices up to N most-recent bars from the snapshot's pre-built cache at the chart's native timeframe. Sub-millisecond. - Count + `period` (one of 1m, 5m, 15m, 30m, 1h, 4h, 1d, 1w): fetches the N most-recent bars at that timeframe via Symbol.GetHistory(). ~130-660ms latency (1w slowest). - WINDOW (`from`+`to`+`period`): fetches ONLY the bars inside the given UTC time window. Use this for a specific past session (e.g. yesterday's RTH) AND to keep payloads small — a 2000-bar full read is ~465 KB and can break the response, while one RTH session at 5m is ~19 KB. `count` is ignored when from/to are set. Returns the full /history JSON envelope as text, including the bars array and metadata (actual_count, truncated, source, fetch_ms).
Capture a chart-panel-only screenshot of the Quantower chart (native resolution, typically ~1456x1153, no desktop overlays). Returns the PNG as inline base64 ImageContent — the agent sees the actual rendered chart (price bars, drawings, indicators, Order Entry panel). Reads the cached snapshot (~5s old at most). Note: each call ships ~160 KB of base64 to the conversation; use sparingly when visual confirmation is needed.
Fetch the current Quantower chart state: symbol, timeframe, account, newest_bar and prior_bar OHLCV, drawings (with coordinates), and observer metadata (version, HTTP port, snapshot age). Reads the snapshot built every ~5 seconds by the indicator's update loop. Returns the full /state JSON payload as text.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All four tools are read-only and idempotent, these should be declared via tool annotations to guide agent planning and prevent unnecessary retries.
No error handling guidance. Tools lack descriptions of failure modes (e.g., 'If Quantower is not running, returns HTTP 503 with message: "Observer not running". Retry after 5 seconds.'). LLMs cannot plan recovery without explicit error classification.
get_history description mentions 'truncated' and 'source' fields in response but does not document the full output schema structure. LLMs need explicit field documentation to extract and chain results.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
get_screenshot returns ~160 KB base64 PNG inline. No guidance on when to call it (e.g., 'Use only when visual confirmation is critical; prefer get_state for data-only queries'). Agents may over-call and waste context.
get_history 'period' parameter is marked optional but description states 'REQUIRED for a windowed (from/to) read'. Conditional required parameters should be enforced in schema (e.g., via oneOf) or validated with clear error messages.