What can you do with this server?

This server is an MCP toolset for analyzing futures markets (gold) on TradingView, combining OHLCV data, chart captures, range detection, trade planning, and backtesting. * Fetch OHLCV bars for H1/H4 trading-day windows with relative volume (volume/SMA14), volume zones, session tags, and per-day summaries. * Capture a TradingView chart screenshot framed to the exact trading-day window, in anonymous mode or your saved session layout. * Detect and analyze range setups on H1: verdict COMPLETED / NOT_COMPLETED / NO_RANGE, with support, resistance, numbered rejections, and break time. * Render detected ranges onto the chart (support/resistance box, numbered rejections, caption) and return the image plus the full range report. * Generate a trade plan per range: direction, entry order and level, stop, R-multiple targets, position size, and exit rules, anchored to account settings. * Run walk-forward backtests over past dates, reporting orders, fills, exits, win rate, R, P&L, drawdown, and profit factor (including 1R/2R/3R exits). * Expose resources such as futures://symbols and futures://status, and prompts such as range_check and trade_plan. * Support inline chart rendering in MCP Apps hosts (e.g. Claude Desktop) via ui://futures-mcp/chart.html.

Which integrations are available for this server?

Provides futures market analysis using TradingView data and charts, including OHLCV bars with relative volume, chart capture, and range setup detection with visual overlays.

How do I use Futures MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Futures MCP Did gold set up a range on H1 over the three days to July 7?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Futures MCP

by usamahassan965

Overview Schema Source Related Servers Discussions Admin

Python

Local

Futures MCP

Python MCP

An MCP server that lets Claude look at the futures market: fetch OHLCV bars with relative volume, capture a TradingView chart framed on an exact trading-day window, detect whether a range setup formed, and return the chart with the range drawn on it.

Ask Claude: "Did gold set up a range on H1 over the three days to July 7?" It calls get_range_chart and answers with the verdict, the levels and this chart:

Range chart for GC1! H1, 3 trading days to 2026-07-07

Two completed ranges were found. Each has support/resistance, numbered rejections in the order they happened, and the time the first one broke. Everything was drawn on a live TradingView screenshot, whose axes were read by OCR so the boxes land on the right prices and bars.

Tools

Tool	What it returns	Typical time
`get_futures_bars`	OHLCV bars for N trading days with Relative Volume (volume / SMA14), its zone, the session tag of each bar, per-day summaries	< 2 s (cached)
`capture_chart`	PNG of the TradingView chart framed on exactly that window, plus the saved path	20–40 s
`analyze_range`	Verdict `COMPLETED` / `NOT_COMPLETED` / `NO_RANGE`, with each structure's support, resistance, rejections and break time	2–5 s
`get_range_chart`	The chart with the detected range drawn on it, plus the same report	30–50 s
`get_trade_plan`	For each detected range: direction, entry order and level, stop and what it is anchored to, R-multiple targets, position size and the exit rules	2–5 s
`run_backtest`	Walk-forward replay of the detector and the rules over past dates: every order, fill and exit, with win rate, R, P&L, drawdown and profit factor for the strategy's own exit and for 1R/2R/3R	~1 min per month

Also:

Resources: futures://symbols lists the supported symbols; futures://status reports the capture mode and whether the detector, the trading rules and OCR are available.
Prompts: range_check is a ready-made "check this symbol for a range" workflow; trade_plan continues it into the trade.

Every tool has a typed output schema (structuredContent) and read-only annotations. The long-running tools report progress.

