LuxAlgo MCP

Vela chart change

chart_command

Read-only

Edits or reads a chart already open in the chat (from chart_open): switch market or timeframe, add or remove a native indicator, draw a level or a zone, clear drawings, or zoom to a date range; {op: "read"} changes nothing and returns what the chart shows now. Ops apply in order. Usually waits a few seconds for the chart to confirm and returns what it shows, in words, with the numbers the user sees on it: the last price, the change since the day's open (00:00 UTC), the high and low of the visible range and each indicator's latest value (e.g. "RSI 38.2"). Quote those as of the moment of the reply; it never returns candles. {op: "read", image: true} also sends a picture of the chart as the user sees it into your context, where the chat app accepts images from the chart (it arrives with the next message). If the chart is idle it may answer at once that the edits are queued and when the chart applies them; if it is not on screen, edits stay queued and apply when it is shown again, and a read returns its last report without live numbers. Use chart_open instead to show a new chart.

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": {
      "chart_id": "<chart_id>",
      "ops": "<ops>",
      "context": "<context>"
    },
    "name": "chart_command"
  }
}

Input Schema

Name	Required	Description
`ops`	Yes
`context`	Yes	Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
`chart_id`	Yes	The chart_id chart_open returned.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses latency ("usually waits a few seconds for the chart to confirm"), queuing behavior when the chart is idle or off screen, what a read returns in that degraded case, and exactly which numbers come back (last price, change since 00:00 UTC open, range high/low, indicator values). It explicitly states the tool never returns candles and explains that image=true delivers a picture with the next message.

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

Conciseness4/5

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

Purpose is front-loaded in the opening clause and each subsequent clause carries distinct information (ordering, latency, return contents, image delivery, off-screen behavior). It is, however, one long semicolon-chained sentence that is dense on first read, so it is efficient but not maximally scannable.

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?

There is no output schema, so the description must carry the return contract, and it does: named values, an example formatting ("RSI 38.2"), and an explicit statement that candles are never returned. For a tool with eight op variants and async confirmation behavior, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, and the description adds real meaning the schema cannot: ops are applied in order, an empty-effect read is distinguished from edits, and image=true is framed as pushing a picture into context rather than as a plain boolean. Per-op payload fields (symbol, price, range enums) are left entirely to the schema, which is the right division of labor.

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 first clause names a specific verb and resource ("Edits or reads a chart already open in the chat") and then enumerates the concrete operations: switch market/timeframe, add/remove indicator, draw level or zone, clear drawings, zoom. It even names the originating tool (chart_open) so the agent can place this tool in a workflow without opening the schema.

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?

It gives an explicit exclusion ("Use chart_open instead to show a new chart") and clarifies that {op: "read"} is the non-mutating path, which is good routing guidance. It does not distinguish itself from chart_peek or chart_sync, which appear to be overlapping read paths, so the when-not guidance is only partial.

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

All LuxAlgo MCP 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.