What can you do with this server?

The server provides AI agents with market data context and trade analysis tools, operating locally with your Databento key and optionally using a hosted API for chart rendering and advanced metrics. Free (local, no API key needed beyond Databento) * Resolve symbols: Convert informal names like "MNQ" or "micro nasdaq" into exact Databento contract notation, including point value, tick size, and front-month. * Fetch price context: Get OHLCV candlestick data and trade markers (entries, exits, stops) as JSON around your fills, with auto-sizing, optional reference levels (PDH, PDL, VWAP, etc.), and technical indicators (EMA, SMA, ATR). Paid (free tier available, no credit card) * Render annotated charts: Generate candlestick chart images (PNG/SVG) with entries, exits, stop/target zones, and reference levels annotated; images are saved locally for journaling. * Analyze trade performance: Compute per-trade metrics (MAE, MFE, R-multiple, went-green-first, capture efficiency) plus USD P&L, time-in-trade, win rate, and session-level roll-ups, helping AI distinguish bad luck from bad location. Privacy-centric: Market data sourced from your Databento key stays on your machine; only the minimal numeric candle data slice is sent to the API for rendering/analysis, and the API is stateless and retains nothing.

How do I use trade-analytics-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@trade-analytics-mcp Analyze my ES trades from yesterday." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

trade-analytics-mcp

by oliverwehn

Overview Schema Related Servers Score Discussions

TypeScript

Remote

trade-analytics-mcp

Give your AI eyes and a ruler for your trades. An open-source MCP server that lets your LLM/agent pull the real price action around every fill in an order-history export, see each trade on a candlestick chart, and measure it — heat taken, R-multiple, whether it went green before red, how much of the move it captured — so it can tell you whether a loss was bad luck or bad location.

You bring your own market-data key; the data stays on your machine.

Why — what it actually lets your AI do

