Skip to main content
Glama
deenesjakoruzh
varrdinc

Varrd

by varrdinc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

VARRD

Two ways to use VARRD

1. Tell your AI. Add the MCP config below, then ask: "What VARRD edges are firing right now?" or "What happens to gold when silver ETFs are making 100-day new lows?" Your AI browses the edge library, shows you what's actionable, and can test any idea you throw at it.

2. Use the web app. Go to app.varrd.com, sign up, and do the same thing — browse the edge library, ask questions like "Is there a seasonal pattern in wheat before harvest?", and watch the full research pipeline run visually.

{
  "mcpServers": {
    "varrd": { "url": "https://app.varrd.com/mcp" }
  }
}

Works with Claude Desktop, Cursor, OpenBB, or any MCP client. No API key needed.

Related MCP server: QuantConnect MCP Server

What VARRD does

VARRD turns trading ideas into quantitative formulas using a domain-specific language we built from the ground up — purpose-built to express market behaviors in a way that's both machine-testable and human-readable. Those formulas are then tested with the right guardrails so the results actually mean something.

The AI generates hypotheses. A purpose-built backtesting engine does the math. The AI never calculates statistics, never fabricates results, and never touches the numbers. Every stat comes from a deterministic computation running in a sandboxed kernel. This matters because most people's first question is: "How do I know the AI isn't just making this up?" It can't. The engine is separate from the model.

VARRD also maintains a growing library of validated edges — patterns that survived the full testing gauntlet — running 24/7 against live market data across futures, equities, and crypto. When an edge fires, you get exact entry, stop, target, hold period, and the complete audit trail of how it was discovered, tested, and validated.

Full transparency

Every edge in the library shows you everything. Not summaries — the actual work.

How it was found: The discovery story — what pattern was hypothesized, why it might work, what market structure theory it's based on. You can read the exact thinking that led to the formula.

The formula itself: Written in our domain-specific language built to quantify market behaviors and make them replicable. You can read every condition, understand the logic, and verify there's no data leak or circular reasoning. The setup code and the boolean formula are both visible.

How it was tested: Per-horizon results showing win rate, expected value, p-value, and signal count at every hold period tested. K-tracking shows how many tests were run on this hypothesis — and every test is fingerprinted so you can't re-run the same thing hoping for a better number. Vectorized embeddings with cosine similarity detect when a new hypothesis overlaps with one already tested — if you're just tweaking the same idea, the system catches it and penalizes accordingly. Lookahead verification confirms signals reproduce on truncated data.

How it's performing now: Post-discovery performance tracked separately from in-sample. Edge decay by quarter. Rolling stability. Regime analysis (how it performs in low vol, high vol, uptrends, downtrends). Monte Carlo simulation. Drawdown analysis. The full picture — not just a win rate.

The interactive view: Every edge has a browser link that shows the chart with every signal marked, the equity curve, the full performance dashboard, and the discovery story. Share it with anyone — no account needed.

If an edge is decaying, you see it. If the post-discovery performance doesn't match in-sample, you see it. If it only works in bull markets, you see it. Nothing is hidden.

What the guardrails prevent

Problem

How it happens

VARRD's guard

Overfitting

Tweak until it looks good on history

OOS is sacred — one shot, permanently locked

Cherry-picking

Test 50 variants, show the winner

K-tracking counts every test, adjusts significance

p-hacking

Massage until "significant"

Bonferroni correction, fingerprinted tests

Duplicate testing

Reword the same idea to dodge K

Cosine similarity on vectorized embeddings detects overlapping hypotheses

Lookahead bias

Future data leaks into formula

Sandbox kernel + automated truncated-data verification

OOS contamination

Peek at holdout, then "validate"

Once used, permanently locked. No re-runs.

Fabricated stats

AI invents numbers

Engine computes, AI interprets. Separate systems.

Slippage ignored

Backtest assumes perfect fills

ATR-normalized returns account for volatility regime

Commission ignored

Gross returns look great, net don't

Explicit in backtest engine, factored into P&L

What you get at each tier

Free — which markets have edges firing

See which markets have validated edges that are firing right now, pending bar close, or in active trades. Markets and status only — no direction, no stats, no trade levels.

VARRD Edge Library — 3 firing, 12 pending bar close, 35 in active trades

FIRING (actionable now):
  AAPL daily — 798c0e5f-4c71-453c-a168-fc3b0771e506
  Crude Oil daily — 9d713707-4548-462e-a787-676e56ec3a0b
  Gold daily — 081ab7f2-edfb-4f74-add8-6fc90aca3561

