aipricepatterns

Describe Candle Windows

describe_candle_windows

Read-onlyIdempotent

Describe the form of a set of candle windows and draw it for a terminal. Pass timestamps (bar open time in Unix ms; set windowBars to 1 for a single print) or one close rule: forwardCloseMaxPct -10 with windowBars 12 means the close 12 bars later is at least 10% lower. Quote brief. It counts down bars, where the low sat, volume versus the bars before the window, and what the next horizonBars did, with ordinary windows of the same length beside them. terminal and brief also contain a monospace chart of the median candles and volume. Show that chart in a code block with every line, including the header, the legend line under it and the footer, and do not reflow it. Quote NO_TRADE verbatim. The caller supplies the times. A move that was retraced before the named close is not included. NO_TRADE. Not a side.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "describe_candle_windows"
  }
}

Input Schema

Name	Required	Description	Default
`symbol`	No	BTCUSDT, ETHUSDT or SOLUSDT. Default BTCUSDT.	BTCUSDT
`interval`	No	5m, 15m, 1h, 4h or 1d. Default 1h.	1h
`timestamps`	No	Bar open times in Unix milliseconds. The caller supplies these. Set windowBars to 1 for the print bar itself.
`windowBars`	No	Bars inside each window. Use 1 for a single print bar. Default 12.
`horizonBars`	No	Bars after the window whose path is described. Default 12.
`lookbackBars`	No	Bars before each window used as the volume and range baseline. Default 96.
`forwardCloseMaxPct`	No	Keep a window when the close this many bars later is at or below this percent. A 10% drop over 12 bars is -10.
`forwardCloseMinPct`	No	Keep a window when the close this many bars later is at or above this percent. A 10% rise over 12 bars is 10.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Beyond the readOnly/idempotent annotations, it discloses what is actually computed (bar countdown, where the low sat, volume versus prior bars, what the next horizonBars did, baseline comparison with ordinary windows of the same length) and an exclusion rule — moves retraced before the named close are dropped. It also imposes output-format obligations (keep the monospace chart intact, quote NO_TRADE verbatim), which the annotations do not cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core capability is front-loaded, but the prose is telegraphic and unevenly punctuated ("Quote brief.", "NO_TRADE. Not a side."), mixing rendering instructions, semantics and exclusions into a dense block. Some clauses ("Not a side.") carry no discernible meaning for a caller.

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?

There is no output schema, and the description compensates by explaining what the terminal/brief payloads contain, that they include a median-candle and volume chart, and how that chart must be preserved. Given eight optional parameters and a research-style computation, the caller has enough to invoke it correctly, with only minor residual ambiguity about the shape of "brief".

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%, so each parameter is already documented. The description repeats some of that (bar open time in Unix ms, windowBars=1 for a single print) and adds one genuinely new constraint the schema lacks — the two forward-close filters are an either/or choice — plus a worked example (-10 over 12 bars = 10% lower). That is additive but modest against an already-complete schema.

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?

Opens with a specific verb+resource pair ("Describe the form of a set of candle windows and draw it for a terminal") and then enumerates the two input modes (timestamps or one forward-close rule), so the agent knows what the tool produces. It never names or contrasts a sibling tool, so differentiation from the many other candle_* tools is left to inference.

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?

"Pass timestamps ... or one close rule" and "set windowBars to 1 for a single print" give concrete entry conditions, and "The caller supplies the times" heads off a mistaken assumption that the server picks bars. There is no explicit when-not or alternative-tool routing, so usage is implied rather than stated.

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

All aipricepatterns 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?