An order-history export (Tradovate, your broker's CSV, …) is just timestamps, prices, sizes, sides. From that alone an AI can spot behaviour — overtrading, revenge entries, size creep, bad time-of-day — but it is blind to trade-location quality: was the entry into structure or a chase? how much adverse excursion did you sit through? did you cut a winner early? was the stop sane for the volatility?

This MCP closes that gap — in two tiers.

🆓 Free, on your machine

resolve_symbol + get_price_context run 100% locally under your own Databento key — no account, no fee, no data leaving the machine. Your agent can:

turn "MNQ" / "micro nasdaq" into the exact contract, point value, and front-month; and
pull the real OHLCV around each fill (auto-windowed) with your entries/exits/stops as JSON,

so it reasons over the actual price path — where the entry sat, the shape of the move, proximity to the day's high/low — instead of guessing. That alone turns "I think I chased" into a grounded read.

💳 With a trade-analytics API key (free tier — no card)

render and analyze send only the numeric slice of that same local data to the hosted API and add the two things that are tedious or impossible to do well from raw JSON. The API has a free tier (no credit card), so you can try the full experience at no cost — paid tiers only raise the monthly quota:

render — an annotated candlestick chart image (entries ▲ / exits ▼, SL/TP zones, reference levels), returned and saved to a file so your AI can drop it into a journal.
analyze — the precise per-trade metrics that separate good-trade-bad-outcome from bad-location: MAE / MFE (heat vs best excursion), R-multiple, went-green-first, capture efficiency, plus USD P&L, time-in-trade, win rate, and session roll-ups.

So — with the paid tools — instead of "you lost on trade #3," your AI can say:

"Trade #3 (short at 20,110) went +0.8R in your favour within three minutes, then reversed through your entry to −18 pts before you exited at −15 — MFE 12, MAE 18, capture −1.2. Location was fine (into the prior-day high); management wasn't," — and hand you the annotated chart.

A typical review

"Review my MNQ trades from last week." → your agent reconstructs the round-trips, calls resolve_symbol (MNQ → the right contract), analyze (per-trade MAE/MFE/R/capture + a session summary), and render on the notable trades (charts saved to your vault), then writes the review with the numbers and the pictures.

Related MCP server: Dragonglass TradingView MCP

Tools

Tool	What it does	Cost
`resolve_symbol`	"MNQ" / "micro nasdaq" → precise contract, point value, front-month	Free, local
`get_price_context`	OHLCV + your entries/exits/SL as JSON for a window auto-sized around the trade	Free, local
`render`	An annotated candlestick chart image, returned and saved to a file (PNG or SVG)	Paid
`analyze`	Per-trade MAE/MFE, R-multiple, went-green-first, capture efficiency + summary	Paid

resolve_symbol and get_price_context run 100% on your machine under your own data key — no account, no fee. render and analyze forward only the numeric slice of your own data to the hosted trade-analytics API and return the result; nothing is retained.

Setup

1. Get a Databento key (your market data)

Databento is a modern market-data provider — institutional-grade historical and live data through a simple API. This example MCP implementation uses it to fetch the candles around your trades, under your own key, locally.

No subscription. It's pay-as-you-go, and new accounts get a free usage credit that comfortably covers normal trade review — historical 1-minute OHLCV is cheap and is often effectively free within that credit.
Sign up at databento.com → open the portal → create an API key → that's your DATABENTO_API_KEY.

Your key and your data stay on your machine; only the numeric slices you render/analyze leave it.

2. Get a trade-analytics API key — free to start

render and analyze call the hosted API, which has a free tier (no credit card) — so you can use the full experience right away; paid tiers only raise the monthly quota.

Open the dashboard and sign up (free).
Click Create key and copy it — it's shown once (looks like tc_live_…).
Add it to your MCP config as TRADE_ANALYTICS_API_KEY (step 3 below).

You don't need this to get started. The MCP connects and the free local tools work with just your Databento key — the API key only unlocks render + analyze, so add it whenever you want charts or analysis. Call those without a key and you'll get a friendly "grab a key" message, not a crash.

3. Add the MCP to your client

Claude Code (or any terminal harness):

claude mcp add trade-analytics \
  -e DATABENTO_API_KEY=db-your-key \
  -e TRADE_ANALYTICS_API_KEY=tc_live_your-key \
  -- npx -y trade-analytics-mcp

Drop the TRADE_ANALYTICS_API_KEY line to run just the free local tools.

Claude Desktop / other MCP clients — add to the config:

{
  "mcpServers": {
    "trade-analytics": {
      "command": "npx",
      "args": ["-y", "trade-analytics-mcp"],
      "env": {
        "DATABENTO_API_KEY": "db-your-key",
        "TRADE_ANALYTICS_API_KEY": "tc_live_your-key"
      }
    }
  }
}

Configuration

Resolved with precedence CLI flags > env > defaults:

Setting	Env	Flag	Notes
Databento key	`DATABENTO_API_KEY`	`--databento-key`	Required. Your own; data stays local.
API key	`TRADE_ANALYTICS_API_KEY`	`--api-key`	Only for `render` / `analyze`.
API URL	`TRADE_ANALYTICS_API_URL`	`--api-url`	Defaults to the hosted API.
Output dir	`TRADE_ANALYTICS_OUTPUT_DIR`	`--output-dir`	Where `render` saves images.

Built on the trade-analytics API

This whole server is a thin client — it fetches data locally and calls the trade-analytics API for the rendering and analysis. That API is a general, data-agnostic service for turning OHLC data into chart images and trade metrics: send it candles (from any source), get back a chart or a trade analysis. This MCP is just one example of what you can build on it — a dashboard, a trading bot, a Discord/Slack integration, a backtest reporter, or your own journaling tool would all sit on the same endpoints.

Privacy

Your Databento key and your market data live on your machine.
The free tools make no network calls to us at all.
render / analyze send only the numeric candle slice needed for that one call; the API is stateless and retains nothing.

Develop

npm install
npm run typecheck && npm test && npm run build
npm run dev   # run the stdio server locally

MIT licensed. Issues and PRs welcome.

Available Tools

4 tools

analyzeA

Analyze trades (PAID — needs TRADE_ANALYTICS_API_KEY): per-trade MAE/MFE, R-multiple, went-green-first, capture efficiency, USD P&L (with point_value), plus an aggregate summary. Fetches the candles spanning your trades locally, sends only the numeric slice to the API. Pass trades as entry/exit fills with a side; add stop for R-multiples.

ParametersJSON Schema

Name	Required	Default
`symbol`	Yes
`trades`	Yes
`session`	No	eth
`timezone`	No	UTC
`timeframe`	No
`max_candles`	No
`point_value`	No

TDQS

A3.9/5.0

Behavior4/5

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

No annotations exist, so the description carries full burden. It discloses that it fetches candles locally and sends only numeric data to the API, and that it requires a TRADE_ANALYTICS_API_KEY. This provides good transparency, though error cases or side effects are not mentioned.

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 with no redundant information. It front-loads the purpose and mentions key outputs and prerequisites concisely.

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

Completeness3/5

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

Given the lack of annotations and output schema, the description covers the core purpose and some parameter hints but fails to explain several parameters (session, timezone, timeframe, max_candles) clearly. Overall adequate but with gaps.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It explains the trades array structure and the stop parameter for R-multiples, and mentions point_value for P&L. However, other parameters like session, timezone, timeframe, and max_candles are not explained.

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 analyzes trades and lists specific metrics (MAE/MFE, R-multiple, etc.), distinguishing it from sibling tools like resolve_symbol or render.

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

Usage Guidelines3/5

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

The description mentions it is PAID and needs an API key, and gives hints on input structure (add stop for R-multiples). However, it lacks explicit guidance on when to use this tool versus alternatives.

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

get_price_contextA

Return OHLCV candles + trade markers as JSON for a symbol/window, fetched locally under your Databento key. Free. Pass fills via markers and the initial stop/target via risk; omit timeframe/start/end to derive the window from the markers (span padded, ~60 candles). For a chart image or trade analysis, use the render / analyze tools.

ParametersJSON Schema

Name	Required	Default
`end`	No
`risk`	No
`start`	No
`levels`	No
`render`	No
`symbol`	Yes
`markers`	No
`session`	No	eth
`timezone`	No	UTC
`timeframe`	No
`indicators`	No
`max_candles`	No
`point_value`	No
`render_options`	No

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses free, local fetch, and JSON return. It mentions auto-derivation of window from markers with span padded (~60 candles). Could mention rate limits or error handling, but overall sufficient for a read-like operation.

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 concise sentences: first states core function, second provides usage guidance and sibling differentiation. No wasted words, front-loaded with key information.

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

Completeness3/5

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

The tool has 14 parameters, nested objects, and no output schema. The description provides some context (auto-derivation, sibling links) but omits details for many parameters and does not describe the return structure beyond 'JSON'.

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 0% and there are 14 parameters. The description adds meaning for markers, risk, timeframe, start, end, and link to render/analyze tools. However, many other parameters (levels, session, timezone, indicators, max_candles, etc.) are left unexplained, requiring the agent to infer from 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 tool returns OHLCV candles and trade markers as JSON for a symbol/window, using a local Databento key. It distinguishes from siblings by directing to render/analyze tools for chart images or trade analysis.

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

Usage Guidelines5/5

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

Explicitly tells when to use this tool vs alternatives: 'For a chart image or trade analysis, use the render / analyze tools.' Also provides guidance on how to omit timeframe/start/end to auto-derive the window from markers, and how to pass fills and risk.

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

renderA

Render a candlestick chart image of a trade (PAID — needs TRADE_ANALYTICS_API_KEY). Fetches your data locally under your Databento key, sends only the numeric slice to the API, and returns the PNG (viewable) AND saves it to a file so you can add it to a journal — the saved path is in the text result. Use save_path to choose the location, format:'svg' for vector, or include_base64:true for inline bytes.

ParametersJSON Schema

Name	Required	Default
`end`	No
`risk`	No
`start`	No
`style`	No
`width`	No
`format`	No	png
`height`	No
`symbol`	Yes
`markers`	No
`session`	No	eth
`timezone`	No	UTC
`save_path`	No
`timeframe`	No
`max_candles`	No
`include_base64`	No

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: it is a paid feature, fetches data locally but sends a numeric slice to the API, returns a PNG and saves it to a file, and mentions the saved path in the text result. This goes beyond what the structured fields offer and provides transparency about side effects and authentication.

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 a single, focused paragraph of four sentences. Each sentence adds value: purpose, cost/auth, data handling, output, and usage tips. It is front-loaded with the main action and avoids redundancy. Every sentence earns its place.

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

Completeness3/5

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

Given the complexity (15 parameters, nested objects, no output schema), the description provides a high-level overview but misses details. It explains the main output and file-saving but does not cover `risk`, `markers`, `style`, `session`, `timezone`, or other schema properties. The return format is partially described, but the 'text result' for the path is vague. Additional details would be needed for full completeness.

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

Parameters2/5

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

Schema description coverage is 0% and the description only mentions three parameters (`save_path`, `format`, `include_base64`) in passing. The other 12 parameters (e.g., `symbol`, `start`, `timeframe`, `style`) are not explained. The description does not compensate for the lack of schema documentation, leaving agents with incomplete guidance for parameter usage.

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 'Render a candlestick chart image of a trade' with a specific verb and resource. It distinguishes itself from sibling tools (resolve_symbol, get_price_context, analyze) by focusing on chart rendering. Additional details about output format and saving file reinforce the purpose.

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 mentions a prerequisite ('needs TRADE_ANALYTICS_API_KEY') and gives usage tips like using `save_path`, `format:'svg'`, and `include_base64:true`. It implicitly suggests when to use (for charting) but does not explicitly state when not to use or compare to siblings. The context is clear but exclusions are absent.

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

resolve_symbolA

Resolve a symbol the user mentioned (e.g. 'MNQ', 'micro nasdaq', 'MNQU6') to its precise Databento notation + trading metadata: root, continuous symbol, dataset, point value, tick size, and best-effort front-month. Runs locally under your Databento key. Free.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No
`query`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It states the tool runs locally, is free, and requires a Databento key, which provides essential behavioral context. It does not mention side effects (likely none), rate limits, or caching, but the disclosure is adequate for a read-only resolution tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is three sentences, front-loading the core purpose with examples in the first sentence. The subsequent two short sentences add behavioral context without waste. Very efficient and easy to parse.

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 (2 params, no output schema), the description covers inputs implicitly, outputs (lists fields), and behavioral context (local, free, key). A minor gap is the lack of explicit date parameter documentation, but overall it is reasonably complete.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must explain both parameters. It clearly explains 'query' with examples ('MNQ', 'micro nasdaq'), but the 'date' parameter is only indirectly referenced via 'front-month' and lacks explicit explanation of its purpose or format. This leaves a gap.

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 the specific verb 'Resolve' and resource 'symbol', providing concrete examples ('MNQ', 'micro nasdaq') and listing the output fields (root, continuous symbol, etc.). It clearly differentiates from sibling tools like get_price_context, render, and analyze, 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 Guidelines3/5

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

The description implies usage when a user mentions a symbol needing resolution, but it does not explicitly state when not to use the tool or how it compares to alternatives like get_price_context. Sibling tools are not addressed, leaving room for ambiguity.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jul 28, 2026
- First observedanalyze
- First observedget_price_context
- First observedrender
- First observedresolve_symbol

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: symbol resolution, data fetching, chart rendering, and trade analysis. No overlap or ambiguity.

Naming Consistency3/5

Two tools use verb_noun pattern (resolve_symbol, get_price_context), while two are single verbs (render, analyze). Inconsistent naming convention, though each name is descriptive enough.

Tool Count4/5

4 tools is slightly below average but appropriate for a focused trade analytics server. Each tool covers a core function without being too thin.

Completeness4/5

Covers the main workflow: symbol resolution, data retrieval, visualization, and analysis. Minor gaps like bulk data or risk management are not core, so overall good coverage.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

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

WICK Funded — TradingOAuth
com.wickfunded
Connect your AI to a funded trading account. Read & trade a simulated funded challenge.
Finance Autonomous Agents
2
alphalabs-intelligence A
io.github.Pak209
Live trading-pipeline intelligence for AI agents: signal scoring, calibration, recorded outcomes.
Finance AI & Machine Learning Agent Orchestration
62
CPZAIOAuth
com.cpz-lab.mcp
Build, backtest, and deploy quantitative trading strategies from your AI agent.
Finance Research & Data
11
newsgurus-intel B
io.github.CollectorGuru
Pay-per-call trading intelligence for AI agents: live market regime, trading signals, composite conv
Finance AI & Machine Learning
382

Related MCP Servers

ai-trader
Finance Research & Data
whchien
A
license
Not graded
quality
D
maintenance
Enables AI assistants like Claude to run backtests, fetch market data, list strategies, and analyze trading algorithms via natural language.
Updated 5 months ago (2026-03-28 11:16 UTC)
1,062
GPL 3.0
Dragonglass TradingView MCP
Finance Cryptocurrency
nightwing-7
F
license
Not graded
quality
B
maintenance
Enables AI co-pilots to interact with TradingView charts, manage alerts via REST API, automate morning briefs with custom trading rules, and perform real-time market analysis.
Updated 3 months ago (2026-06-11 03:50 UTC)
-
panther-mcpofficial
Finance Cryptocurrency
PantherWatch
A
license
A
quality
D
maintenance
Enables AI assistants to backtest trading strategies described in plain English, providing access to market data, technical indicators, and comprehensive performance reports.
Updated 5 months ago (2026-04-08 07:03 UTC)
13
1
MIT
Trader Journal MCP
Finance AI & Machine Learning
CepharsBonacci
A
license
Not graded
quality
A
maintenance
Provides AI-powered trading analytics and coaching by analyzing historical trades to identify strategies, emotional patterns, and behavioral mistakes via MCP tools.
Updated a month ago (2026-08-05 15:18 UTC)
1
MIT

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/oliverwehn/trade-analytics-mcp'

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

trade-analytics-mcp

Why — what it actually lets your AI do

🆓 Free, on your machine

💳 With a trade-analytics API key (free tier — no card)

A typical review

Tools

Setup

1. Get a Databento key (your market data)

2. Get a trade-analytics API key — free to start

3. Add the MCP to your client

Configuration

Built on the trade-analytics API

Privacy

Develop

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

panther-mcpofficial

Latest Blog Posts

MCP directory API