$0.50: unlock direction, win rate, EV, stop/target, entry date for ALL edges (depth=1)
$1/edge or $5/all: full formula, methodology, performance analytics (depth=2)

$0.50 — 15-minute snapshot of all active edges

Unlocks direction, win rate, EV, stops, entry date, and hold period for every firing, pending, and active edge. This is a 15-minute window — a snapshot of what's live right now.

  NQ daily LONG | FIRING — enter 2026-05-04 OPEN
    64% win | 0.51 EV | 1419 signals | stop $27,200 target $29,785 | hold 10
    "NQ 13-day ROC positive 5 days then declining, weekly RSI > 55"

$1/edge — full audit trail

The complete methodology for one edge. TRADE details, PERFORMANCE with post-discovery tracking, INTEGRITY (K-tracking, lookahead verification, beats-market), DISCOVERY story, FORMULA in our domain-specific language, and drill-down sections:

  • horizons — Win rate, EV, p-value, signal count at every hold period

  • analytics — SQN, profit factor, Kelly %, Monte Carlo, drawdown, regime analysis, edge decay

  • occurrences — Every historical signal with date and ATR return

  • setup_code — Full source code in our DSL (auditable)

  • view — Interactive chart + discovery story link for your user

EDGE QUALITY
  SQN: 6.46 (Excellent)
  Profit Factor: 1.66
  Kelly %: 25.4%
  Best Streak: 25W · Worst Streak: 16L

MONTE CARLO
  500 simulations · 98% profitable
  Median: +44.49 ATR · Worst 5%: +8.56 ATR

REGIME ANALYSIS
  Low Vol (VIX < 15)    59% WR · +0.38 ATR
  Normal (VIX 15-25)    66% WR · +0.54 ATR
  High Vol (VIX > 25)   75% WR · +1.07 ATR

$5 — everything on every edge

Full audit trail on every active edge in the library. Same depth as the $1 tier, but for all of them.

Python SDK

pip install varrd
from varrd import VARRD

v = VARRD()

# Browse the edge library
edges = v.edges()                              # free — which markets are firing
edges = v.edges(depth=1)                       # $0.50 — snapshot with stats + levels
edges = v.edges(depth=1, direction="SHORT")    # filter by direction
edges = v.edges(depth=1, asset_class="futures") # filter by asset class
edges = v.edges(depth=2, edge_id="abc123")     # $1 — full audit trail

# Research your own ideas
r = v.research("When RSI drops below 25 on ES, is there a bounce?")
r = v.research("test it", session_id=r.session_id)
print(r.context.edge_verdict)  # "STRONG EDGE" / "NO EDGE"

# Autonomous discovery
result = v.discover("mean reversion on futures")

# Morning briefing
b = v.briefing()
print(b.news)

CLI

varrd edges                                    # free — which markets are firing
varrd edges --depth 1                          # $0.50 — snapshot with stats + levels
varrd edges --depth 2 --edge-id abc123         # $1 — full audit trail
varrd research "Does buying SPY after 3 down days work?"
varrd discover "momentum on grains"
varrd briefing

Questions VARRD can answer

These are real things you can ask. VARRD loads the data, builds the formula, tests it statistically, and tells you if there's an edge.

"Is there an edge to going long Starbucks on their Red Cup Day?"

"What happens to gold futures when yen and 10-year bonds make 20-day new highs on the same day?"

"Take a look at crude oil on a 240-minute timeframe right now — diagnose how it's acting and let's find every time it's happened in the past and if there's an edge."

"Does it test out to short fast food companies during Lent?"

"What happens to Bitcoin after a halving event?"

"When corn and soybeans diverge by more than 2 standard deviations, is there a mean reversion trade?"

Every question becomes a hypothesis, gets charted with real data, statistically tested with proper guardrails (Bonferroni correction, K-tracking, lookahead verification), and produces a clear verdict: edge or no edge. Both answers are valuable.

Data coverage

Asset Class

Markets

Timeframes

Futures (CME)

35 markets (ES, NQ, CL, GC, SI, ZC, ZW, NG, ...)

1h through weekly, back to 1985

Equities

Any US stock or ETF (12,600+ tickers)

1h through weekly

Crypto

BTC, ETH, SOL and more

1h through weekly

MCP tools

Tool

What it does

varrd_edges

Browse the validated edge library with filters

varrd_ai

Multi-turn research — test any trading idea

autonomous_varrd_ai

Autonomous discovery — VARRD finds edges for you

