Skip to main content
Glama
deenesjakoruzh
varrdinc

Varrd

by varrdinc
OverviewSchemaRelated ServersScoreDiscussions
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.9/5.0
Behavior5/5

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

The description adds behavioral context beyond annotations: it mentions the tool draws from knowledge graphs, generates novel hypotheses, returns complete results (edge or not, stats, trade setup), and costs ~$0.25 per call. Annotations already indicate non-readOnly and openWorld, and the description aligns with these without contradiction.

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 (about 150 words), well-structured with a clear opening, a 'BEST FOR' highlight, and a direct comparison with the sibling tool. Every sentence adds value; no fluff or repetition.

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, 1 required, 2 enums) and the presence of an output schema, the description is complete. It covers purpose, usage, output, cost, and alternatives. The output schema handles return value details, so the description need not repeat them.

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 baseline is 3. The description adds value by providing concrete examples (e.g., 'momentum on grains') and explaining how parameters like test_type and search_mode affect behavior. This contextualizes the parameters beyond their schema descriptions.

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 specifies the action (exploring), resource (VARRD knowledge graph), and outcome (novel hypotheses). It also distinguishes from the sibling tool 'varrd_ai' by explicitly stating when to use each.

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?

The description provides explicit when-to-use guidance: 'BEST FOR: Exploring a space broadly.' It also tells when not to use it and what alternative to use: 'Use varrd_ai instead when YOU have a specific idea to test and want full control over each step.' This is clear and actionable.

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

A4.9/5.0
Behavior5/5

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

Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds behavioral details: returns Stripe Checkout link for card or deposit address+payment_intent_id for crypto, explains two-step crypto confirmation, and states the call consumes no credits. 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.

Conciseness5/5

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

The description is well-structured: opens with purpose and free note, then bullet points for two payment methods with clear steps. Every sentence adds meaningful information. It is appropriately sized for the complexity and front-loads the key action.

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 complexity (payment flows, multiple methods), the description is complete. It covers both methods end-to-end, including return values, follow-up actions (check_balance, second buy_credits call), and the free nature. No gaps remain for agent understanding.

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?

Input schema has 100% coverage, so baseline is 3. The description adds valuable context beyond schema: explains the workflow for each parameter (e.g., payment_intent_id used to confirm crypto payment), defaults, minimum amount, and the two payment method flows. This extra guidance raises it above baseline.

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, with specific verb 'buy' and resource 'credits'. It distinguishes two payment methods (card and crypto) and mentions the default minimum of $5. This fully defines the tool's purpose and differentiates it from siblings.

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?

The description provides explicit when-to-use guidance by detailing two payment methods with step-by-step instructions. It suggests crypto for autonomous scenarios and card for human-in-loop, and references check_balance as a follow-up. The 'Free — no credits consumed' note further clarifies usage context. This is thorough guidance.

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.5/5.0
Behavior4/5

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

Adds context beyond annotations: free, no credits consumed, auto-detects payments, response includes recovered_cents. 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.

Conciseness5/5

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

Two brief sentences, front-loaded with core purpose, no extraneous words. Highly efficient.

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?

Simple tool with no params and output schema present. Description covers purpose, free nature, and payment confirmation use case. Complete for a read-only check.

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?

No parameters, schema coverage 100%. Baseline 4 applies; description adds no parameter info but none needed.

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?

Clearly states it checks credit balance and available packs, and also auto-detects completed payments. Specific verb 'check' and resource 'balance', distinguishes from sibling 'buy_credits'.

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?

Provides usage guidance: free, no credits consumed, suggest calling after payment to confirm credits. Implies when to use, but lacks explicit when-not or alternatives.

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?

Annotations already declare readOnlyHint=true, idempotentHint=false, and destructiveHint=false. The description adds behavioral details beyond annotations: it profiles strategies, searches today's news, writes a digest with connections to positions and edges, and notes credit costs. No contradiction with annotations; the description enriches the behavioral model.

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: two short paragraphs with the first sentence immediately stating the purpose. Every sentence adds relevant information (profiling, searching, writing, format, requirements, cost). No fluff, well-structured for quick comprehension.

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 no parameters but an output schema (existence noted), the description covers input requirements (5 edges, credits), processing steps, and output format features. It fully prepares the agent to invoke the tool correctly, without needing to see the output schema.

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?

