de en es ja ko ru zh

Varrd

Name: Varrd
Author: varrdinc

by varrdinc

Overview Schema Related Servers Score Discussions

Python

Remote

VARRD

PyPI MCP Transport License MCP Badge

Convierte cualquier idea de trading en una ventaja estadísticamente validada en unos 3 minutos.

pip install varrd

Pregúntale cualquier cosa

varrd research "Does buying SPY after a 3-day losing streak actually work?"

varrd research "When VIX spikes above 30, is there a bounce in ES?"

varrd research "Is there a seasonal pattern in wheat before harvest?"

varrd research "What happens to gold when the dollar drops 3 days straight?"

varrd research "Does Bitcoin rally after the halving?"

varrd research "When crude oil drops 5% in a week, what happens next?"

Cada pregunta obtiene datos reales, un gráfico con señales marcadas, una prueba estadística y una respuesta definitiva.

Related MCP server: QuantConnect MCP Server

Qué obtienes a cambio

Ventaja encontrada

STRONG EDGE — Statistically significant vs both zero and market baseline.

  Direction:    LONG
  Win Rate:     62%
  Sharpe:       1.45
  Signals:      247

  Trade Setup:
    Entry:       $5,150.25
    Stop Loss:   $5,122.00
    Take Profit: $5,192.50
    Risk/Reward: 1:1.5

Sin ventaja

NO EDGE — Neither test passed. No tradeable signal found.

You found out for 25 cents instead of $25,000 in live losses.

Ambos son resultados valiosos.

¿Por qué no puedo simplemente pedirle a Claude / ChatGPT que haga esto?

Porque probar ideas de trading correctamente es realmente difícil de hacer bien, y hay una docena de formas de producir accidentalmente resultados falsos que parecen excelentes pero que pierden dinero en producción.

Un LLM por sí solo escribirá felizmente un backtest para ti, te mostrará una hermosa curva de capital y te dirá que tiene una tasa de aciertos del 70%. El problema: nada de eso es real. El LLM no tiene datos de mercado, no tiene un entorno de pruebas y no tiene barreras de seguridad que le impidan sobreajustar, seleccionar datos a conveniencia o simplemente inventar números.

Incluso si le das datos reales a un LLM (como en Claude Code o Cursor), todavía no puede hacer esto correctamente. He aquí por qué:

Qué puede salir mal al probar ideas de trading — y qué maneja VARRD:

Sobreajuste (Overfitting) — Ajustar una estrategia hasta que se vea bien con datos pasados. VARRD reserva datos no vistos y los prueba una vez. No puedes volver a ejecutarlo después de ver los resultados.
Selección de resultados (Cherry-picking) — Probar 50 variaciones y mostrar solo la ganadora. VARRD rastrea cada prueba que ejecutas y aumenta automáticamente el nivel de significancia cuanto más pruebas.
p-hacking — Manipular los números hasta obtener un resultado "significativo". VARRD corrige las comparaciones múltiples para que un resultado afortunado no pase como real.
Sesgo de anticipación (Lookahead bias) — Usar accidentalmente datos futuros en tu fórmula. VARRD se ejecuta en un kernel aislado (sandboxed) que hace que esto sea estructuralmente imposible.
Tipo de prueba incorrecto — Algunas ideas necesitan análisis de retorno a futuro, otras necesitan simulaciones completas con stops y objetivos. VARRD cuenta con un equipo de agentes especializados que determinan la prueba correcta para cada pregunta.
Contaminación entre mercados — Probar en un mercado cuando la señal en realidad provino de otro. VARRD aísla y alinea los datos entre mercados y marcos temporales.
Estadísticas fabricadas — Los LLM inventarán números para sonar convincentes. En VARRD, cada estadística proviene de un cálculo determinista. La IA interpreta los resultados, nunca los genera.
Dimensionamiento de posición basado en ATR — Las ventajas reales necesitan una gestión de riesgos real. VARRD calcula los stop loss y take profits basados en la volatilidad real, no en porcentajes arbitrarios.
Mostrar lo que está sucediendo ahora mismo — Una ventaja validada es inútil si no puedes ver cuándo se está activando. VARRD escanea datos en vivo y te dice exactamente cuándo tus señales están activas, con niveles frescos de entrada y salida.

Un LLM es un cerebro sin laboratorio. Puede razonar sobre ideas de trading, pero no puede probarlas en un entorno controlado. VARRD es el laboratorio: una infraestructura diseñada específicamente donde cada prueba se rastrea, cada resultado se verifica y la docena de formas de hacer trampa accidentalmente se bloquean a nivel de sistema, no a nivel de prompt.

Inicio rápido — Python

from varrd import VARRD

v = VARRD()  # auto-creates free account, $2 in credits

# Research a trading idea
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"

# Get exact trade levels
r = v.research("show me the trade setup", session_id=r.session_id)

# What's firing right now across all your strategies?
signals = v.scan(only_firing=True)
for s in signals.results:
    print(f"{s.name}: {s.direction} {s.market} @ ${s.entry_price}")

# Morning briefing — today's news connected to your specific edges
b = v.briefing()
print(b.news)
# "**ES selling accelerates into the open** Three consecutive lower highs..."
# "↳ Your ES mean-reversion setups are live territory here..."

# Let VARRD discover edges autonomously
result = v.discover("mean reversion on futures")
print(result.edge_verdict, result.market, result.win_rate)

Inicio rápido — CLI

# Full research workflow (auto-follows chart → test → trade setup)
varrd research "When wheat drops 3 days in a row, is there a snap-back?"

# What's firing right now?
varrd scan --only-firing

# Personalized market briefing — news filtered to your edge library
varrd briefing

# Search saved strategies
varrd search "momentum on grains"

# Let VARRD discover edges on its own
varrd discover "mean reversion on futures"

Uso con agentes de IA

Claude Desktop / Claude Code / Cursor

Opción 1 — HTTP directo (Claude Code, Cursor, OpenBB):

{
  "mcpServers": {
    "varrd": {
      "transport": {
        "type": "streamable-http",
        "url": "https://app.varrd.com/mcp"
      }
    }
  }
}

Opción 2 — vía mcp-remote (Claude Desktop, cualquier cliente stdio):

{
  "mcpServers": {
    "varrd": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://app.varrd.com/mcp"]
    }
  }
}

No se necesita clave API. Luego solo pregunta: "¿Existe un patrón cuando el oro sube después de una decisión de tipos de la Fed?"

OpenBB Workspace

VARRD se conecta directamente a OpenBB Workspace como un servidor MCP:

Abre Workspace → haz clic en "+" en el panel del servidor MCP
Ingresa https://app.varrd.com/mcp
Las herramientas de VARRD aparecen en tu Copilot: investiga ideas, escanea señales, busca estrategias

OpenBB te da los datos. VARRD te dice si tu idea tiene una ventaja.

Bots de trading (Freqtrade, Jesse, Hummingbot, OctoBot, NautilusTrader)

VARRD valida que tu estrategia tenga una ventaja real antes de desplegarla. Funciona con cualquier bot:

from varrd import VARRD
from varrd.freqtrade import generate_strategy

v = VARRD()
result = v.discover("RSI oversold reversal on BTC")

if result.has_edge:
    hyp = v.get_hypothesis(result.hypothesis_id)
    strategy_code, config = generate_strategy(hyp)
    # Drop into your bot's strategies/ folder and run it

Bot	Cómo se conecta VARRD
Freqtrade	`varrd.freqtrade` genera archivos IStrategy listos para ejecutar con stops ATR
Jesse	`varrd.jesse` genera archivos de estrategia listos para ejecutar con stops ATR
Hummingbot	Valida señales direccionales antes de desplegar en market-making
OctoBot	Pre-valida cualquier estrategia tentacle a través del servidor MCP de VARRD
NautilusTrader	Validación de ventaja estadística antes del despliegue en vivo

El patrón: valida primero, despliega después. La mayoría de las estrategias no sobreviven a las pruebas estadísticas; es mejor descubrirlo por $0.25 que por $25,000.

CrewAI

from crewai import Agent, Task, Crew

researcher = Agent(
    role="Trading Researcher",
    goal="Find statistically validated trading edges",
    backstory="You are a quantitative researcher who tests trading ideas rigorously.",
    mcps=[{"type": "streamable-http", "url": "https://app.varrd.com/mcp"}]
)

task = Task(
    description="Research whether RSI oversold conditions on ES lead to a bounce within 5 days.",
    agent=researcher,
    expected_output="Edge verdict with trade setup if edge is found."
)

crew = Crew(agents=[researcher], tasks=[task])
result = crew.kickoff()

LangChain / LangGraph

from langchain_mcp_adapters.client import MultiServerMCPClient
from langgraph.prebuilt import create_react_agent
from langchain_anthropic import ChatAnthropic

model = ChatAnthropic(model="claude-sonnet-4-20250514")

async with MultiServerMCPClient({
    "varrd": {"url": "https://app.varrd.com/mcp", "transport": "streamable_http"}
}) as client:
    agent = create_react_agent(model, client.get_tools())
    result = await agent.ainvoke({"messages": [
        {"role": "user", "content": "Does gold rally when the dollar drops 3 days in a row?"}
    ]})

MCP sin procesar (cualquier cliente)

# Any MCP-compatible client can connect to:
https://app.varrd.com/mcp
# Transport: Streamable HTTP | No auth required | $2 free credits

8 barreras de seguridad estadísticas (impuestas por la infraestructura)

Cada prueba se ejecuta a través de estas automáticamente. No puedes saltártelas.

Barrera de seguridad	Qué evita
K-Tracking	¿Pruebas 50 variaciones de la misma idea? La barra de significancia sube automáticamente.
Corrección de Bonferroni	Penalización por comparaciones múltiples. Sin p-hacking.
Bloqueo OOS	Fuera de muestra (Out-of-sample) es un solo intento. No se puede volver a ejecutar después de ver los resultados.
Detección de anticipación	Detecta fórmulas que usan accidentalmente datos futuros.
Las herramientas calculan, la IA interpreta	Cada número proviene de datos reales. La IA nunca fabrica estadísticas.
Gráfico → Aprobar → Probar	Ves y apruebas el patrón antes de gastar poder estadístico.
Deduplicación de huella digital	No se puede volver a probar la misma fórmula/mercado/horizonte dos veces.
Sin optimización post-OOS	Los parámetros se bloquean después de que se valida el fuera de muestra.

Cobertura de datos

Clase de activo	Mercados	Marcos temporales
Futuros (CME)	ES, NQ, CL, GC, SI, ZW, ZC, ZS, ZB, TY, HG, NG + 20 más	1h y superior
Acciones / ETFs	Cualquier acción de EE. UU.	Diario
Cripto (Binance)	BTC, ETH, SOL + más	10min y superior

15,000+ instrumentos en total.

Herramientas MCP

Herramienta	Costo	Qué hace
`research`	~$0.25	Investigación cuantitativa de múltiples turnos. Orquesta 15 herramientas internas.
`autonomous_research`	~$0.25	La IA descubre ventajas para ti. Dale un tema, obtén resultados validados.
`scan`	Gratis	Escanea estrategias contra datos en vivo. Precios frescos de entrada/stop/objetivo.
`search`	Gratis	Encuentra estrategias por palabra clave o lenguaje natural.
`get_hypothesis`	Gratis	Detalles completos sobre cualquier estrategia.
`check_balance`	Gratis	Ver créditos y paquetes disponibles.
`buy_credits`	Gratis	Compra créditos con USDC en Base o Stripe.
`reset_session`	Gratis	Elimina una sesión rota y comienza de nuevo.

Precios

$2 gratis al registrarte: suficiente para 6–8 sesiones de investigación
Investigación: ~$0.20–0.30 por idea probada
Descubrimiento (autónomo): ~$0.20–0.30
Consejo ELROND (8 investigadores expertos): ~$0.40–0.60
Multi-mercado (3+ mercados): ~$1
Escanear, buscar, saldo: Siempre gratis
Paquetes de crédito: $5 / $20 / $50 vía Stripe
Los créditos nunca caducan

Ejemplos

Consulta examples/ para ver scripts ejecutables:

quick_start.py — 5 líneas para escanear todas las estrategias
research_idea.py — Flujo de trabajo completo de investigación de múltiples turnos
multi_idea_loop.py — Prueba muchas ideas en un bucle
scan_portfolio.py — Escaneo de cartera con niveles de trading
mcp_config.json — Configuración MCP para Claude Desktop / Cursor

Para desarrolladores de agentes de IA

Consulta AGENTS.md para obtener la guía de integración completa: referencia de herramientas, formatos de respuesta, autenticación y patrones de flujo de trabajo.

Enlaces

Aplicación web: app.varrd.com
Sitio web: varrd.com
Endpoint MCP: https://app.varrd.com/mcp
PyPI: pypi.org/project/varrd

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

Name	Required	Description	Default
`topic`	Yes	Research topic or trading idea (e.g. 'BTC 240min short setups', 'momentum on grains', 'mean reversion after VIX spikes').
`context`	No	Prior conversation context — recent user queries to use as research inspiration. Optional.
`markets`	No	Focus on specific markets (e.g. ['ES', 'NQ']). Omit for VARRD to choose.
`test_type`	No	Type of statistical test. Default: event_study.	event_study
`search_mode`	No	focused = stay close to topic. explore = creative freedom. Default: focused.	focused
`asset_classes`	No	Limit to specific asset classes. Default: all.

Output Schema

ParametersJSON Schema

Name	Required	Description
`text`	No	Full research result with edge verdict
`context`	No	has_edge, edge_verdict, workflow_state
`widgets`	No	Chart, test results, trade setup
`session_id`	No

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

Name	Required	Description	Default
`amount_cents`	No	Amount in cents (default 500 = $5.00). Minimum $5.
`payment_method`	No	Payment method: 'card' (default, Stripe Checkout) or 'crypto' (USDC on Base).	card
`payment_intent_id`	No	For crypto: Stripe PaymentIntent ID from a previous buy_credits call. Pass after sending USDC to confirm.

Output Schema

ParametersJSON Schema

Name	Required	Description
`deposit`	No	USDC deposit address for crypto payment
`checkout_url`	No	Stripe Checkout link for card payment
`current_balance_cents`	No

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

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`credit_packs`	No	Available credit packs for purchase
`balance_cents`	No	Current credit balance in cents
`recovered_cents`	No	Credits 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

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`news`	No	Personalized market news digest
`profile`	No	Trader profile based on edge library
`strong_count`	No	Number 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

Name	Required	Description	Default
`hypothesis_id`	Yes	The hypothesis ID (from search or scan results).

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	No
`formula`	No
`win_rate`	No
`direction`	No
`hypothesis_id`	No
`horizon_results`	No

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

Name	Required	Description	Default
`session_id`	Yes	The session_id to reset.

Output Schema

ParametersJSON Schema

Name	Required	Description
`reset`	No
`message`	No

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.

searchA

Read-onlyIdempotent

Inspect

Search your saved hypotheses by keyword or natural language query. Returns matching strategies ranked by relevance, with key stats (win rate, Sharpe, edge status). Use this to find strategies you've already validated.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results to return.
`query`	Yes	Search query — keywords or natural language (e.g. 'momentum strategies', 'RSI oversold').
`market`	No	Optional market filter.

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	No
`method`	No	Search method: embedding or keyword
`results`	No	Matching strategies with win rate, Sharpe, similarity

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds value by stating that results are ranked and include key stats, which are helpful behavioral details 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 two sentences, front-loading the action and output, then providing usage guidance. Every sentence earns its place with zero fluff.

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?

Given the tool's simplicity, annotations, and output schema existence, the description covers purpose, usage, and key behavioral aspects. It does not explain ranking details or stats precisely, but these may be unnecessary for a search tool.

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 schema already documents all three parameters. The description provides an example for the 'query' parameter and mentions the 'market' filter is optional, adding marginal value but not significantly beyond the 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 clearly states the verb 'search', the resource 'saved hypotheses', and the output 'matching strategies ranked by relevance with key stats'. It distinguishes from siblings like 'get_hypothesis' which likely returns a single hypothesis.

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 says 'Use this to find strategies you've already validated', providing clear context for when to use it. It does not mention when not to use or provide alternatives, but the context signals with sibling tool names imply differentiation.

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.