search

Search your saved strategies

get_hypothesis

Full detail on your own strategy

check_balance

Credit balance + auto-detects completed payments

buy_credits

Card (Stripe Checkout) or USDC on Base (autonomous)

get_briefed

Personalized market news tied to your edge library

reset_session

Kill a stuck research session

Pricing

What

Cost

Duration

See which markets have edges firing

Free

—

Snapshot: stats + trade levels on all active edges

$0.50

15 minutes

Full audit trail on one edge

$1

Permanent

Full audit trail on every edge

$5

15 minutes

Research your own ideas

~$0.25

Per query

Autonomous discovery

~$1

Per idea

Sign up at app.varrd.com for $2 in free credits.

Why this exists

Finding edges is not hard. Finding non-data-mined edges with proper precautions at every step is much harder.

An LLM by itself will happily write you a backtest, show you a beautiful equity curve, and tell you it has a 70% win rate. The problem: none of it is real. The LLM doesn't have market data, doesn't have a testing environment, and has no guardrails preventing it from overfitting, cherry-picking, or fabricating numbers.

An LLM is a brain without a lab. It can reason about trading ideas, but it can't test them in a controlled environment. VARRD is the lab — purpose-built infrastructure where every test is tracked, every result is verified, and the dozen ways to accidentally cheat are blocked at the system level, not the prompt level.

And if you still aren't convinced — we show you everything. The formula, the code, the test results at every horizon, the post-discovery performance, the regime sensitivity, the Monte Carlo simulation, and every single historical occurrence. Full transparency. Audit it yourself.

Available Tools

9 tools
autonomous_varrd_aiAInspect

Point VARRD's autonomous AI in a direction and let it discover edges for you. Give it a topic and it draws from one of the most comprehensive market structure knowledge graphs ever built — containing ideologies and theories, not statistics — so it generates genuinely novel hypotheses rather than overfitting to what already worked.

BEST FOR: Exploring a space broadly. Give it 'momentum on grains' and it might test wheat seasonal patterns, corn spread reversals, or soybean crush ratio momentum. It propagates from your seed idea into related concepts you might not think of.

Returns a complete result — edge or no edge, stats, trade setup. Each call tests ONE hypothesis through the full pipeline (~$0.25/idea). Call again for another idea.

Use 'varrd_ai' instead when YOU have a specific idea to test and want full control over each step.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicYesResearch topic or trading idea (e.g. 'BTC 240min short setups', 'momentum on grains', 'mean reversion after VIX spikes').
contextNoPrior conversation context — recent user queries to use as research inspiration. Optional.
marketsNoFocus on specific markets (e.g. ['ES', 'NQ']). Omit for VARRD to choose.
test_typeNoType of statistical test. Default: event_study.event_study
search_modeNofocused = stay close to topic. explore = creative freedom. Default: focused.focused
asset_classesNoLimit to specific asset classes. Default: all.

Output Schema

ParametersJSON Schema
NameRequiredDescription
textNoFull research result with edge verdict
contextNohas_edge, edge_verdict, workflow_state
widgetsNoChart, test results, trade setup
session_idNo

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), the description adds crucial behavioral details: each call tests exactly ONE hypothesis, costs ~$0.25/idea, and propagates from the seed idea into related concepts. It also explains the output: 'edge or no edge, stats, trade setup.' These are not present in the schema, providing genuine transparency.

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 well-structured with clear sections ('BEST FOR', 'Returns', alternative tool). It is slightly verbose with marketing phrases like 'comprehensive market structure knowledge graphs ever built', but every sentence carries information. Front-loaded with the core purpose, and examples aid comprehension. A minor trim could improve conciseness, but it is not wasteful.

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

Completeness5/5

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

Given the tool's complexity (6 parameters, output schema exists, annotations present), the description provides sufficient context for an AI agent to decide when to invoke it. It covers what the tool does, example usage, cost, output summary, and the distinction from a sibling tool. The output schema handles return values, so no further elaboration is needed. This is a complete description.

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 coverage is 100%, so the baseline is 3. The description adds illustrative meaning to the 'topic' parameter via the 'momentum on grains' example, but does not enhance understanding of other parameters like 'context', 'markets', 'test_type', or 'search_mode'. It does not contradict or significantly add beyond the schema descriptions, so a 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 clearly states the tool's purpose: 'Point VARRD's autonomous AI in a direction and let it discover edges for you.' It explains that it generates and tests hypotheses, and explicitly distinguishes this from the sibling tool 'varrd_ai' for controlled testing. The verb 'discover' and resource 'edges' make the primary function unambiguous.

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

