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

Verwandeln Sie jede Handelsidee in etwa 3 Minuten in einen statistisch validierten Edge.

pip install varrd

Fragen Sie alles

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?"

Jede Frage erhält echte Daten, ein Diagramm mit markierten Signalen, einen statistischen Test und eine definitive Antwort.

Related MCP server: QuantConnect MCP Server

Was Sie zurückerhalten

Edge gefunden

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

Kein Edge

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

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

Beides sind wertvolle Ergebnisse.

Warum kann ich nicht einfach Claude / ChatGPT bitten, das zu tun?

Weil es wirklich schwer ist, Handelsideen richtig zu testen, und es ein Dutzend Möglichkeiten gibt, versehentlich gefälschte Ergebnisse zu produzieren, die großartig aussehen, aber in der Praxis Geld verlieren.

Ein LLM allein schreibt Ihnen gerne einen Backtest, zeigt Ihnen eine schöne Equity-Kurve und sagt Ihnen, dass es eine Gewinnrate von 70 % hat. Das Problem: Nichts davon ist echt. Das LLM hat keine Marktdaten, keine Testumgebung und keine Leitplanken, die es daran hindern, Overfitting zu betreiben, sich die besten Ergebnisse herauszupicken oder sich einfach Zahlen auszudenken.

Selbst wenn Sie einem LLM echte Daten geben (wie in Claude Code oder Cursor), kann es dies immer noch nicht richtig tun. Hier ist der Grund:

Was beim Testen von Handelsideen schiefgehen kann — und was VARRD handhabt:

Overfitting — Das Optimieren einer Strategie, bis sie auf historischen Daten gut aussieht. VARRD hält ungesehene Daten zurück und testet nur einmal darauf. Sie können es nicht erneut ausführen, nachdem Sie die Ergebnisse gesehen haben.
Cherry-picking von Ergebnissen — Das Testen von 50 Variationen und das Zeigen nur des Gewinners. VARRD verfolgt jeden Test, den Sie durchführen, und erhöht die Signifikanzschwelle automatisch, je mehr Sie testen.
p-hacking — Das Bearbeiten der Zahlen, bis Sie ein "signifikantes" Ergebnis erhalten. VARRD korrigiert für Mehrfachvergleiche, damit ein glückliches Ergebnis nicht als echt durchgeht.
Lookahead-Bias — Das versehentliche Verwenden zukünftiger Daten in Ihrer Formel. VARRD läuft in einem isolierten Kernel, der dies strukturell unmöglich macht.
Falscher Testtyp — Manche Ideen benötigen eine Analyse der Vorwärtsrenditen, andere benötigen vollständige Simulationen mit Stops und Targets. VARRD verfügt über ein Team spezialisierter Agenten, die den richtigen Test für jede Frage bestimmen.
Marktübergreifende Kontamination — Das Testen auf einem Markt, obwohl das Signal eigentlich von einem anderen stammte. VARRD isoliert und gleicht Daten über Märkte und Zeitrahmen hinweg ab.
Erfundene Statistiken — LLMs erfinden Zahlen, um überzeugt zu klingen. In VARRD stammt jede Statistik aus einer deterministischen Berechnung. Die KI interpretiert Ergebnisse, sie generiert sie niemals.
ATR-basierte Positionsgrößenbestimmung — Echte Edges benötigen echtes Risikomanagement. VARRD berechnet Stop-Losses und Take-Profits basierend auf der tatsächlichen Volatilität, nicht auf willkürlichen Prozentsätzen.
Anzeigen, was gerade passiert — Ein validierter Edge ist nutzlos, wenn Sie nicht sehen können, wann er ausgelöst wird. VARRD scannt Live-Daten und sagt Ihnen genau, wann Ihre Signale aktiv sind, mit frischen Einstiegs- und Ausstiegsniveaus.

Ein LLM ist ein Gehirn ohne Labor. Es kann über Handelsideen nachdenken, aber es kann sie nicht in einer kontrollierten Umgebung testen. VARRD ist das Labor — eine zweckgebundene Infrastruktur, in der jeder Test verfolgt, jedes Ergebnis verifiziert und das Dutzend Möglichkeiten, versehentlich zu schummeln, auf Systemebene blockiert wird, nicht auf Prompt-Ebene.

Schnellstart — 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)

Schnellstart — 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"

Verwendung mit KI-Agenten

Claude Desktop / Claude Code / Cursor

Option 1 — Direktes HTTP (Claude Code, Cursor, OpenBB):

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

Option 2 — via mcp-remote (Claude Desktop, jeder stdio-Client):

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

Kein API-Schlüssel erforderlich. Fragen Sie dann einfach: "Gibt es ein Muster, wenn Gold nach einer Zinsentscheidung der Fed ansteigt?"

OpenBB Workspace

VARRD lässt sich direkt als MCP-Server in den OpenBB Workspace integrieren:

Workspace öffnen → auf "+" im MCP-Server-Panel klicken
https://app.varrd.com/mcp eingeben
Die Tools von VARRD erscheinen in Ihrem Copilot — Ideen recherchieren, Signale scannen, Strategien suchen

OpenBB liefert Ihnen die Daten. VARRD sagt Ihnen, ob Ihre Idee einen Edge hat.

Handelsbots (Freqtrade, Jesse, Hummingbot, OctoBot, NautilusTrader)

