LuxAlgo MCP

See my open Vela chart

chart_peek

Read-only

A picture of the chart the signed-in member has open right now in Vela, our next-generation charting platform, in their browser, as they see it, with the market, timeframe and indicators in words and a Vela link (chart_url). Use it when the member asks about the chart they have open in Vela ("look at my chart", "what do you see here?"). To show a market inside the chat instead, use chart_open. Works for crypto charts fed by an exchange only (Binance, Binance.US, Coinbase, Hyperliquid); for any other market it says so and sends no picture. The member's Vela tab must be open and visible; a first ask after a quiet spell can say no chart is open, and asking again a minute later works. The result carries no prices beyond what the picture shows. chart_index picks one chart of a multi-chart layout (0 is the first); without it, the chart the member is working on. Requires signing in with a LuxAlgo account (OAuth).

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": {
      "context": "<context>"
    },
    "name": "chart_peek"
  }
}

Input Schema

Name	Required	Description	Default
`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_index`	No	One chart of a multi-chart layout, in layout order (0 is the first). Leave it out for the chart the member is working on.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond readOnlyHint/openWorldHint, it discloses OAuth sign-in via a LuxAlgo account, the requirement that the Vela tab be open and visible, a transient 'no chart is open' failure mode that resolves on retry, exchange coverage limits, and that no prices come back beyond the image. Not a 5 only because it does not say what the picture payload looks like or whether repeated calls are rate-limited, though 'no prices beyond what the picture shows' covers the main ambiguity.

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?

Front-loaded with the core purpose and the sibling routing, and most sentences carry distinct information (exchange coverage, auth, transient failure). It is long and the chart_index sentence duplicates schema text, which is the only thing keeping it from a 5.

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?

For a two-parameter read tool with full schema coverage, no output schema, and no nested objects, the description covers purpose, alternative, prerequisites, failure modes, and result contents. An agent has everything needed to select and 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 coverage is 100%, so both parameters are already documented. The description's note that chart_index selects one chart of a multi-chart layout (0 = first) and defaults to the chart being worked on restates the schema's own chart_index description rather than adding new meaning, so the baseline 3 applies.

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 verb and resource (a picture of the chart the member has open in Vela), enumerates what the result contains (market, timeframe, indicators in words plus chart_url), and explicitly contrasts itself with chart_open for in-chat market display. An agent can distinguish it from every sibling without opening a schema.

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

Usage Guidelines5/5

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

It names the triggering utterances ('look at my chart', 'what do you see here?') and routes the alternative case to chart_open. It also states when the tool will not work (non-crypto markets, Vela tab not open/visible) instead of leaving that to trial and error.

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.