Usage Guidelines5/5

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

It explicitly says 'BEST FOR: Exploring a space broadly' and provides concrete examples of when to use it. It also gives a clear exclusion criterion: 'Use 'varrd_ai' instead when YOU have a specific idea to test and want full control over each step.' This is textbook usage guidance.

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

buy_creditsAInspect

Buy credits for the edge library and AI research. Default $5 minimum. Free — no credits consumed to call this.

TWO PAYMENT METHODS: card (default): Returns a Stripe Checkout link for your user to click and pay. After payment, call check_balance to confirm credits were added. crypto: USDC on Base. Fully autonomous — no human needed. Three steps: 1. buy_credits(payment_method='crypto') → returns deposit address + payment_intent_id 2. Send USDC to the deposit address (use your wallet tool) 3. buy_credits(payment_intent_id='pi_...') → confirms payment, credits added instantly If you have wallet access, this is the fastest path — fully machine-to-machine.

ParametersJSON Schema
NameRequiredDescriptionDefault
amount_centsNoAmount in cents (default 500 = $5.00). Minimum $5.
payment_methodNoPayment method: 'card' (default, Stripe Checkout) or 'crypto' (USDC on Base).card
payment_intent_idNoFor crypto: Stripe PaymentIntent ID from a previous buy_credits call. Pass after sending USDC to confirm.

Output Schema

ParametersJSON Schema
NameRequiredDescription
depositNoUSDC deposit address for crypto payment
checkout_urlNoStripe Checkout link for card payment
current_balance_centsNo

TDQS

A5/5.0
Behavior5/5

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

Discloses that the tool is free (no credits consumed), returns a Stripe Checkout link for card, and provides a deposit address and payment_intent_id for crypto. It also explains the two-step confirmation behavior, offering context beyond the annotations.

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 well-organized with clear headings and numbered steps, making it scannable. Every sentence provides actionable information without waste.

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

Completeness5/5

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

Covers the full payment lifecycle, including fallback to check_balance, exact call sequence for crypto, and the condition of instant credit addition after confirmation. Given the complexity of a payment tool, this is complete.

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

Parameters5/5

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

The schema already describes all three parameters, but the description adds operational meaning by explaining the two-phase crypto flow (first with payment_method='crypto', then with payment_intent_id to confirm) and the default amount_cents. This makes the parameters' roles clear in context.

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 clearly states the tool 'Buys credits for the edge library and AI research' and details the two payment methods. It also distinguishes itself from the sibling check_balance by referencing it for post-payment confirmation.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance: card for user-mediated Stripe payment, crypto for autonomous machine-to-machine flow when wallet access is available. It also instructs the agent to call check_balance after card payment, naming a sibling alternative.

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

check_balanceA
Read-onlyIdempotent
Inspect

Check your credit balance and see available credit packs. Free — no credits consumed. Also auto-detects completed payments — call this after your user pays via a checkout link to confirm credits were added. If payment went through, the response includes recovered_cents.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
credit_packsNoAvailable credit packs for purchase
balance_centsNoCurrent credit balance in cents
recovered_centsNoCredits recovered from completed payments (if any)

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable context: 'Free — no credits consumed' and the auto-detection behavior with 'recovered_cents' in the response. This enriches the agent's understanding of side effects and return values.

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?

Three focused sentences, each earning its place: first states the core purpose, second addresses cost, third provides a critical usage scenario and expected response. No redundancy or filler.

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

Completeness5/5

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

The description fully covers the tool's purpose, usage context, and important behavioral nuances. With output schema available and annotations present, no additional explanation is needed for a zero-parameter tool.

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

Parameters4/5

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's nothing to explain. Baseline for 0 params is 4, and the description appropriately mentions the response field 'recovered_cents' which aligns with the output schema.

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 uses specific verbs ('Check', 'see', 'auto-detects') and clearly identifies the resource ('credit balance', 'credit packs', 'completed payments'). It distinguishes from siblings like buy_credits by focusing on checking and payment confirmation, not purchasing.

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

Usage Guidelines5/5

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

Explicitly states the tool is free and safe to use, and gives a concrete scenario ('call this after your user pays via a checkout link to confirm credits were added'). This provides clear when-to-use guidance and implies alternatives like buy_credits for purchasing.

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

get_briefedA
Read-only
Inspect

Get a personalized market news briefing based on your validated edge library. Profiles your strategies, searches today's news for the instruments and setups you actually trade, and writes a concise digest connecting each headline to your specific book.