There are zero parameters and 100% schema description coverage. The description adds context about what the briefing includes (e.g., '↳ line tying it to your actual positions and edges'), which goes beyond the empty schema. Since no parameters exist, the baseline is 4, and the description provides additional value.

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: 'Get a personalized market news briefing based on your validated edge library.' It distinguishes from sibling tools like 'search' and 'varrd_ai' by specializing in personalized briefing generation. The verb 'Get' combined with specific resource 'personalized market news briefing' makes the action unambiguous.

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 explicit prerequisites ('Requires at least 5 strong edges in your library') and a cost constraint ('Costs credits'), guiding the agent on when to use this tool. It implies use when the user has sufficient edges and wants a briefing, but does not explicitly state when not to use or list alternatives, though sibling names offer some context.

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.2/5.0
Behavior4/5

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

Annotations already indicate safe, read-only behavior. The description adds value by detailing return content (performance metrics, version history, etc.), providing insight beyond the annotation hints.

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?

Two sentences, front-loaded with purpose, bullet-like list of return fields, and a closing emphasis on utility. Every sentence adds value.

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

Completeness4/5

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

With a single parameter and output schema present, the description adequately covers what the tool does and returns. Missing error handling details, but acceptable for a simple read operation.

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% with a clear description for the only parameter. The tool description adds no further param details, so baseline 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 returns full details for a hypothesis/strategy, listing specific elements (formula, rules, metrics, etc.). It distinguishes from siblings by its specific retrieval function.

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 usage when an agent has a hypothesis_id, and the schema parameter description specifies the ID comes from search or scan results. No explicit exclusions or alternatives, but context is clear.

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.3/5.0
Behavior4/5

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

Annotations already provide destructiveHint=true and idempotentHint=true, but the description adds useful behavioral context: 'Free — no credits consumed' and the post-reset step. There is 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.

Conciseness5/5

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

The description is concise with three sentences, front-loaded with the primary action, and each sentence adds value without 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, good schema coverage, output schema exists, and annotations provide behavioral hints), the description covers when to use, what it does, and follow-up actions, making it complete for an agent.

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

Parameters3/5

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

The only parameter, session_id, is fully covered by the schema description ('The session_id to reset'). The description does not add additional meaning beyond what the schema already provides.

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 a specific verb 'Kill' and resource 'broken research session', clearly distinguishing it from sibling tools like 'search' and 'varrd_ai' which have different purposes.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool ('when a session gets stuck, produces errors, or enters a bad state') and provides post-action guidance ('call research without a session_id to start a new clean session'). It does not mention when not to use it, but the context is clear.

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

A5/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), session creation, terminal states (edge verdicts, context.has_edge), and the requirement to follow context.next_actions. 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.

Conciseness5/5

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

The description is well-structured with clear sections (MULTI-TURN, HYPOTHESIS INTEGRITY, KEY CAPABILITIES, etc.), front-loads the core purpose, and every sentence adds necessary detail without 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 complexity (multi-turn, stateful, cost, hypothesis testing), the description covers all essential aspects: how to start/continue, rules, edge verdicts, terminal states, and key capabilities. It is fully self-contained for an agent to use correctly.

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?

Schema coverage is 100%, and the description adds significant value: examples for 'message' (e.g., 'test it', 'show trade setup') and explicit instructions for 'session_id' ('Omit to start a new research session'). It also explains how to use parameters within the multi-turn workflow.

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: 'Talk to VARRD AI...Describe any trading idea...handles everything'. It distinguishes from siblings like 'autonomous_varrd_ai' by emphasizing multi-turn user interaction and specific workflow steps.

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?

The description provides explicit when-to-use and when-not-to-use guidance, including multi-turn session management, hypothesis integrity rules ('Never combine multiple setups'), and allowed/not-allowed actions like testing same setup across markets but not different formulas simultaneously.

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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: autonomous_varrd_ai explores broadly, varrd_ai tests specific ideas, varrd_edges provides live edges, search finds saved hypotheses, get_hypothesis gives details, get_briefed creates news briefs, buy_credits/check_balance handle credits, and reset_session manages sessions. No ambiguity.

Naming Consistency3/5

Most tools follow verb_noun snake_case (get_briefed, buy_credits, check_balance, reset_session, search), but some are noun phrases (varrd_edges, varrd_ai) or longer (autonomous_varrd_ai). The pattern is not fully consistent, though still readable.

Tool Count5/5

9 tools is well-scoped for a trading research server. Each tool serves a specific function without redundancy, covering exploration, testing, live data, search, credit management, and session control. No bloat or missing essentials.

Completeness4/5

The tool surface covers exploration, hypothesis testing, live edges, search, details, briefing, session management, and payments. Minor gaps: no explicit tool to manually create or delete saved hypotheses, but the AI-driven flow handles creation. Core workflows are supported.

Maintenance

ActivityMaintained
ResponsivenessSlow

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/varrdinc/varrd'

If you have feedback or need assistance with the MCP directory API, please join our Discord server