VARRD validiert, dass Ihre Strategie einen echten Edge hat, bevor Sie sie einsetzen. Funktioniert mit jedem 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	Wie VARRD eingebunden wird
Freqtrade	`varrd.freqtrade` generiert ausführbereite IStrategy-Dateien mit ATR-Stops
Jesse	`varrd.jesse` generiert ausführbereite Strategy-Dateien mit ATR-Stops
Hummingbot	Validierung von Richtungssignalen vor dem Einsatz im Market-Making
OctoBot	Vorab-Validierung jeder Tentacle-Strategie über den MCP-Server von VARRD
NautilusTrader	Statistische Edge-Validierung vor dem Live-Einsatz

Das Muster: Erst validieren, dann einsetzen. Die meisten Strategien überstehen statistische Tests nicht — es ist besser, dies für 0,25 $ herauszufinden als für 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?"}
    ]})

Raw MCP (jeder Client)

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

8 statistische Leitplanken (infrastrukturell erzwungen)

Jeder Test durchläuft diese automatisch. Sie können sie nicht überspringen.

Leitplanke	Was sie verhindert
K-Tracking	Testet 50 Variationen derselben Idee? Die Signifikanzschwelle steigt automatisch.
Bonferroni-Korrektur	Strafe für Mehrfachvergleiche. Kein p-hacking.
OOS-Sperre	Out-of-Sample ist ein einmaliger Schuss. Kann nach dem Sehen der Ergebnisse nicht erneut ausgeführt werden.
Lookahead-Erkennung	Erkennt Formeln, die versehentlich zukünftige Daten verwenden.
Tools berechnen, KI interpretiert	Jede Zahl stammt aus echten Daten. KI erfindet niemals Statistiken.
Diagramm → Genehmigen → Testen	Sie sehen und genehmigen das Muster, bevor Sie statistische Power aufwenden.
Fingerabdruck-Dedup	Kann nicht dieselbe Formel/Markt/Horizont zweimal testen.
Keine Post-OOS-Optimierung	Parameter werden nach der Out-of-Sample-Validierung gesperrt.

Datenabdeckung

Anlageklasse	Märkte	Zeitrahmen
Futures (CME)	ES, NQ, CL, GC, SI, ZW, ZC, ZS, ZB, TY, HG, NG + 20 weitere	1h und höher
Aktien / ETFs	Jede US-Aktie	Täglich
Krypto (Binance)	BTC, ETH, SOL + mehr	10min und höher

Insgesamt über 15.000 Instrumente.

MCP-Tools

Tool	Kosten	Was es tut
`research`	~0,25 $	Quant-Forschung über mehrere Runden. Orchestriert 15 interne Tools.
`autonomous_research`	~0,25 $	KI entdeckt Edges für Sie. Geben Sie ein Thema ein, erhalten Sie validierte Ergebnisse.
`scan`	Kostenlos	Scannt Strategien gegen Live-Daten. Frische Einstiegs-/Stop-/Zielpreise.
`search`	Kostenlos	Findet Strategien nach Stichwort oder natürlicher Sprache.
`get_hypothesis`	Kostenlos	Vollständige Details zu jeder Strategie.
`check_balance`	Kostenlos	Guthaben und verfügbare Pakete anzeigen.
`buy_credits`	Kostenlos	Guthaben mit USDC auf Base oder Stripe kaufen.
`reset_session`	Kostenlos	Beendet eine defekte Sitzung und startet neu.

Preise

2 $ kostenlos bei der Anmeldung — genug für 6–8 Forschungssitzungen
Forschung: ~0,20–0,30 $ pro getesteter Idee
Discovery (autonom): ~0,20–0,30 $
ELROND-Rat (8 Experten-Ermittler): ~0,40–0,60 $
Multi-Markt (3+ Märkte): ~1 $
Scan, Suche, Guthaben: Immer kostenlos
Guthabenpakete: 5 $ / 20 $ / 50 $ via Stripe
Guthaben verfällt nie

Beispiele

Siehe examples/ für ausführbare Skripte:

quick_start.py — 5 Zeilen, um alle Strategien zu scannen
research_idea.py — Vollständiger Forschungs-Workflow über mehrere Runden
multi_idea_loop.py — Viele Ideen in einer Schleife testen
scan_portfolio.py — Portfolio-Scan mit Handelsniveaus
mcp_config.json — MCP-Konfiguration für Claude Desktop / Cursor

Für KI-Agenten-Entwickler

Siehe AGENTS.md für den vollständigen Integrationsleitfaden — Tool-Referenz, Antwortformate, Authentifizierung und Workflow-Muster.

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

Fragen Sie alles

Was Sie zurückerhalten

Edge gefunden

Kein Edge

Warum kann ich nicht einfach Claude / ChatGPT bitten, das zu tun?

Schnellstart — Python

Schnellstart — CLI

Verwendung mit KI-Agenten

Claude Desktop / Claude Code / Cursor

OpenBB Workspace

Handelsbots (Freqtrade, Jesse, Hummingbot, OctoBot, NautilusTrader)

CrewAI

LangChain / LangGraph

Raw MCP (jeder Client)

8 statistische Leitplanken (infrastrukturell erzwungen)

Datenabdeckung

MCP-Tools

Preise

Beispiele

Für KI-Agenten-Entwickler

Links

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