Skip to main content
Glama
Sign In
TradingView-MCP

TradingView-MCP

by tedorigawa001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

preflight_cross_asset_shock

Counts exact UTC closed-bar intersections for cross-asset shock studies. Reuses an auxiliary chart to read DXY, US10Y, and XAUUSD at 5/15-minute timeframes, then restores it.

Instructions

Coverage preflight for the cross-asset shock study. It binds an EURUSD or USDJPY target chart, then temporarily reuses one auxiliary chart for DXY, US10Y, and XAUUSD at the same 5 or 15 minute timeframe, restoring that auxiliary chart after each read. An optional explicit history load can add older bars but never changes symbols or timeframes persistently. Only exact UTC closed-bar intersections are counted; no shock threshold, direction, outcome, order-flow claim, or trading instruction is produced.

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": {
      "target_chart_index": "<target_chart_index>",
      "auxiliary_chart_index": "<auxiliary_chart_index>",
      "expected_target_symbol": "<expected_target_symbol>",
      "expected_timeframe": "<expected_timeframe>"
    },
    "name": "preflight_cross_asset_shock"
  }
}

Input Schema

NameRequiredDescriptionDefault
countNo
load_more_barsNoAdditional history to request for the target and each temporary context before reading. Default: 0
expected_timeframeYes
target_chart_indexYes
minimum_aligned_barsNo
auxiliary_chart_indexYes
expected_target_symbolYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.10

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does an excellent job: it discloses temporary chart reuse, restoration after each read, optional history loading, lack of persistent symbol/timeframe changes, and the strict counting rule. This gives the agent a clear picture of side effects and non-effects beyond what any schema could convey.

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 dense and well-structured: purpose first, then mechanics, then exclusions and limitations. Every sentence adds distinct value, and the most important behavioral constraints are front-loaded without redundancy.

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

Completeness3/5

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

The tool has 7 parameters, no annotations, and no output schema, so the description must do more heavy lifting. It covers side effects and scope well, but it omits definitions for 'count' and 'minimum_aligned_bars' and does not specify the return shape beyond implying an intersection count. For a tool an agent must invoke with correct parameter values, these are important gaps.

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 only 14%, so the description must compensate. It does clarify the roles of target_chart_index and auxiliary_chart_index, the expected symbols, the timeframe, and load_more_bars behavior. However, 'count' and 'minimum_aligned_bars' are never mentioned or explained, even though they are likely central to the preflight logic, leaving a meaningful semantic gap.

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 clearly identifies the tool as a coverage preflight for the cross-asset shock study and specifies exactly what it does: bind an EURUSD or USDJPY target chart, temporarily reuse an auxiliary chart for DXY/US10Y/XAUUSD, and count exact UTC closed-bar intersections. It also explicitly distinguishes itself from outcome-producing tools by stating that no shock threshold, direction, outcome, order-flow claim, or trading instruction is produced.

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?

The description gives clear context by explaining this is a preflight/coverage-checking operation and explicitly lists what it does not produce, which helps an agent avoid using it for outcome analysis or trade instruction. However, it does not name alternative sibling tools directly or state explicit conditions like 'use this before running classify_cross_asset_shocks.'

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

Deploy Server

Other Tools