Skip to main content
Glama

Stratify

by site.aeon-labs
OverviewDiscussionsAdmin

build_report

Turn a stored backtest into a finished, self-contained Stratify report — one HTML document with the honesty panel, equity and drawdown curves, walk-forward folds, the gross-to-net breakdown, a month grid and the trade table. PUBLISH THE RETURNED HTML VERBATIM AS AN ARTIFACT (Claude), a canvas document (ChatGPT, Gemini), or write it to a .html file (CLI clients). Do not rewrite it, summarise it into your own chart code, or regenerate the figures — the numbers in it came from the backtest, and anything you redraw from a table is a second source that can disagree with the first. It needs no network, no libraries and no build step, and it renders on light and dark. Use it when someone asks for a report, a summary they can keep, something to share, or an artifact.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNo'artifact' (default) returns the whole document to publish. 'link' returns only the hosted URL — far cheaper in tokens, and the right choice when the user just wants to look at it rather than keep it. 'full' builds the FULL STRATEGY REPORT and returns its link: the strategy's rules in plain English, what it did to ₹10 lakh of capital, every trade plotted on a zoomable NIFTY chart, the evidence panel, and the capital curve. Ask for it whenever someone wants to really understand a strategy rather than glance at it. It is rate limited.
capitalNoformat 'full' only. Starting capital in rupees. It sets the report's OPENING view — the reader can change it in the page without a new report. Default 1,000,000.
risk_pctNoformat 'full' only. Size by RISK instead of margin: the percent of capital the trade is allowed to lose in its worst case (2 means 'risk 2% per trade'). Only works where the position has a bounded worst case — a naked short does not, and the call is refused with that reason rather than sized off a guess. Overrides deploy_pct.
deploy_pctNoformat 'full' only. Percent of capital used as margin on any one trade. Default 10.
backtest_idYesFrom a previous run_backtest.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

The description discloses that the tool returns a complete HTML document that must be published verbatim, and warns against regenerating figures from tables. This adds context beyond the sparse annotations (readOnlyHint=false, destructiveHint=false). It doesn't mention rate limits or side effects, but the schema covers the rate limit for 'full' format.

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?

The description is front-loaded with the core purpose and then provides necessary handling instructions for the returned HTML. Each sentence serves a purpose: defining the output, instructing verbatim publication, warning against redrawing, and stating when to use the tool. It is slightly long but not wasteful.

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?

The description tells the agent what the output is, how to handle it, and when to use it. It also implicitly covers the main workflow (after run_backtest). Since there is no output schema, the description's explanation of the HTML document's contents fills that gap. Combined with a fully described input schema, this is complete for the tool's complexity.

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?

The input schema provides detailed descriptions for all five parameters, including the format enum's behavior and the purpose of capital, risk_pct, and deploy_pct. Since schema coverage is 100%, the description is not required to add parameter details. It does not, so a baseline score of 3 is appropriate.

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 action: turning a stored backtest into a finished, self-contained Stratify report. It names the output type (one HTML document) and lists the included components, making the tool's function unambiguous. It clearly distinguishes from siblings like run_backtest and get_backtest by focusing on report generation from an existing backtest.

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 explicitly says when to use the tool: 'when someone asks for a report, a summary they can keep, something to share, or an artifact.' It also implies it is for already-stored backtests, distinguishing it from run_backtest. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of full guidance.

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

All Stratify 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