Each news item includes a ↳ line tying it to your actual positions and edges (e.g. 'your ES momentum setups', 'your GC mean-reversion edge').

Requires at least 5 strong edges in your library. Costs credits.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
newsNoPersonalized market news digest
profileNoTrader profile based on edge library
strong_countNoNumber of strong edges in library

TDQS

A4.7/5.0
Behavior5/5

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

The description goes beyond the annotations by disclosing important behavioral traits: it 'Costs credits', requires a specific prerequisite ('at least 5 strong edges'), and explains the process ('Profiles your strategies, searches today's news...'). It also describes the output format with '↳ lines'. These details are not present in the annotations and add significant transparency.

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 concise and well-structured: the first sentence gives the main purpose, the second explains the output detail, and the third states prerequisites and cost. Every sentence adds value, and there is no wasted text.

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

Completeness5/5

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

Given that the tool has no parameters and an output schema exists, the description is complete. It covers the core behavior, prerequisites, cost, and what the user can expect in the output. No gaps are apparent.

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

Parameters4/5

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

The tool has zero parameters, so the baseline for parameter semantics is 4. The description adds no param-specific information because there are no params, which is acceptable; schema coverage is 100% by default.

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 clearly states the tool's function: 'Get a personalized market news briefing based on your validated edge library.' The verb 'get' plus the resource 'briefing' is specific and distinguishes it from sibling tools like general 'search' or 'varrd_ai'. It also explains the unique value proposition of tying headlines to the user's positions and edges.

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 provides clear context for when to use the tool: it requires 'at least 5 strong edges in your library' and is intended for a personalized briefing. However, it does not explicitly mention alternatives or when not to use it, so it falls just short of the 'explicit when/when-not' benchmark.

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

get_hypothesisA
Read-onlyIdempotent
Inspect

Get full detail for a specific hypothesis/strategy. Returns formula, entry/exit rules, direction, performance metrics (win rate, Sharpe, profit factor, max drawdown), version history, and trade levels. Everything an agent needs to understand and act on a strategy.

ParametersJSON Schema
NameRequiredDescriptionDefault
hypothesis_idYesThe hypothesis ID (from search or scan results).

Output Schema

ParametersJSON Schema
NameRequiredDescription
nameNo
formulaNo
win_rateNo
directionNo
hypothesis_idNo
horizon_resultsNo

TDQS

A4.6/5.0
Behavior5/5

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

The description aligns with annotations (readOnlyHint, idempotentHint) and adds behavioral detail about returned data (performance metrics, version history, trade levels), fully disclosing what the tool does beyond safety properties.

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 two sentences with clear front-loading. The second sentence is somewhat general ('Everything an agent needs...') but not overly verbose. Minor improvement possible.

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

Completeness5/5

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

Given the low parameter count, full schema coverage, presence of output schema, and comprehensive annotations, the description fully covers what the agent needs to know about this simple retrieval tool.

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

Parameters4/5

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

Schema coverage is 100%, and the description adds the context that hypothesis_id comes from 'search or scan results,' which is helpful for correct invocation. However, no additional parameter-specific details are given.

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 explicitly states 'Get full detail for a specific hypothesis/strategy' and enumerates specific content (formula, entry/exit rules, performance metrics, etc.), making the purpose very clear and distinguishing it from siblings like 'search'.

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 the tool is used after discovery via search/scan ('from search or scan results'), providing clear usage context. However, it does not explicitly state when not to use it or mention alternatives beyond the sibling list.

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

reset_sessionA
DestructiveIdempotent
Inspect

Kill a broken research session and start fresh. Use this when a session gets stuck, produces errors, or enters a bad state. Free — no credits consumed. After resetting, call research without a session_id to start a new clean session.

ParametersJSON Schema
NameRequiredDescriptionDefault
session_idYesThe session_id to reset.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resetNo
messageNo

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the tool as destructive and idempotent. The description adds valuable behavioral context beyond these hints: it notes the operation is free ('Free — no credits consumed') and that the old session is effectively discarded, letting the agent plan accordingly.

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 three sentences long, front-loaded with the purpose, and each sentence earns its place: what it does, when to use it, cost, and next step. No filler or redundancy.

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

Completeness5/5

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

Given the tool's simplicity (one required parameter), existing annotations, and an output schema, the description is complete. It covers when to use, cost implications, and the aftermath, leaving no critical gaps.

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

Parameters4/5

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

Schema coverage is 100%, so the parameter description already explains session_id. The description adds context by specifying this is a 'research session' and explains that the next call should omit session_id, giving the parameter semantic meaning beyond the schema's generic wording.

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 opens with 'Kill a broken research session and start fresh' — a specific verb and resource that clearly states what the tool does. It distinguishes reset_session from sibling tools like search or buy_credits by focusing on session lifecycle management.

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

Usage Guidelines5/5

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

It explicitly states when to use the tool ('when a session gets stuck, produces errors, or enters a bad state') and provides a clear next step ('call research without a session_id'). The guidance is practical and unambiguous, covering the primary use case and follow-up action.

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

varrd_aiAInspect

Talk to VARRD AI (~$0.25/turn). Describe any trading idea in plain language and the system handles everything — loading decades of market data, charting your pattern, running statistical tests, backtesting with stops, and generating exact trade setups.

MULTI-TURN: First call creates a session. Keep calling with the same session_id, following context.next_actions each time.

  1. Your idea -> VARRD charts pattern

  2. 'test it' -> statistical test (event study or backtest)

  3. 'show me the trade setup' -> exact entry/stop/target prices

HYPOTHESIS INTEGRITY (critical): VARRD tests ONE hypothesis at a time — one formula, one setup. Never combine multiple setups into one formula or ask to 'test all' — each idea must be tested as a separate hypothesis for the statistics to be valid. Say 'start a new hypothesis' between ideas to reset cleanly.

  • ALLOWED: Test the SAME setup across multiple markets ('test this on ES, NQ, and CL') — same formula, different data.

  • NOT ALLOWED: Test multiple DIFFERENT formulas/setups at once — each is a separate hypothesis requiring its own chart-test-result cycle. If ELROND council returns 4 setups, test each one separately: chart setup 1 -> test -> results -> 'start new hypothesis' -> chart setup 2 -> etc.

KEY CAPABILITIES you can ask for:

  • 'Use the ELROND council on [market]' -> 8 expert investigators

  • 'Optimize the stop loss and take profit' -> SL/TP grid search

  • 'Test this on ES, NQ, and CL' -> multi-market testing

  • 'Simulate trading this with 1.5 ATR stop' -> backtest with stops

EDGE VERDICTS in context.edge_verdict after testing:

  • STRONG EDGE: Significant vs zero AND vs market baseline

  • MARGINAL: Significant vs zero only (beats nothing, but real signal)

  • PINNED: Significant vs market only (flat returns but different from market)

  • NO EDGE: Neither significant test passed

TERMINAL STATES: Stop when context.has_edge is true (edge found) or false (no edge — valid result). Always read context.next_actions.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesYour trading idea, research question, or instruction (e.g. 'test it', 'show trade setup').
session_idNoSession ID from a previous call. Omit to start a new research session.

Output Schema

ParametersJSON Schema
NameRequiredDescription
textNoAI response text
contextNoWorkflow state, edge verdict, next actions
widgetsNoChart, event study, backtest, or trade setup widgets
session_idNoSession ID for multi-turn conversation

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses cost (~$0.25/turn), the multi-turn session state, the 'ONE hypothesis at a time' constraint, edge verdict categories, and terminal states. This is rich behavioral context not captured in structured fields.

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?

Though lengthy, the description is sectioned logically (MULTI-TURN, HYPOTHESIS INTEGRITY, KEY CAPABILITIES, EDGE VERDICTS, TERMINAL STATES) and every sentence carries functional guidance for a complex tool. It is front-loaded with the core purpose and then details the workflow without fluff.

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

Completeness5/5

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

For a complex multi-turn tool, the description covers the full lifecycle: session creation, hypothesis testing, allowed/not-allowed patterns, verdict interpretation, and stopping criteria. It references context fields (has_edge, next_actions, edge_verdict) and assumes an output schema, so the agent is fully equipped to use the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, but the description adds value by giving concrete message examples ('test it', 'show me the trade setup') and clarifying session_id behavior (omit to start new). This supports the schema without redundancy, though it doesn't define parameter constraints beyond what's already present.

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 opens with a clear statement: "Talk to VARRD AI... Describe any trading idea in plain language and the system handles everything..." It enumerates specific capabilities (charting, statistical tests, backtesting, trade setups) and distinguishes from siblings by emphasizing interactive multi-turn research rather than autonomous execution.

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 provides an explicit multi-turn protocol, including 'First call creates a session. Keep calling with the same session_id, following context.next_actions each time.' It also gives allowed/not-allowed examples for hypothesis testing, but doesn't explicitly reference sibling tools as alternatives, so it lacks explicit when-not/alternatives.

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

varrd_edgesA
Read-onlyIdempotent
Inspect

THE PRIMARY TOOL — start here. FREE at depth=0, always safe to call.

Live feed of THIS USER'S OWN statistically validated trading edges — the ones on their account — running 24/7 against real market data. See which of YOUR edges are firing right now, get trade levels, or audit the full methodology. Scoped to the connected account: if the user has no edges yet, this returns none (it is NOT a general/shared library).

THREE TIERS: depth=0 (FREE — call this first): See which of YOUR edges are firing right now, pending bar close, or actively in trades. Markets and status only — no direction, no stats. Get a sense of what's live. depth=1 ($0.50): Unlock direction, occurrence count, EV/trade, stop-loss, take-profit, hold horizon, and current entry prices for ALL active edges in one request. depth=2 ($1 per edge, $5 for all): Full methodology — the actual formula, setup code, how the edge was discovered, edge decay analysis, complete performance analytics (Sharpe, drawdown, equity curve, profit factor). Machine-readable so any AI can audit the statistical rigor. Includes drill-down sections (free after purchase): setup_code, horizons, analytics, occurrences, and view (interactive chart link for your user, 15 min).

Every edge in this library is Bonferroni-corrected, tested against both zero returns and market baseline, with K-tracking to prevent p-hacking. Out-of-sample validated. Full transparency.

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNo0=free (markets + status), 1=$0.50 (direction, stats, trade levels for ALL active edges), 2=$1/edge or $5/all (full methodology + performance). Cheaper than a coffee.
marketNoFilter by market symbol (e.g. 'ES', 'GC'). Omit to see all.
statusNoFilter by status: 'firing', 'pending', 'active', or omit for all.
edge_idNoSpecific edge ID for depth 1 or 2 detail. Omit to see all edges.
sectionNoDrill into a specific section of a depth=2 edge (free after purchase). Options: setup_code, horizons, analytics, occurrences, view. Omit to get the overview directory.
directionNoFilter by direction: 'LONG' or 'SHORT'.
timeframeNoFilter by timeframe: '60min', '120min', '240min', '480min', 'daily', 'weekly'.
asset_classNoFilter by asset class: 'futures', 'equities', 'crypto'.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark readOnlyHint, idempotentHint, and destructiveHint, and the description agrees fully. It adds substantial behavioral context: free at depth 0, always safe to call, pricing tiers, account scoping, validation methodology, and drill-down behavior after purchase. No contradiction 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.

Conciseness4/5

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

The description is front-loaded with the most important instruction ('start here') and organized clearly into tiers and validation notes. It is longer than minimal, with some redundant marketing phrases like 'Full transparency' and repeated validation claims, but the structure makes the content scannable and decision-relevant.

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

Completeness5/5

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

For a tool with 8 optional parameters, no output schema, and multi-tier pricing, the description is remarkably complete: it covers scoping, pricing, return contents per depth, filter semantics, no-edge behavior, and output sections. An agent has enough context to call the tool correctly and set user expectations.

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

Parameters4/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 adds real value by explaining the business semantics of depth tiers, what each tier unlocks, and the drill-down sections, which helps an agent choose parameters. It does not deeply elaborate on market, status, or timeframe syntax, but the schema already covers those.

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?

Description opens with a specific verb+resource: it is a live feed of the user's own statistically validated trading edges, scoped to the connected account. It clearly distinguishes itself from a general/shared library and tells the agent this is the primary starting point.

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?

Strong when-to-use guidance is present: 'THE PRIMARY TOOL — start here' and 'call this first', plus a clear exclusion that if the user has no edges it returns none and is not a general library. However, it does not explicitly name sibling tools as alternatives or explain when to prefer varrd_ai, search, or get_hypothesis.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.4.3
    • Changedvarrd_edges1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "properties": {
-    "text": {
-      "description": "Formatted edge data (depth 0/1) or directory overview (depth 2)",
-      "type": "string"
-    }
-  },
-  "type": "object"
-}New value: +null
  2. 9 tool updatesv0.4.2
    • Changedautonomous_varrd_ai1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "context": {
+      "description": "has_edge, edge_verdict, workflow_state",
+      "type": "object"
+    },
+    "session_id": {
+      "type": "string"
+    },
+    "text": {
+      "description": "Full research result with edge verdict",
+      "type": "string"
+    },
+    "widgets": {
+      "description": "Chart, test results, trade setup",
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
    • Changedbuy_credits1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "checkout_url": {
+      "description": "Stripe Checkout link for card payment",
+      "type": "string"
+    },
+    "current_balance_cents": {
+      "type": "integer"
+    },
+    "deposit": {
+      "description": "USDC deposit address for crypto payment",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
    • Changedcheck_balance1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "balance_cents": {
+      "description": "Current credit balance in cents",
+      "type": "integer"
+    },
+    "credit_packs": {
+      "description": "Available credit packs for purchase",
+      "type": "array"
+    },
+    "recovered_cents": {
+      "description": "Credits recovered from completed payments (if any)",
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}
    • Changedget_briefed1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "news": {
+      "description": "Personalized market news digest",
+      "type": "string"
+    },
+    "profile": {
+      "description": "Trader profile based on edge library",
+      "type": "string"
+    },
+    "strong_count": {
+      "description": "Number of strong edges in library",
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}
    • Changedget_hypothesis1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "direction": {
+      "type": "string"
+    },
+    "formula": {
+      "type": "string"
+    },
+    "horizon_results": {
+      "type": "array"
+    },
+    "hypothesis_id": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "win_rate": {
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
    • Changedreset_session1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "reset": {
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}
    • Changedsearch1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "method": {
+      "description": "Search method: embedding or keyword",
+      "type": "string"
+    },
+    "query": {
+      "type": "string"
+    },
+    "results": {
+      "description": "Matching strategies with win rate, Sharpe, similarity",
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
    • Changedvarrd_ai1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "context": {
+      "description": "Workflow state, edge verdict, next actions",
+      "type": "object"
+    },
+    "session_id": {
+      "description": "Session ID for multi-turn conversation",
+      "type": "string"
+    },
+    "text": {
+      "description": "AI response text",
+      "type": "string"
+    },
+    "widgets": {
+      "description": "Chart, event study, backtest, or trade setup widgets",
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
    • Changedvarrd_edges1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "text": {
+      "description": "Formatted edge data (depth 0/1) or directory overview (depth 2)",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  3. 7 tool updatesv0.3.4
    • Removedautonomous_research
    • Addedautonomous_varrd_ai
    • Changedbuy_credits2 fields changed
      • changedInput schema / properties / payment_intent_id / description
        Previous value: -"Stripe PaymentIntent ID from a previous buy_credits call. Pass this after sending USDC to confirm payment and receive credits."New value: +"For crypto: Stripe PaymentIntent ID from a previous buy_credits call. Pass after sending USDC to confirm."
      • addedInput schema / properties / payment_method
        Added value: +{
+  "default": "card",
+  "description": "Payment method: 'card' (default, Stripe Checkout) or 'crypto' (USDC on Base).",
+  "type": "string"
+}
    • Removedresearch
    • Removedscan
    • Addedvarrd_ai
    • Addedvarrd_edges
  4. 9 tool updatesv1.0.0
    • First observedautonomous_research
    • First observedbuy_credits
    • First observedcheck_balance
    • First observedget_briefed
    • First observedget_hypothesis
    • First observedresearch
    • First observedreset_session
    • First observedscan
    • First observedsearch
Deploy Server
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

TDQS

A4.3/5.0

Scored across 9 tools

Disambiguation4/5

Most tools have clearly distinct purposes: varrd_edges for live edges, varrd_ai for interactive research, autonomous_varrd_ai for one-shot discovery, search/get_hypothesis for retrieving saved strategies, check_balance/buy_credits for payments, reset_session for session control, get_briefed for news. The only mild overlap is between varrd_ai and autonomous_varrd_ai, but descriptions clarify the difference well.

Naming Consistency2/5

Naming is inconsistent. Some tools follow verb_noun (get_hypothesis, check_balance, buy_credits, reset_session, get_briefed), some are prefixed with 'varrd_' (varrd_edges, varrd_ai), and 'search' is a bare noun. The mixed prefixes and verb styles create no clear pattern.

Tool Count5/5

Nine tools is well-scoped for a trading research platform covering edge monitoring, AI research, autonomous discovery, strategy retrieval, payments, session management, and news briefing. Each tool has a clear role and the count is within the ideal 3-15 range.

Completeness4/5

The surface covers the core workflows: discovering edges, researching ideas, retrieving saved strategies, managing credits, and getting news. Minor gaps exist, such as no explicit tool to delete or edit hypotheses, but agents can work around these via the search and get_hypothesis tools.

Maintenance

ActivityMaintained
ResponsivenessSlow

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches