Algo Trade Analytics

verify_candidate

verify_candidate

Read-onlyIdempotent

Apply materiality and risk gates for a required experiment protocolId before any promotion language. Set confirmation:true with a persisted candidateId to spend this study's one reserved confirmation window and obtain a server-written receipt.

Input Schema

TableJSON Schema

Name	Required	Description
`checks`	No
`symbol`	Yes
`endDate`	Yes
`startDate`	Yes
`timeframe`	Yes
`protocolId`	Yes	Experiment protocol id returned by define_experiment_protocol for this exact candidate-evaluation check.
`candidateId`	No
`caseStudyId`	No	Optional: bind this call to one of your case studies. Defaults to the bound run's case study.
`constraints`	No
`confirmation`	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

A3.8/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is already covered. The description adds meaningful behavioral context: it spends a scarce resource ('one reserved confirmation window'), requires confirmation:true, and produces a 'server-written receipt'. This goes beyond the annotations and warns about a side effect despite the readOnly hint. No contradiction.

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?

Two sentences, front-loaded with the core purpose and the key precondition. The second sentence packs the critical action requirements (confirmation:true, persisted candidateId, reserved window, receipt). Slightly dense jargon ('promotion language', 'server-written receipt') but no wasted words.

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

Completeness3/5

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

For a 22-parameter tool with no output schema and only 32% schema coverage, the description is not complete. It explains the core gate and the confirmation mechanism, but an agent would still be uncertain about what the receipt contains, what 'materiality and risk gates' actually do, and how the many optional parameters interact. The annotations cover safety, but the operational semantics are under-specified.

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 only 32%, so the description should compensate for the many undocumented parameters. The description does clarify the critical parameters: protocolId (required), confirmation (must be true), candidateId (persisted), and the receipt outcome. But it doesn't explain the other 18 parameters, many of which have no schema description. Baseline 3 is appropriate because the description adds value for the key parameters but leaves most of the parameter space unexplained.

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 states a specific verb ('Apply materiality and risk gates') and resource ('required experiment protocolId'), and mentions 'before any promotion language', which distinguishes it from promotion-related siblings like claim_promotion_state. However, it doesn't explicitly name a sibling alternative, and the phrase 'promotion language' is somewhat jargon-heavy, so it's clear but not maximally differentiated.

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 implies when to use this tool: before promotion, with a required protocolId, and when spending the study's one reserved confirmation window. It doesn't explicitly state when not to use it or name alternatives like evaluate_candidate or claim_promotion_state, but the context of 'before any promotion language' and 'one reserved confirmation window' gives clear usage context.

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?