Algo Trade Analytics

stress_test_candidate

stress_test_candidate

Read-onlyIdempotent

Probe robustness across alternate scopes, costs, and perturbations for a required experiment protocolId.

Input Schema

TableJSON Schema

Name	Required	Description
`symbol`	Yes
`endDate`	Yes
`startDate`	Yes
`timeframe`	Yes
`protocolId`	Yes	Experiment protocol id returned by define_experiment_protocol for this exact candidate-evaluation check.
`caseStudyId`	No	Optional: bind this call to one of your case studies. Defaults to the bound run's case study.
`constraints`	No
`maxVariants`	No
`researchRunId`	No	Optional: bind this call to one of your existing research runs. Defaults to this session's most recent unfinished run.
`baselineInputs`	No	Optional input overrides as a JSON-stringified object, e.g. '{"SMA Length":14}'. Keys are Pine input names; values are number, string, or boolean.
`baselineSource`	No	Pine source of the comparison baseline. Omit to use the platform benchmark baseline for this scope, which declares 1bp commission per side and 2 ticks slippage so the comparison is not a costed candidate against a zero-cost control.
`evaluationMode`	No
`trainTestSplit`	No
`candidateInputs`	No	Optional input overrides as a JSON-stringified object, e.g. '{"SMA Length":14}'. Keys are Pine input names; values are number, string, or boolean.
`candidateSource`	Yes
`objectiveMetric`	No
`mcpIdempotencyKey`	No	Unique key for this logical action. Reuse it only when retrying the same arguments. Required for hosted trust-creating actions when no idempotency header is supplied.
`objectiveDirection`	No
`sourceExperimentId`	No
`candidateVersionHash`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 17, 2026

addedInput schema / properties / baselineSource / anyOf

Added value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / baselineSource / description

Added value: +"Pine source of the comparison baseline. Omit to use the platform benchmark baseline for this scope, which declares 1bp commission per side and 2 ticks slippage so the comparison is not a costed candidate against a zero-cost control."

removedInput schema / properties / baselineSource / minLength
```
Removed value: -1
```
removedInput schema / properties / baselineSource / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "symbol",
-  "timeframe",
-  "startDate",
-  "endDate",
-  "baselineSource",
-  "candidateSource",
-  "protocolId"
-]New value: +[
+  "symbol",
+  "timeframe",
+  "startDate",
+  "endDate",
+  "candidateSource",
+  "protocolId"
+]

First observedSep 16, 2026

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that it probes across scope, cost, and perturbations, but does not disclose return behavior, number of variants, or whether it runs asynchronously. With annotations present, this is acceptable but not rich.

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

Conciseness3/5

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

The description is a single, front-loaded sentence, which is efficient and easy to parse. However, for a tool with 20 parameters and no output schema, the brevity borders on under-specification and introduces a rambling, unstructured feel without guiding the reader through complex usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high parameter count, low schema coverage, and absence of an output schema, this description is inadequate for an agent to call the tool correctly. It lacks parameter details, usage context, and expectations about results, making it difficult for an agent to select and invoke appropriately.

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

Parameters2/5

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

Schema description coverage is only 35%, so the description must compensate for undocumented parameters like candidateSource, evaluationMode, constraints, and maxVariants. The description does not mention any parameter semantics, leaving the agent to guess the meaning of critical inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'probe' naming the resource 'robustness' and explicitly scopes it 'across alternate scopes, costs, and perturbations' with a required protocolId. It is reasonably specific but does not clearly differentiate from overlapping siblings like analyze_parameter_robustness or run_parameter_sweep.

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

Usage Guidelines2/5

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

No guidance is provided about when to use this tool versus the many sibling tools such as evaluate_candidate, run_parameter_sweep, or walk_forward_candidate. There is no mention of prerequisites, exclusions, or decision criteria for choosing this tool over alternatives.

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

All Algo Trade Analytics 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.

Resources

Need Help?