Backtest NIFTY option strategies on real 1-minute data, with an honest out-of-sample panel.
Scored across 11 tools
Most tools have clearly distinct purposes, but fetch and get_backtest overlap in retrieval by id, and describe_coverage/search have some conceptual overlap around discovering data coverage. The descriptions are detailed enough to disambiguate in most cases.
Tool names predominantly follow a snake_case verb_noun pattern (run_backtest, list_backtests, get_backtest, build_report, submit_feedback). Minor deviations exist with single-word verbs (fetch, search) and the noun phrase my_feedback, but overall the pattern is predictable.
Eleven tools is well within the ideal range and each tool earns its place in the platform's workflow: discovery, methodology, execution, retrieval, reporting, and feedback. The count feels complete without being bloated.
The tool surface covers the full lifecycle: understanding data and methodology, searching and fetching, running backtests, retrieving results, building reports, listing historical strategies/backtests, and filing/checking feedback. No obvious dead ends for the stated domain.
Creates a shareable report page for a backtest the user owns and returns its URL. The page carries the honesty panel, equity and drawdown curves, walk-forward folds, the gross-to-net breakdown, a month grid and the trade table, computed from the stored backtest. Use when the user asks for a report or something to share.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | 'link' (default) returns the hosted URL of the report page. 'artifact' returns the whole self-contained HTML document as well, which costs considerably more tokens. 'full' builds the full strategy report and returns its link: the strategy's rules in plain English, what it did to a given capital, every trade plotted on a zoomable NIFTY chart, the evidence panel and the capital curve. 'full' is rate limited. | link |
| capital | No | format '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_pct | No | format '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_pct | No | format 'full' only. Percent of capital used as margin on any one trade. Default 10. | |
| backtest_id | Yes | From a previous run_backtest. |
| Name | Required | Description |
|---|---|---|
| bytes | No | |
| message | No | |
| contains | No | |
| document | No | |
| mime_type | No | |
| report_url | No | |
| backtest_id | No | |
| document_properties | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations (readOnlyHint=false, destructiveHint=false) by disclosing that it creates a resource, returns a URL, mentions token costs for 'artifact', rate limiting for 'full', and refusal conditions for risky risk_pct calls. It also explains the report's interactive nature (user can change capital view). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence front-loads the core action and output, and the second gives the usage trigger. No redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values. It covers the report contents, ownership requirement, format options (via schema), and error conditions (via schema). It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is well-documented in the schema. The tool description adds no additional parameter semantics beyond what the schema already provides. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Creates a shareable report page for a backtest the user owns and returns its URL.' It clearly differentiates from siblings like get_backtest (which retrieves data) and run_backtest (which executes a backtest) by focusing on the report generation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the user asks for a report or something to share,' providing a clear when-to-use trigger. It does not name alternatives explicitly, but the context of siblings and the 'Use when' condition is sufficient for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What data is available: symbols, date range, resolution, structures, gates, biases, the cost model, and every known gap.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| from | No | |
| tier | No | |
| symbol | No | |
| resolution | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is clear. The description adds useful context by listing the scope of coverage, but doesn't disclose additional behavioral traits like whether it returns structured metadata or how gaps are defined. With annotations covering the core behavior, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that lists the key coverage items without waste. Every word earns its place, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool whose purpose is to describe data coverage, the description is complete. It enumerates the essential aspects an agent needs to know before using other tools, and an output schema likely covers the exact return structure. Nothing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with 100% coverage, so the baseline is 4. The description doesn't need to explain parameters, and it correctly focuses on what the tool returns. No gap here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (describe) and a clear resource (coverage), then enumerates the exact data aspects (symbols, date range, resolution, structures, gates, biases, cost model, gaps). This distinguishes it from siblings like build_report or explain_methodology, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it doesn't explicitly state when to use this tool versus alternatives, the name and description make the use case obvious: to learn what data is available. Given zero parameters and a self-explanatory purpose, explicit exclusions are unnecessary, but a brief mention of 'use this before querying data' would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How a result is produced: entry pricing, settlement, margin, slippage, the honesty rubric, and what each check can and cannot establish.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No |
| Name | Required | Description |
|---|---|---|
| body | No | |
| title | No | |
| topic | No | |
| topics | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety behavior is covered without contradiction. The description adds useful context about the tool's scope, including the 'honesty rubric' and 'what each check can and cannot establish,' which hints at limitations. However, it does not describe return behavior, output structure, or other operational traits beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main purpose and followed by a compact, informative list of covered topics. Every phrase adds meaning and there is no filler. It is efficiently structured for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, read-only, with an output schema), and the description covers the main thematic scope and even notes epistemic limitations. Still, it does not clarify what happens when topic is omitted, how to select among the enum options, or how the output is organized beyond relying on the output schema. These gaps are moderate given the availability of enum and schema information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the topic parameter, but it does not directly define how the parameter is used or why one would choose a value. It mentions several enum values in prose (margin, slippage, settlement) but not all, and gives no instruction on selection or default behavior. The enum itself is self-descriptive, but the description does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the subject matter: how a result is produced, covering specific elements such as entry pricing, settlement, margin, and slippage. It names the resource and gives a topical list, though it lacks an explicit verb like 'explains' and does not directly contrast with sibling tools. It is still specific enough to distinguish it as a methodology-explanation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as build_report, describe_coverage, or fetch. There are no exclusions, alternatives, or contextual conditions mentioned. The intended use is only implied by the topic list, leaving the agent to infer when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a document or backtest result by id, as returned by search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| text | No | |
| title | No | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile with readOnlyHint=true and destructiveHint=false. The description adds the useful provenance detail that ids come from search results, but it does not disclose additional behavioral nuances. This is adequate but minimal, given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. Every phrase earns its place, and there is no wasted repetition of the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with annotations and an output schema, the description covers the resource type and the id source. The main gap is the lack of explicit distinction from the sibling 'get_backtest', which leaves some ambiguity about which tool to invoke for backtest-related ids.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one string parameter with no description (0% coverage), so the description must compensate. It does add meaning by specifying that the id is one 'as returned by search', giving the agent a clear source for valid IDs. For a single simple parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and identifies the resource as 'a document or backtest result' retrieved by id, linking the id source to 'search'. It is clear about what the tool does, though it does not explicitly differentiate itself from the sibling tool 'get_backtest'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'as returned by search' implies that this tool is meant to retrieve items that were previously found via search, which is useful context. However, no explicit when-to-use or when-not-to-use guidance is provided relative to alternatives like 'get_backtest' or 'list_backtests'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a previous backtest result by its id — honesty panel, equity curve and per-trade detail, exactly as first computed.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | ||
| backtest_id | Yes |
| Name | Required | Description |
|---|---|---|
| spec | No | |
| trades | No | |
| honesty | No | |
| summary | No | |
| report_url | No | |
| backtest_id | No | |
| detail_note | No | |
| data_release | No | |
| trade_detail | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond those annotations: 'exactly as first computed' signals that the result is an immutable stored artifact, not recomputed or altered on retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that names the action, resource, and key content with no filler. Every phrase earns its place, and the most important identifier ('by its id') appears early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety, an output schema available, and a clear id-based retrieval action, the description is largely complete. The only notable gap is the undocumented 'detail' parameter semantics, but the enum values are reasonably self-explanatory and the output schema likely clarifies return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that backtest_id refers to a previous backtest result, but it does not explain the 'detail' parameter or its enum values ('summary', 'standard', 'full'). The phrase about honesty panel, equity curve, and per-trade detail hints at content but does not map those to detail levels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieve'), a precise resource ('previous backtest result by its id'), and the payload contents ('honesty panel, equity curve and per-trade detail'). It clearly distinguishes this from siblings like run_backtest (which creates new results) and list_backtests (which lists rather than retrieves a single result).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previous backtest result by its id' makes the primary use case clear: when the agent already has a backtest id and wants the stored result. It does not explicitly name alternatives or exclusion conditions, but the context of siblings and the 'previous' wording imply it is not for running new backtests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's backtests, newest first, with id, date, trade count, net P&L and report URL. Answers a request for the most recent run, which list_strategies does not: that one returns only results that passed the evidence checks, ranked by consistency rather than by date.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | No | |
| backtests | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive behavior. The description adds meaningful behavioral context: results are scoped to the account, sorted newest-first, and include specific fields plus a report URL. It does not contradict the annotations and provides useful detail beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The core result information is front-loaded, and the comparative guidance about list_strategies is placed second. Every clause contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with an output schema present and a single self-explanatory parameter, the description covers scope, ordering, and key fields. Annotations cover safety, and the output schema handles return structure. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, `limit`, has zero schema description coverage, and the tool description does not mention it at all. Since schema descriptions are absent, the description should compensate by explaining the parameter's effect, but it remains unexplained. The parameter name and constraints provide some hints, but the description adds no meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('the account's backtests'), the ordering ('newest first'), and the exact returned fields (id, date, trade count, net P&L, report URL). It also explicitly differentiates this tool from list_strategies, so the agent knows exactly what this tool does and what it does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a direct usage rule: use this when you need the most recent run, and explicitly says list_strategies is the wrong alternative because it returns only evidence-passed results ranked by consistency. This is a clear when-to-use vs. when-not-to-use distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strategies from THIS account's history that held up under out-of-sample and walk-forward checks, not merely ones that made money. Ranked by worst walk-forward fold — consistency, not size. Answers what has worked on this account so far without re-running anything.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| order | No | 'consistency' (default) sorts by worst walk-forward fold, then median fold. 'pnl' sorts by total P&L and is the ranking most likely to put an overfit at the top. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | No | |
| strategies | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes further by explaining the selection behavior (out-of-sample and walk-forward validation), the ranking behavior (by worst walk-forward fold, consistency over size), and explicitly notes 'without re-running anything,' which confirms no side effects and adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The core selection criterion is front-loaded, the ranking philosophy is stated clearly, and the read-only benefit is added at the end. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, clear annotations, and documented parameters, the description covers the essential purpose, selection criteria, ranking, and read-only nature. Nothing an agent needs to decide whether to call this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (order has a description, limit does not). The tool description adds semantic value by clarifying what the default consistency ranking means ('Ranked by worst walk-forward fold — consistency, not size'), which enriches the order parameter. The limit parameter is self-evident from its type and bounds, so the description does not need to elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific resource ('strategies from THIS account's history') and a specific filtering criterion ('held up under out-of-sample and walk-forward checks'), and contrasts with 'not merely ones that made money.' This distinguishes it from sibling tools like list_backtests and run_backtest without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong context: it answers what has worked without re-running anything, implying when to use it (when you want validated historical strategies) and when not (when you need a fresh backtest or pure P&L ranking). It does not explicitly name alternative tools, so it stops short of a full 5, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports this account has filed, and where each one stands. Use it to answer 'did that bug I reported ever get fixed?'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds useful behavioral context: it scopes results to 'this account' and indicates the output includes the status ('where each one stands') of each filed report. This goes beyond the structured fields and gives the agent a good sense of what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero fluff. The first sentence states the core function, the second gives a concrete use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool with an output schema and strong annotations, the description fully covers what an agent needs: what the tool does, what data it scopes to, and when to use it. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing for the description to explain. Under the rules, a zero-parameter tool gets a baseline of 4, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: reporting the account's filed reports and their statuses. The use-case example 'did that bug I reported ever get fixed?' clearly differentiates it from sibling tools like submit_feedback (which files reports) and build_report (which likely creates new reports), even though it doesn't name alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete scenario ('did that bug I reported ever get fixed?') that tells an agent when to use this tool. It does not list exclusions or alternatives, but the context is clear enough to route an agent to the right tool for status-checking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Backtest an Indian index option strategy on real 1-minute NIFTY options data. Returns P&L after real charges and slippage, return-on-margin, and an honesty panel: out-of-sample split, walk-forward folds, bootstrap interval, and a deflated Sharpe that accounts for how many variants you have already tried. Refuses windows too narrow to be meaningful, and reports no ratios below 30 trades. Two spec forms: a PRESET (structure + params) for the common shapes, or an OPEN STRATEGY (legs + rules) for anything else — any number of legs at any strikes on any expiry, strikes chosen by percent, points, premium or delta, entry at any minute, and rules that CHANGE the position while it is live (roll a tested leg, close one side, add a hedge, trail a stop) plus book-level rules like standing down after three losers. Nothing here is restricted by tier; a paid tier only widens the date window.
| Name | Required | Description | Default |
|---|---|---|---|
| lots | No | ||
| spec | Yes | Either a preset spec (structure + params) or an open strategy (legs + rules). Use the open form for anything the presets cannot say. | |
| detail | No | How much per-trade data to return. 'standard' (default) is the equity curve, breakdowns and the first 25 trades with their leg prices. 'full' returns up to 300 trades — ask for it when the caller wants to audit or chart every trade. 'summary' returns aggregates only, and is the cheapest to read. |
| Name | Required | Description |
|---|---|---|
| spec | No | |
| quota | No | |
| trades | No | |
| honesty | No | |
| summary | No | |
| breakdown | No | |
| report_url | No | |
| backtest_id | No | |
| methodology | No | |
| cost_seconds | No | |
| data_release | No | |
| equity_curve | No | |
| trade_detail | No | |
| strategy_book | No | |
| interpretation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior far beyond the sparse annotations: it refuses too-narrow windows, suppresses ratios below 30 trades, applies real charges and slippage, reports a detailed honesty panel, and notes that tier only affects the date window. This gives the agent essential expectations about side effects, data realism, and statistical guardrails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and outputs, then moves through behavioral constraints, spec forms, and tier behavior. It is dense and somewhat run-on, but every clause adds a distinct fact needed to invoke the tool correctly. Restructuring into shorter sentences would improve scannability without cutting content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested spec schema and the presence of an output schema, the description covers invocation-critical context thoroughly: minimum sample size, refusal conditions, data realism, result contents, tier limitations, and the boundary between preset and open strategies. Nothing essential appears missing for an agent deciding how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful high-level semantics for the `spec` parameter: preset versus open strategy, strike selection by percent/points/premium/delta, live-adjustment rules, and portfolio-level rules. However, the top-level `lots` parameter is not explained in either the schema or the description, leaving a small semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific action ('Backtest'), a specific resource ('Indian index option strategy on real 1-minute NIFTY options data'), and the key outputs (P&L after real charges and slippage, return-on-margin). This cleanly distinguishes run_backtest from retrieval siblings like get_backtest and list_backtests without forcing the agent to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on choosing between the PRESET and OPEN strategy forms ('Use the open form for anything the presets cannot say') and explains scope/cadence choices such as any number of legs, live position-changing rules, and book-level rules. It does not explicitly name sibling tools or state when not to use run_backtest versus build_report/explain_methodology, but the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search what this service covers — symbols, dates, structures, signals, methodology. Returns ids usable with fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns ids usable with fetch, which is useful behavioral context. It does not describe pagination, result limits, or how query matching works, but for a read-only search tool with annotations, the description provides adequate additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and then adds the key detail about return ids. Every word earns its place, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, an output schema, and read-only annotations, so the description does not need to explain return values in detail. It covers the search scope and the relationship to fetch. However, it lacks guidance on query formulation and result limits, which would make it more complete for an agent deciding how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single 'query' parameter. The description says 'Search what this service covers' and lists example content areas, which implies the query is a free-text search string, but it does not explain query syntax, expected format, or how results are matched. With only one parameter and no schema description, the description should provide more explicit guidance on what to put in 'query'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('what this service covers'), and enumerates the kinds of things it covers: symbols, dates, structures, signals, methodology. It also notes that results are ids usable with fetch, which helps distinguish it from other tools. It does not explicitly name a sibling alternative, but the scope is clear enough to differentiate from fetch and the other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to discover what the service covers and obtain ids for later fetching. It does not explicitly state when not to use it or name alternatives, but the mention of 'ids usable with fetch' gives a clear usage context. Sibling names like describe_coverage and explain_methodology suggest related tools, but the description does not contrast with them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Files a bug report or feature request when the user asks to report something. Confirm the title and body with the user before filing. Passing backtest_id attaches that backtest's spec so the issue can be reproduced.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | What was expected, what happened, and any spec involved. Write it from the user's report, not from your own summary of it. | |
| title | Yes | One line naming the problem or request. | |
| category | No | Omit it and it will be inferred from the text. | |
| severity | No | ||
| backtest_id | No | The result this is about, if any. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| status | No | |
| message | No | |
| category | No | |
| severity | No | |
| feedback_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide read-only and destructive hints; the description adds real behavioral context: confirmation before filing and the fact that passing backtest_id attaches the backtest's spec for reproducibility. It could say more about side effects or destinations, but the key behaviors are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and trigger, then the key behavior and parameter nuance. Every sentence earns its place and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with an output schema and no nested objects, the description covers purpose, trigger, confirmation step, and the most important parameter behavior. Minor gaps such as not naming alternatives are present, but the overall package is agent-actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 80% schema coverage, the baseline is 3, but the description adds meaningful semantics by explaining that backtest_id attaches the backtest spec so the issue can be reproduced. The confirmation instruction also reinforces the role of title and body. Severity is not elaborated, but the schema already provides an enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Files a bug report or feature request') and the trigger condition ('when the user asks to report something'). It does not explicitly distinguish this from the sibling tool my_feedback, but the scope is understandable and specific enough for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an actionable trigger condition ('when the user asks to report something') and a required pre-step ('Confirm the title and body with the user before filing'). It does not mention when not to use the tool or name alternatives, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
build_report3 fields changedInput schema / properties / format / defaultAdded value: +"link"Input schema / properties / format / descriptionPrevious value: -"'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."New value: +"'link' (default) returns the hosted URL of the report page. 'artifact' returns the whole self-contained HTML document as well, which costs considerably more tokens. 'full' builds the full strategy report and returns its link: the strategy's rules in plain English, what it did to a given capital, every trade plotted on a zoomable NIFTY chart, the evidence panel and the capital curve. 'full' is rate limited."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "backtest_id": {
+ "type": "string"
+ },
+ "bytes": {
+ "type": "integer"
+ },
+ "contains": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "document": {
+ "type": "string"
+ },
+ "document_properties": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "mime_type": {
+ "type": "string"
+ },
+ "report_url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}describe_coverage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "resolution": {
+ "type": "string"
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}explain_methodology1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic": {
+ "type": "string"
+ },
+ "topics": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}fetch1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "metadata": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_backtest1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "backtest_id": {
+ "type": "string"
+ },
+ "data_release": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "detail_note": {
+ "type": "string"
+ },
+ "honesty": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "report_url": {
+ "type": "string"
+ },
+ "spec": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "trade_detail": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "trades": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}list_backtestslist_strategies1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "note": {
+ "type": "string"
+ },
+ "strategies": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}my_feedback1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "items": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}run_backtest2 fields changedInput schema / properties / spec / oneOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "bias": {
- "description": "Chooses the side each cycle for directional structures. 'neutral' to use a fixed direction instead.",
- "type": "string"
- },
- "cadence": {
- "description": "'weekly' (default) enters ONCE per expiry, on the day matching entry_dte — about 58 trades a year. 'daily' enters EVERY trading session on whichever expiry is nearest — about 246. Use 'daily' for anything described as 'every day'.",
- "enum": [
- "weekly",
- "daily"
- ],
- "type": "string"
- },
- "entry_time": {
- "description": "IST. EOD is 15:29, the last tradeable minute.",
- "enum": [
- "09:15",
- "09:30",
- "11:00",
- "12:00",
- "12:30",
- "13:00",
- "14:00",
- "15:00",
- "EOD"
- ],
- "type": "string"
- },
- "exit_time": {
- "description": "IST clock exit — squares the position off the SAME session, so it never reaches expiry. Omit to hold until a stop, a target or settlement. Must be after entry_time. Set this to express an intraday round trip such as in at 11:00, out at 14:00.",
- "enum": [
- "09:15",
- "09:30",
- "11:00",
- "12:00",
- "12:30",
- "13:00",
- "14:00",
- "15:00",
- "EOD"
- ],
- "type": "string"
- },
- "gate": {
- "description": "Entry filter; 'always' to disable.",
- "type": "string"
- },
- "max_dte": {
- "description": "cadence 'daily' only: skip sessions where the nearest expiry is further out than this. max_dte 0 is expiry-day only.",
- "maximum": 45,
- "minimum": 0,
- "type": "integer"
- },
- "overlay": {
- "description": "Volatility filter: 'vol20' skips a cycle when the index's 20-day realised volatility is above 20% at entry. Omit for none.",
- "pattern": "^vol[0-9]{1,3}$",
- "type": "string"
- },
- "params": {
- "description": "Structure parameters. pct_offset and pct_width are percent of spot. sl_mult is a multiple of the credit received; sl_pct and tp_pct are fractions of premium paid. entry_dte is days to expiry at entry. direction is CE or PE for directional structures, and must be omitted when a bias is set.",
- "properties": {
- "direction": {
- "enum": [
- "CE",
- "PE"
- ],
- "type": "string"
- },
- "entry_days_before": {
- "description": "Entry day as TRADING SESSIONS before expiry (0 = expiry day, 2 = 'T-2'), instead of calendar entry_dte. Set one or the other.",
- "maximum": 30,
- "minimum": 0,
- "type": "integer"
- },
- "entry_dte": {
- "maximum": 45,
- "minimum": 0,
- "type": "integer"
- },
- "pct_offset": {
- "maximum": 20,
- "minimum": 0,
- "type": "number"
- },
- "pct_width": {
- "maximum": 20,
- "minimum": 0,
- "type": "number"
- },
- "sl_mult": {
- "exclusiveMinimum": 0,
- "type": "number"
- },
- "sl_pct": {
- "exclusiveMinimum": 0,
- "maximum": 1,
- "type": "number"
- },
- "tp_pct": {
- "exclusiveMinimum": 0,
- "type": "number"
- }
- },
- "type": "object"
- },
- "period": {
- "additionalProperties": false,
- "description": "YYYY-MM-DD, inside 2025-07-01 to 2026-06-30.",
- "properties": {
- "from": {
- "type": "string"
- },
- "to": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "structure": {
- "description": "Option structure to trade.",
- "enum": [
- "credit_spread",
- "iron_condor",
- "iron_fly",
- "long_option",
- "short_strangle"
- ],
- "type": "string"
- },
- "symbol": {
- "description": "Free tier serves NIFTY only.",
- "enum": [
- "NIFTY"
- ],
- "type": "string"
- }
- },
- "required": [
- "structure",
- "params"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "description": "An open strategy: any legs, any rules. Use this whenever the idea does not fit a preset — ratio spreads, calendars, diagonals, jade lizards, broken wings, delta- or premium-selected strikes, per-leg stops, rolling a tested side, trailing stops, entry conditions on the credit available, and book-level rules like standing down after three losers.",
- "properties": {
- "entry": {
- "additionalProperties": false,
- "properties": {
- "cadence": {
- "description": "weekly = one entry per weekly expiry; monthly = one per monthly expiry (the last of its calendar month); daily = one per session.",
- "enum": [
- "weekly",
- "daily",
- "monthly"
- ],
- "type": "string"
- },
- "dte": {
- "description": "weekly/monthly only: days before expiry to enter. Defaults to 4 weekly, 21 monthly.",
- "maximum": 60,
- "minimum": 0,
- "type": "integer"
- },
- "max_dte": {
- "description": "daily only: skip sessions further than this from expiry.",
- "maximum": 60,
- "minimum": 0,
- "type": "integer"
- },
- "time": {
- "description": "ANY minute of the session, e.g. '09:20'. Not a grid.",
- "type": "string"
- },
- "when": {
- "description": "Optional gate on the cycle — the REASON for taking the trade. combined_premium is the credit on offer, so {\"combined_premium\": {\"gte\": 80}} means 'only if I collect 80 points'. Market state is here too: day_of_week, gap_pct, prev_day_move_pct, realised_vol_20d, vix, vix_change_pct, vix_prev_close. e.g. {\"vix\": {\"gte\": 15}}, {\"prev_day_move_pct\": {\"lte\": -1}}, {\"day_of_week\": {\"eq\": 1}} for Mondays. INDEX INDICATORS too, computed on closes up to YESTERDAY: rsi_N (0-100), close_vs_sma_N_pct and close_vs_ema_N_pct (per cent above/below the N-day average), ema_F_vs_S_pct and sma_F_vs_S_pct (fast against slow, positive = fast is above). N from 2 to 250. e.g. {\"rsi_14\": {\"lt\": 30}} for oversold, {\"close_vs_ema_50_pct\": {\"gt\": 0}} for 'above the 50-day', {\"ema_9_vs_21_pct\": {\"gt\": 0}} for a 9/21 crossover. All are knowable before the session — none can see the day's own close.",
- "type": "object"
- }
- },
- "type": "object"
- },
- "exit": {
- "additionalProperties": false,
- "properties": {
- "time": {
- "description": "hard square-off at this minute on the entry day.",
- "type": "string"
- },
- "when": {
- "type": "object"
- }
- },
- "type": "object"
- },
- "legs": {
- "description": "What to open. Leg order defines the indices rules use.",
- "items": {
- "additionalProperties": false,
- "properties": {
- "expiry": {
- "description": "'near' is the nearest expiry at entry; 'next' is the one after, which is how a calendar or diagonal is written.",
- "enum": [
- "near",
- "next",
- "far"
- ],
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "qty": {
- "description": "lots of THIS leg relative to the others. Unequal quantities are how a ratio spread is written.",
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
- },
- "side": {
- "enum": [
- "sell",
- "buy"
- ],
- "type": "string"
- },
- "strike": {
- "description": "How to pick the strike. One of: {\"pct_offset\": 1.0} percent from spot (negative for puts) | {\"points_offset\": 200} | \"atm\" | {\"strike\": 24000} | {\"premium_near\": 50} the strike whose last real print is nearest 50 points | {\"delta_near\": 0.20} | {\"from_leg\": {\"leg\": 0, \"pct\": 0.5}} relative to another leg. Add {\"ref\": \"entry\"} to measure from the spot at entry rather than the spot now."
- },
- "type": {
- "enum": [
- "CE",
- "PE"
- ],
- "type": "string"
- }
- },
- "required": [
- "side",
- "type",
- "strike"
- ],
- "type": "object"
- },
- "maxItems": 12,
- "minItems": 1,
- "type": "array"
- },
- "max_adjustments": {
- "description": "how many times the rules may change the position in one trade. Default 4.",
- "maximum": 50,
- "minimum": 0,
- "type": "integer"
- },
- "name": {
- "type": "string"
- },
- "period": {
- "additionalProperties": false,
- "properties": {
- "from": {
- "type": "string"
- },
- "to": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "portfolio": {
- "additionalProperties": false,
- "description": "Rules over the SEQUENCE of trades, which no per-trade condition can express.",
- "properties": {
- "max_trades": {
- "minimum": 1,
- "type": "integer"
- },
- "skip_after_loss": {
- "type": "boolean"
- },
- "stop_after_drawdown_pct": {
- "type": "number"
- },
- "stop_after_losses": {
- "minimum": 1,
- "type": "integer"
- },
- "stop_after_profit_pct": {
- "type": "number"
- }
- },
- "type": "object"
- },
- "resolution": {
- "description": "minutes per rule check. 1 is the default and the honest one.",
- "enum": [
- 1,
- 5,
- 15
- ],
- "type": "integer"
- },
- "rules": {
- "description": "Checked every minute, in order; the first match fires. Fields: adjustments_done, combined_premium, credit_kept_pct, day_of_week, drawdown_from_peak, dte, gap_pct, leg_mark, leg_mark_delta, leg_mark_mult, leg_pnl_pts, minutes_held, pnl_pct_of_credit, pnl_pct_of_max, pnl_pts, pnl_rupees, prev_day_move_pct, realised_vol_20d, runup_from_trough, spot, spot_beyond_strike, spot_move_pct, spot_move_pts, time, vix, vix_change_pct, vix_prev_close. Actions: \"close\" | {\"close_legs\": [0]} | {\"open\": [leg,...]} | {\"roll\": {\"legs\": [0], \"to\": strike}} | {\"close_and_open\": {\"close\": [0], \"open\": [leg]}}.",
- "items": {
- "additionalProperties": false,
- "properties": {
- "label": {
- "type": "string"
- },
- "max_times": {
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
- },
- "then": {},
- "when": {
- "type": "object"
- }
- },
- "required": [
- "when",
- "then"
- ],
- "type": "object"
- },
- "maxItems": 24,
- "type": "array"
- },
- "symbol": {
- "enum": [
- "NIFTY"
- ],
- "type": "string"
- }
- },
- "required": [
- "legs"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "bias": {
+ "description": "Chooses the side each cycle for directional structures. 'neutral' to use a fixed direction instead.",
+ "type": "string"
+ },
+ "cadence": {
+ "description": "'weekly' (default) enters ONCE per expiry, on the day matching entry_dte — about 58 trades a year. 'daily' enters EVERY trading session on whichever expiry is nearest — about 246. Use 'daily' for anything described as 'every day'.",
+ "enum": [
+ "weekly",
+ "daily"
+ ],
+ "type": "string"
+ },
+ "entry_time": {
+ "description": "IST. EOD is 15:29, the last tradeable minute.",
+ "enum": [
+ "09:15",
+ "09:30",
+ "11:00",
+ "12:00",
+ "12:30",
+ "13:00",
+ "14:00",
+ "15:00",
+ "EOD"
+ ],
+ "type": "string"
+ },
+ "exit_time": {
+ "description": "IST clock exit — squares the position off the SAME session, so it never reaches expiry. Omit to hold until a stop, a target or settlement. Must be after entry_time. Set this to express an intraday round trip such as in at 11:00, out at 14:00.",
+ "enum": [
+ "09:15",
+ "09:30",
+ "11:00",
+ "12:00",
+ "12:30",
+ "13:00",
+ "14:00",
+ "15:00",
+ "EOD"
+ ],
+ "type": "string"
+ },
+ "gate": {
+ "description": "Entry filter; 'always' to disable.",
+ "type": "string"
+ },
+ "max_dte": {
+ "description": "cadence 'daily' only: skip sessions where the nearest expiry is further out than this. max_dte 0 is expiry-day only.",
+ "maximum": 45,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "overlay": {
+ "description": "Volatility filter: 'vol20' skips a cycle when the index's 20-day realised volatility is above 20% at entry. Omit for none.",
+ "pattern": "^vol[0-9]{1,3}$",
+ "type": "string"
+ },
+ "params": {
+ "description": "Structure parameters. pct_offset and pct_width are percent of spot. sl_mult is a multiple of the credit received; sl_pct and tp_pct are fractions of premium paid. entry_dte is days to expiry at entry. direction is CE or PE for directional structures, and must be omitted when a bias is set.",
+ "properties": {
+ "direction": {
+ "enum": [
+ "CE",
+ "PE"
+ ],
+ "type": "string"
+ },
+ "entry_days_before": {
+ "description": "Entry day as TRADING SESSIONS before expiry (0 = expiry day, 2 = 'T-2'), instead of calendar entry_dte. Set one or the other.",
+ "maximum": 30,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "entry_dte": {
+ "maximum": 45,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "pct_offset": {
+ "maximum": 20,
+ "minimum": 0,
+ "type": "number"
+ },
+ "pct_width": {
+ "maximum": 20,
+ "minimum": 0,
+ "type": "number"
+ },
+ "sl_mult": {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ "sl_pct": {
+ "exclusiveMinimum": 0,
+ "maximum": 1,
+ "type": "number"
+ },
+ "tp_pct": {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "period": {
+ "additionalProperties": false,
+ "description": "YYYY-MM-DD, inside 2025-07-01 to 2026-06-30.",
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "structure": {
+ "description": "Option structure to trade.",
+ "enum": [
+ "credit_spread",
+ "iron_condor",
+ "iron_fly",
+ "long_option",
+ "short_strangle"
+ ],
+ "type": "string"
+ },
+ "symbol": {
+ "description": "Free tier serves NIFTY only.",
+ "enum": [
+ "NIFTY"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "structure",
+ "params"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "description": "An open strategy: any legs, any rules. Covers what the presets cannot say — ratio spreads, calendars, diagonals, jade lizards, broken wings, delta- or premium-selected strikes, per-leg stops, rolling a tested side, trailing stops, entry conditions on the credit available, and book-level rules like standing down after three losers.",
+ "properties": {
+ "entry": {
+ "additionalProperties": false,
+ "properties": {
+ "cadence": {
+ "description": "weekly = one entry per weekly expiry; monthly = one per monthly expiry (the last of its calendar month); daily = one per session.",
+ "enum": [
+ "weekly",
+ "daily",
+ "monthly"
+ ],
+ "type": "string"
+ },
+ "dte": {
+ "description": "weekly/monthly only: days before expiry to enter. Defaults to 4 weekly, 21 monthly.",
+ "maximum": 60,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "max_dte": {
+ "description": "daily only: skip sessions further than this from expiry.",
+ "maximum": 60,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "time": {
+ "description": "ANY minute of the session, e.g. '09:20'. Not a grid.",
+ "type": "string"
+ },
+ "when": {
+ "description": "Optional gate on the cycle — the REASON for taking the trade. combined_premium is the credit on offer, so {\"combined_premium\": {\"gte\": 80}} means 'only if I collect 80 points'. Market state is here too: day_of_week, gap_pct, prev_day_move_pct, realised_vol_20d, vix, vix_change_pct, vix_prev_close. e.g. {\"vix\": {\"gte\": 15}}, {\"prev_day_move_pct\": {\"lte\": -1}}, {\"day_of_week\": {\"eq\": 1}} for Mondays. INDEX INDICATORS too, computed on closes up to YESTERDAY: rsi_N (0-100), close_vs_sma_N_pct and close_vs_ema_N_pct (per cent above/below the N-day average), ema_F_vs_S_pct and sma_F_vs_S_pct (fast against slow, positive = fast is above). N from 2 to 250. e.g. {\"rsi_14\": {\"lt\": 30}} for oversold, {\"close_vs_ema_50_pct\": {\"gt\": 0}} for 'above the 50-day', {\"ema_9_vs_21_pct\": {\"gt\": 0}} for a 9/21 crossover. All are knowable before the session — none can see the day's own close.",
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "exit": {
+ "additionalProperties": false,
+ "properties": {
+ "time": {
+ "description": "hard square-off at this minute on the entry day.",
+ "type": "string"
+ },
+ "when": {
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "legs": {
+ "description": "What to open. Leg order defines the indices rules use.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "expiry": {
+ "description": "'near' is the nearest expiry at entry; 'next' is the one after, which is how a calendar or diagonal is written.",
+ "enum": [
+ "near",
+ "next",
+ "far"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "qty": {
+ "description": "lots of THIS leg relative to the others. Unequal quantities are how a ratio spread is written.",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "side": {
+ "enum": [
+ "sell",
+ "buy"
+ ],
+ "type": "string"
+ },
+ "strike": {
+ "description": "How to pick the strike. One of: {\"pct_offset\": 1.0} percent from spot (negative for puts) | {\"points_offset\": 200} | \"atm\" | {\"strike\": 24000} | {\"premium_near\": 50} the strike whose last real print is nearest 50 points | {\"delta_near\": 0.20} | {\"from_leg\": {\"leg\": 0, \"pct\": 0.5}} relative to another leg. Add {\"ref\": \"entry\"} to measure from the spot at entry rather than the spot now."
+ },
+ "type": {
+ "enum": [
+ "CE",
+ "PE"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "side",
+ "type",
+ "strike"
+ ],
+ "type": "object"
+ },
+ "maxItems": 12,
+ "minItems": 1,
+ "type": "array"
+ },
+ "max_adjustments": {
+ "description": "how many times the rules may change the position in one trade. Default 4.",
+ "maximum": 50,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "period": {
+ "additionalProperties": false,
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "portfolio": {
+ "additionalProperties": false,
+ "description": "Rules over the SEQUENCE of trades, which no per-trade condition can express.",
+ "properties": {
+ "max_trades": {
+ "minimum": 1,
+ "type": "integer"
+ },
+ "skip_after_loss": {
+ "type": "boolean"
+ },
+ "stop_after_drawdown_pct": {
+ "type": "number"
+ },
+ "stop_after_losses": {
+ "minimum": 1,
+ "type": "integer"
+ },
+ "stop_after_profit_pct": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "resolution": {
+ "description": "minutes per rule check. 1 is the default and the honest one.",
+ "enum": [
+ 1,
+ 5,
+ 15
+ ],
+ "type": "integer"
+ },
+ "rules": {
+ "description": "Checked every minute, in order; the first match fires. Fields: adjustments_done, combined_premium, credit_kept_frac, day_of_week, drawdown_from_peak, dte, gap_pct, leg_mark, leg_mark_delta, leg_mark_mult, leg_pnl_pts, minutes_held, pnl_frac_of_credit, pnl_frac_of_max, pnl_pts, pnl_rupees, prev_day_move_pct, realised_vol_20d, runup_from_trough, spot, spot_beyond_strike, spot_move_pct, spot_move_pts, time, vix, vix_change_pct, vix_prev_close. Actions: \"close\" | {\"close_legs\": [0]} | {\"open\": [leg,...]} | {\"roll\": {\"legs\": [0], \"to\": strike}} | {\"close_and_open\": {\"close\": [0], \"open\": [leg]}}.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "max_times": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "then": {},
+ "when": {
+ "type": "object"
+ }
+ },
+ "required": [
+ "when",
+ "then"
+ ],
+ "type": "object"
+ },
+ "maxItems": 24,
+ "type": "array"
+ },
+ "symbol": {
+ "enum": [
+ "NIFTY"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "legs"
+ ],
+ "type": "object"
+ }
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "backtest_id": {
+ "type": "string"
+ },
+ "breakdown": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "cost_seconds": {
+ "type": "number"
+ },
+ "data_release": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "equity_curve": {
+ "type": "array"
+ },
+ "honesty": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "interpretation": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "methodology": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "quota": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "report_url": {
+ "type": "string"
+ },
+ "spec": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "strategy_book": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "trade_detail": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "trades": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}search1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}submit_feedback1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "feedback_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "severity": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}build_reportdescribe_coverageexplain_methodologyfetchget_backtestlist_strategiesmy_feedbackrun_backtestsearchsubmit_feedbackHonest A-F grades for trading strategies, backtested on real out-of-sample data. No hype.
Honest backtests and paper trading for US options and equities, driven by your agent.
Backtest plain-English trading strategies on real market data: graded results, honesty flags.
Backtest strategies and analyze portfolios on any ticker: CAGR, drawdown, Sharpe, from real data.
Add one secure layer between your agents and this server.