Your idea -> VARRD charts pattern
'test it' -> statistical test (event study or backtest)
'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

Name	Required	Description	Default
`message`	Yes	Your trading idea, research question, or instruction (e.g. 'test it', 'show trade setup').
`session_id`	No	Session ID from a previous call. Omit to start a new research session.

Output Schema

ParametersJSON Schema

Name	Required	Description
`text`	No	AI response text
`context`	No	Workflow state, edge verdict, next actions
`widgets`	No	Chart, event study, backtest, or trade setup widgets
`session_id`	No	Session 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

Name	Required	Description
`depth`	No	0=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.
`market`	No	Filter by market symbol (e.g. 'ES', 'GC'). Omit to see all.
`status`	No	Filter by status: 'firing', 'pending', 'active', or omit for all.
`edge_id`	No	Specific edge ID for depth 1 or 2 detail. Omit to see all edges.
`section`	No	Drill 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.
`direction`	No	Filter by direction: 'LONG' or 'SHORT'.
`timeframe`	No	Filter by timeframe: '60min', '120min', '240min', '480min', 'daily', 'weekly'.
`asset_class`	No	Filter 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

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

CPZAI
com.cpz-lab.mcp
Build, backtest, and deploy quantitative trading strategies from your AI agent.
Finance Research & Data
11
Ice Juice Trading
com.icejuicetrading
Automate trading on your own Alpaca account - build, backtest and run strategies via your AI.
Finance Autonomous Agents
1
TextToQuant Backtesting and Quant Research
com.texttoquant
Backtest trading strategies written in plain English, on real market data, with graded results.
Finance
1
Valuein — SEC EDGAR Fundamentals & Smart-Money Data A
io.github.valuein
Point-in-time, survivorship-free SEC EDGAR fundamentals + smart-money signals for AI agents.
Finance Government Data Open Data
1182

Related MCP Servers

Polygon-io MCP Serverofficial
Finance Search Data Platforms
massive-com
A
license
C
quality
C
maintenance
An MCP server for Massive.com Financial Market Data
Updated 3 months ago (2026-06-11 16:25 UTC)
20
53
387
MIT
QuantConnect MCP Server
Agent Orchestration Code Execution Finance
taylorwilsdon
A
license
B
quality
D
maintenance
LLM Driven Trading Platform Orchestration - Strategy Design, Research & Implementation
Updated a year ago (2025-08-24 17:16 UTC)
50
119
Python
MIT
QuantConnectofficial
Cloud Platforms Finance Developer Tools
QuantConnect
A
license
B
quality
F
maintenance
Official QuantConnect API Server MCP
Updated 4 months ago (2026-05-07 16:17 UTC)
64
77
Apache 2.0
Quant Companion MCP
Finance Search
Ademscodeisnotsobad
F
license
Not graded
quality
D
maintenance
Provides real-time options analytics, pricing with Greeks, Monte Carlo simulations, volatility analysis, strategy backtesting, and risk metrics using actual market data from Yahoo Finance and Polygon.io.
Updated 8 months ago (2025-12-23 01:20 UTC)
1

Appeared in Searches

A quantitative trading system

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

VARRD

Pregúntale cualquier cosa

Qué obtienes a cambio

Ventaja encontrada

Sin ventaja

¿Por qué no puedo simplemente pedirle a Claude / ChatGPT que haga esto?

Inicio rápido — Python

Inicio rápido — CLI

Uso con agentes de IA

Claude Desktop / Claude Code / Cursor

OpenBB Workspace

Bots de trading (Freqtrade, Jesse, Hummingbot, OctoBot, NautilusTrader)

CrewAI

LangChain / LangGraph

MCP sin procesar (cualquier cliente)

8 barreras de seguridad estadísticas (impuestas por la infraestructura)

Cobertura de datos

Herramientas MCP

Precios

Ejemplos

Para desarrolladores de agentes de IA

Enlaces

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Polygon-io MCP Serverofficial

QuantConnectofficial

Appeared in Searches

Latest Blog Posts

MCP directory API