Inline chart (MCP Apps). capture_chart and get_range_chart link a small HTML view (ui://futures-mcp/chart.html). Hosts that support MCP Apps, such as Claude Desktop, render the chart with its verdict and levels directly in the chat. Other hosts ignore it and still get the image and JSON.

Related MCP server: TradingView MCP Jackson

How it works

flowchart LR
    C[Claude Code / Desktop] <-- stdio --> S[server.py<br/>tools · resources · prompt]
    S --> SV[service.py]
    SV --> B[data/bars.py<br/>tvDatafeed + disk cache]
    SV --> T[capture/tradingview.py<br/>async Playwright]
    SV --> P[ranges/pipeline.py]
    P --> D[(private detector<br/>not in repo)]
    SV --> R[trading/rules.py<br/>loader + arithmetic guard]
    R --> E[(private trade rules<br/>not in repo)]
    SV --> BT[trading/backtest.py<br/>walk-forward replay]
    BT --> P
    BT --> R
    SV --> O[ranges/overlay.py<br/>OCR calibration + drawing]
    B --> TV1((TradingView<br/>data))
    T --> TV2((TradingView<br/>chart))

One window everywhere. timewindow.window_utc(end_date, days) defines the trading-day window. The bar fetch, the screenshot (framed through TradingView's Go to → Custom range) and the scan all use it, so the bars and the chart describe exactly the same span.
Bars and screenshot fetched concurrently in get_range_chart (an anyio task group). A shared Chromium page stays warm between calls; captures are serialised because the chart is one piece of UI state.
Detection runs the private detector over the window's 2- and 3-day sub-windows, dedupes the hits, drops ranges contained in a wider one, and numbers the rejections.
Calibration. Tesseract reads the price and time axis labels, and a least-squares fit maps price to pixels and time to pixels. If the fit is loose (RMS ≥ 1 px), or the window's high/low would fall outside the price pane, nothing is drawn and the tool returns the clean screenshot with a warning. The verdict is unaffected either way.
Chart settings are forced to match the data: the axis timezone is set to UTC+5, and back-adjustment for contract rolls (B-ADJ) is turned off for the shot. If a saved layout had B-ADJ on, it is restored afterwards.

Setup

Requirements: Python 3.11+, Tesseract (on Windows the default C:\Program Files\Tesseract-OCR install is found automatically).

conda create -n futures_mcp python=3.12 -y
conda activate futures_mcp
pip install -e ".[dev]"
pip install "tvdatafeed @ git+https://github.com/stefanomorni/fork-tvdatafeed.git"
playwright install chromium

Playwright version: if playwright install cannot download the latest Chromium build (CDN timeouts), pin Playwright to match a Chromium you already have. For example, pip install playwright==1.58.0 uses Chromium build 1208.

Copy .env.example to .env if you want to change anything. All settings are optional.

Capture modes

Anonymous (default). TradingView's public chart. No account needed.
Session. Set TRADINGVIEW_SESSION_ID (your sessionid cookie) and TRADINGVIEW_URL (your saved layout). Captures then use your own layout, indicators and colours. Keep the cookie in .env, which is git-ignored.

Each chart request can also pick its mode: capture_chart and get_range_chart take an optional mode (anonymous or session), so "show it on my layout" uses your layout for that one request. When a request doesn't pick one, the server uses FUTURES_MCP_DEFAULT_MODE. If that's unset, it uses session when a cookie is set and anonymous otherwise. Set FUTURES_MCP_DEFAULT_MODE=anonymous to keep the public chart as the default while your layout is available on request.

The range detector is private

The detection rules are proprietary and are not in this repository. At runtime the server imports range_screener_v6.py from FUTURES_MCP_DETECTOR_DIR (default ./private, which is git-ignored). The contract it must meet is documented in ranges/detector.py.

Without the detector, get_futures_bars and capture_chart work normally. The two range tools return a clear error straight away, before spending any time in the browser.

To try the range tools without the private rules, point the server at the toy example detector in examples/detector/:

FUTURES_MCP_DETECTOR_DIR=examples/detector

It meets the same contract with deliberately naive logic: the box is the first day's high/low, and 4 alternating edge touches count as complete. Its results are not the ones shown above. CI uses it to run the range pipeline end to end.

So are the trading rules

get_trade_plan answers the next question — what is the trade on this range? — and the rules that answer it are private in the same way. At runtime the server imports entry_rules.py from FUTURES_MCP_RULES_DIR (default: the detector folder). The contract is documented in trading/rules.py: a module exposing RULES_VERSION and plan(bars, structure, account), and optionally simulate(bars, plan, structure, placed_idx, exit) for backtests.

Whatever the rules return, the server re-checks before it leaves the process: the stop must be on the correct side of the entry, risk_points must equal |entry − stop|, every target must sit exactly its R multiple away, and the size must clear the minimum. A plan that fails any of those is an error, not a trade. No level or size in the output is ever produced by a language model — the tool computes them and the model may only report them.

Sizing comes from the account settings: FUTURES_MCP_ACCOUNT_EQUITY (default 100000), FUTURES_MCP_RISK_PCT (default 1) and FUTURES_MCP_CONTRACT. Levels are always read on the continuous future (GC1!), but positions are sized in the micro contract by default (MGC, $10 per point), which gets much closer to the risk budget than one standard GC ($100 per point). Set FUTURES_MCP_CONTRACT=standard to size in GC.

A toy set of rules lives in examples/rules/ — last rejection, market entry at its close, stop at that bar's extreme — so the tool can be run end to end from a clean checkout:

FUTURES_MCP_DETECTOR_DIR=examples/detector FUTURES_MCP_RULES_DIR=examples/rules

It is wiring, not a strategy. CI uses it the same way it uses the toy detector.

Backtesting

run_backtest answers would this have worked? without hindsight. At every H1 bar in the period, trading/backtest.py cuts the window the live tool would have seen at that moment, runs the detector and the rules on it, and places an order only on the bar where the signal first appears. The rules' own simulate then replays that order on the bars that follow. The backtest module decides nothing about fills or exits; it schedules signals, enforces the portfolio constraints and counts:

One signal per range. The sliding window renumbers the same range as it moves, so later signals on an overlapping range are ignored.
One trade at a time. A signal is skipped while an order rests or a trade is open.
Stale signals are counted, not traded. Sometimes a detector recognises a structure only after the order would already have filled or been cancelled.
Worst case on ambiguous bars. A bar that touches both the stop and the target counts as the stop, and is flagged.
Roll gaps are flagged. Continuous contracts jump at a roll; trades spanning one are marked.

No commissions or slippage are modelled yet.

Connect it to Claude

Claude Code (plugin)

The repo is also a Claude Code plugin marketplace. Install the plugin once and the server is available in every session:

claude plugin marketplace add usamahassan965/futures-mcp
claude plugin install futures-mcp@futures-mcp

The plugin runs ${FUTURES_MCP_PYTHON:-python} -m futures_mcp. Point it at the environment you installed into by adding this to ~/.claude/settings.json:

{ "env": { "FUTURES_MCP_PYTHON": "C:/Users/<you>/miniconda3/envs/futures_mcp/python.exe" } }

Claude Code starts servers from whatever folder a session is in, so put your settings in the per-user file ~/.futures-mcp/.env (same keys as .env.example), using absolute paths for FUTURES_MCP_DATA_DIR and FUTURES_MCP_DETECTOR_DIR. Then ask "Is GC setting up a range on H1?".

Without the plugin:

claude mcp add futures -s user -- C:/Users/<you>/miniconda3/envs/futures_mcp/python.exe -m futures_mcp

Claude Desktop

Claude Desktop also starts servers from its own working directory: use ~/.futures-mcp/.env as above, or give absolute paths in the config. Edit %APPDATA%\Claude\claude_desktop_config.json (on macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "futures": {
      "command": "C:/Users/<you>/miniconda3/envs/futures_mcp/python.exe",
      "args": ["-m", "futures_mcp"],
      "env": {
        "FUTURES_MCP_DATA_DIR": "C:/Users/<you>/futures-mcp/data",
        "FUTURES_MCP_DETECTOR_DIR": "C:/Users/<you>/futures-mcp/private"
      }
    }
  }
}

Both work on a Claude Pro subscription. The server runs locally over stdio, so no API key is needed.

MCP Inspector

npx @modelcontextprotocol/inspector python -m futures_mcp

Development

pytest        # unit + golden + in-memory MCP protocol tests
ruff check .
mypy

Golden tests. Three recorded GC windows (COMPLETED, NOT_COMPLETED, NO_RANGE) in tests/fixtures/:
- Re-scanning them must reproduce the recorded structures.
- Re-drawing them must reproduce the recorded marked charts pixel for pixel.
Protocol tests. An in-memory mcp.Client runs against the real server with only the network edges faked, i.e. the bar feed and the browser. They cover schemas, argument validation, error mapping, progress, images and structured output.
CI runs on Ubuntu with Python 3.11 and 3.12. Tests that need the private detector are skipped there; the toy detector test still runs the range pipeline.

Scope and limits

Symbols: GC1! (COMEX gold). Adding a symbol is one line in symbols.py.
Position sizing assumes one account and one instrument's point value; it does not know your broker, margin or fees.
Timeframes: bars and charts on H1/H4; range detection on H1, where it is calibrated.
Backtests are limited by how much H1 history TradingView returns (about six months) and to 120 calendar days per run. They exclude costs.
Times are shown in UTC+5 (the chart axis) and UTC.
Not financial advice. This is an analysis tool.

License

MIT

Available Tools

4 tools

analyze_rangeAnalyze range setupA

Read-onlyIdempotent

Detect a range in the window. Verdict: COMPLETED (a range met every rule), NOT_COMPLETED (a range is forming but not yet confirmed), or NO_RANGE. Each structure lists support, resistance, its numbered rejections and, if price has left it, when it broke.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Trading days to scan
`symbol`	No	Futures symbol, e.g. 'GC1!' (aliases: GC, GOLD)	GC1!
`end_date`	No	Last trading day of the window, YYYY-MM-DD. Omit for the current one.
`timeframe`	No	Range detection is calibrated on H1	H1

Output Schema

ParametersJSON Schema

Name	Required	Description
`symbol`	Yes
`summary`	Yes
`verdict`	Yes
`timeframe`	Yes
`candidates`	Yes	Detector hit counts before selection: completed / anticipation / demoted
`structures`	Yes
`window_utc`	Yes
`target_date`	Yes
`window_complete`	Yes
`window_trading_days`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description need not repeat those. It adds valuable behavioral context by specifying the possible verdicts (COMPLETED, NOT_COMPLETED, NO_RANGE) and the structure of each result (support, resistance, rejections, break time). This goes beyond the annotations and helps the agent anticipate output shape.

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?

The description is two sentences long, front-loads the primary action, and immediately provides the verdict taxonomy and output structure. There is zero fluff or repetition of schema content. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return values are presumably documented there. The description nonetheless explains the verdicts and the components of each structure, which is sufficient for an agent to understand the tool's behavior. Given the low complexity (4 optional params, no nesting), the description covers everything needed for correct invocation.

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 coverage is 100% and all parameters have descriptions, so the schema already documents days, symbol, end_date, and timeframe. The description does not add any additional parameter-specific meaning beyond referencing 'the window', which is already implied by the parameters. Baseline 3 is appropriate when the schema carries the semantic load.

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 states a specific action ('Detect a range in the window') with clear scope, and distinguishes itself from siblings like get_futures_bars and get_range_chart by focusing on analysis rather than data retrieval or charting. It also enumerates the verdicts, which clarifies the tool's core purpose without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to choose this tool over its siblings (get_futures_bars, capture_chart, get_range_chart). It only describes what it does, not the conditions or use cases that would make it the preferred option. No exclusions or alternatives are mentioned.

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

capture_chartCapture TradingView chartA

Read-onlyIdempotent

Screenshot of the TradingView chart framed on exactly the trading-day window. Takes 20-40 seconds.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Trading days in the window
`mode`	No	Chart to capture on: 'anonymous' (TradingView's public chart) or 'session' (the user's saved layout, e.g. when they say 'on my layout'). Omit for the server default.
`symbol`	No	Futures symbol, e.g. 'GC1!' (aliases: GC, GOLD)	GC1!
`end_date`	No	Last trading day of the window, YYYY-MM-DD. Omit for the current one.
`timeframe`	No	Bar timeframe	H1

Output Schema

ParametersJSON Schema

Name	Required	Description
`mode`	Yes	anonymous (default chart) or session (your saved layout)
`path`	Yes	Where the PNG was saved on the server machine
`warnings`	Yes
`window_utc`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish read-only, open-world, and idempotent behavior. The description adds meaningful context beyond those by specifying that the chart is framed on exactly the trading-day window and that the operation takes 20-40 seconds. No contradiction exists.

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?

The description is two short sentences with no wasted words. The core purpose is front-loaded, and the latency warning earns its place as an operational hint.

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 tool with a rich input schema, safety annotations, and an output schema, the description covers the main operational facts: what it captures, the window framing, and the expected delay. It could be slightly more complete by mentioning when to choose this over get_range_chart, but that gap does not undermine correct invocation.

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 input schema already documents all five parameters with defaults, examples, and meanings. The description does not need to add parameter-level detail, and does not, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Screenshot') and resource ('TradingView chart'), and adds a key scoping detail about the trading-day window. It is clear, though it does not explicitly differentiate itself from sibling tools like get_range_chart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: whenever a screenshot of a TradingView chart is needed, especially one aligned to a trading-day window. It provides no explicit when-not-to-use guidance or alternatives, and the latency note is useful but does not help with sibling selection.

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

get_futures_barsGet futures barsA

Read-onlyIdempotent

OHLCV bars for a trading-day window, with Relative Volume (volume/SMA14), its zone, the session each bar belongs to, and per-day summaries.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Trading days in the window
`symbol`	No	Futures symbol, e.g. 'GC1!' (aliases: GC, GOLD)	GC1!
`end_date`	No	Last trading day of the window, YYYY-MM-DD. Omit for the current one.
`timeframe`	No	Bar timeframe	H1
`include_bars`	No	False returns only the per-day summaries

Output Schema

ParametersJSON Schema

Name	Required	Description
`bars`	Yes	Omitted when include_bars=false
`days`	Yes
`n_bars`	Yes
`symbol`	Yes
`timeframe`	Yes
`window_utc`	Yes	[start, end) in UTC
`target_date`	Yes
`timezone_note`	Yes
`window_complete`	Yes	False while the window's last session is still open
`window_trading_days`	Yes
`window_max_volume_bar`	Yes
`relative_volume_indicator`	Yes

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds value by detailing what the output includes (Relative Volume, zone, session, summaries), which is beyond the annotations. It does not contradict annotations and provides useful behavioral context about the data returned.

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?

The description is a single, concise sentence that efficiently communicates the core output and key derived fields. It front-loads the primary content (OHLCV bars) and lists the enhancements. There is no redundant information, and every phrase earns its place.

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?

Given the tool's simplicity, full parameter coverage in the schema, and presence of an output schema, the description is largely complete. It explains the return content adequately. Minor gaps like default window length or date format are covered by the schema, so nothing essential is missing for an agent to call it correctly.

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 parameters (days, symbol, end_date, timeframe, include_bars) are already documented with descriptions and defaults. The description does not need to add parameter-level detail, and it doesn't. The baseline of 3 is appropriate because the schema carries the full burden and the description adds no extra semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns OHLCV bars for a trading-day window, with additional computed fields (Relative Volume, zone, session, summaries). It specifies the resource (futures bars) and the nature of the output. It does not explicitly distinguish itself from sibling tools like get_range_chart, but the purpose is evident from the name and content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description only describes the output, not the context in which it should be selected. For a tool with siblings like get_range_chart, this omission leaves the agent to infer usage without explicit direction.

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

get_range_chartRange chartA

Read-onlyIdempotent

The TradingView chart for the window with the detected range drawn on it (support/resistance box, numbered rejections, caption), plus the report. Takes 30-50 seconds.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Trading days to scan
`mode`	No	Chart to capture on: 'anonymous' (TradingView's public chart) or 'session' (the user's saved layout, e.g. when they say 'on my layout'). Omit for the server default.
`symbol`	No	Futures symbol, e.g. 'GC1!' (aliases: GC, GOLD)	GC1!
`end_date`	No	Last trading day of the window, YYYY-MM-DD. Omit for the current one.
`timeframe`	No	Range detection is calibrated on H1	H1

Output Schema

ParametersJSON Schema

Name	Required	Description
`mode`	Yes	anonymous (default chart) or session (your saved layout)
`path`	Yes
`drawn`	Yes	False when chart calibration failed and nothing was drawn
`report`	Yes
`warnings`	Yes

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds the important behavioral context that a call takes 30-50 seconds and returns both a chart and a report. This goes beyond the structured annotations without contradicting them.

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?

Two short sentences, front-loaded with the core output and ending with the critical latency caveat. Every word earns its place; there is no filler or redundancy.

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?

Given the output schema, safety annotations, and fully described optional parameters, the description is largely complete: it states what is returned and how long it takes. It could add more about report contents or prerequisites, but that is likely covered by the output schema.

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 baseline is 3; all parameters already have meaningful descriptions. The tool description itself adds no parameter-level semantics, but little is needed because the schema carries the full burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the deliverable: a TradingView chart with the detected range drawn on it, plus a report. This distinguishes it from siblings like analyze_range and capture_chart. It relies on the tool name for the verb and does not explicitly name alternatives, so it just misses the top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus analyze_range or capture_chart. There are no ordering dependencies, exclusions, or alternative-selection hints. The latency note is behavioral information, not usage guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 19, 2026
- First observedanalyze_range
- First observedcapture_chart
- First observedget_futures_bars
- First observedget_range_chart

Deploy Server

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

TDQS

A3.9/5.0

Scored 2026-09-19 18:55 across 4 tools

Disambiguation4/5

Each tool has a clear primary purpose: retrieving bar data, performing range analysis, and capturing chart images. The only potential confusion is between capture_chart and get_range_chart, but the descriptions make clear that one is a raw screenshot while the other includes the detected range and report.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: get_futures_bars, analyze_range, capture_chart, get_range_chart. The naming style is uniform and predictable, with no mixing of conventions.

Tool Count4/5

Four tools is somewhat lean, but appropriate for a focused futures charting and range-analysis workflow. Each tool fills a distinct step in the process, and the small count keeps the server manageable.

Completeness4/5

The server covers the core workflow of retrieving bars, detecting a range, and viewing charts. Minor gaps exist, such as no obvious tool for listing available futures instruments or configuring window parameters, but these do not severely block the intended use case.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Algo Trade AnalyticsOAuth
com.algo-trade-analytics
Evidence-gated quant research for TradingView Pine Script strategies, run from your AI client.
Finance Research & Data
1
Bullrun A
org.bull-run
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
Finance AI & Machine Learning Research & Data
303
trayd-mcpOAuth
io.github.teamtrayd
Trade Robinhood through natural language in Claude Code.
Finance App Automation
242
mcp A
io.github.ironflowsh
Read-only Hyperliquid data for AI agents: fills, candles, funding, liquidations, wallet analytics.
Cryptocurrency Finance Blockchain
361

Related MCP Servers

mcp-tradingview-server
Finance Web Scraping
bidouilles
F
license
Not graded
quality
D
maintenance
Exposes TradingView technical indicators and OHLCV data through MCP tools for Claude Desktop or any MCP-aware client.
Updated 3 months ago (2026-06-22 16:06 UTC)
23
-
TradingView MCP Jackson
Finance Data Visualization
BluePandaNYC
F
license
Not graded
quality
D
maintenance
Enables Claude to control and read from the TradingView Desktop app, providing automated morning briefs, chart analysis, Pine Script development, and replay mode.
Updated 3 months ago (2026-07-10 22:52 UTC)
130 npm
-
TradingView MCP Jackson
Finance Browser Automation
kylepk-boop
F
license
Not graded
quality
C
maintenance
Enables Claude to control TradingView Desktop for automated morning briefs, chart analysis, Pine Script development, and session management via MCP tools.
Updated 3 months ago (2026-07-12 11:30 UTC)
130 npm
-
tradingview-mcp
Finance Data Visualization
Miha21222
A
license
A
quality
A
maintenance
Provides AI agents with a TradingView-centric toolkit for screener queries, historical FX data, pattern scanning, chart rendering, backtesting, Pine tooling, and optional account/desktop integration.
Updated 9 days ago (2026-09-22 13:23 UTC)
6
MIT