Skip to main content
Glama

NexusTrade Financial MCP

by io.github.austin-starks
OverviewDiscussionsAdmin

query_backtest_history

Return a time series of {time, value, cash, positionValue, comparisonValue, reservedCollateral} per tick for a completed backtest. Reads from the backtesthistories collection (full minute-resolution; 30-day TTL). Use this to find suspicious single-tick portfolio value jumps without needing the codebase — feed the result through your own jump-detection logic. Cash is derived as value minus Σ(position.quantity × lastPrice). reservedCollateral is the collateral locked by open positions at that tick, as the engine computed it; it reads null for a run made before collateral reporting existed, which is NOT zero. Never re-derive it from cash − buyingPower. Zero research token cost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (default 1)
end_dateNoISO date filter end (e.g. 2024-10-18). Inclusive; T23:59:59.999Z is appended if a bare date is given.
page_sizeNoRows per page (default 500, max 5000). Larger than events because history is plain numbers — cheap to emit.
start_dateNoISO date filter start (e.g. 2024-10-07). Inclusive.
backtest_idYesBacktest ID (required). Must be owned by the calling MCP user.
jump_bps_thresholdNoIf set, the response appends a 'Suspicious jumps' section listing every single-tick Δvalue whose magnitude exceeds this many basis points of the FIRST point's value. E.g. 50 = flag any >0.5% move between consecutive ticks. Useful for mark-to-market bug hunts. Default: omitted (no jump scan).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/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 it does so thoroughly. It discloses the data source collection, 30-day TTL, minute resolution, cash derivation formula, reservedCollateral null semantics, and explicitly warns against re-deriving reservedCollateral from cash − buyingPower. It also notes zero research token cost.

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 front-loaded with the purpose, then adds only high-value operational details: storage, TTL, derivation, null semantics, and cost. Every sentence earns its place; caveats are compact and directly relevant to avoiding misuse.

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 enumerating the per-tick fields and explaining the tricky ones (cash derivation, reservedCollateral null behavior) and the optional 'Suspicious jumps' section. It does not define comparisonValue or positionValue in detail, and ownership is only mentioned in the input schema, but overall an agent has enough context to invoke and interpret the tool.

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. The description does not add per-parameter syntax or meaning, but it enriches interpretation of the output fields relevant to parameters like jump_bps_threshold. Since the schema already fully documents the parameters, no strong compensation is needed.

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?

States a specific verb ('Return') and resource ('a time series ... per tick for a completed backtest'), and distinguishes itself from siblings such as query_backtest_status by focusing on tick-level historical data. The description makes the tool's role immediately distinguishable from other backtest-related and portfolio tools.

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?

Explicitly says when to use the tool: to find suspicious single-tick portfolio value jumps without needing the codebase. It does not explicitly name excluded alternatives or when-not-to-use conditions, but the intended usage context is clear and actionable.

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

All NexusTrade Financial MCP toolsInspect
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