Markolis ships an MCP server that exposes market microstructure data (order flow, volatility bands, session overlaps, causal transmission graphs) as callable tools. The interesting part is not the data itself but the protocol design: how do you translate sub-second order book updates, exchange-specific schemas, and institutional compliance boundaries into a standardized tool interface that agents can query without writing custom API clients?
Most MCP servers wrap CRUD operations or document retrieval. Financial market data introduces different constraints: streaming tick updates, deterministic snapshots for backtesting, rate-limited exchange connections, and regulatory guardrails that must fire before the agent sees a response.
Protocol Shape
The MCP server exposes tools like expected_volatility, prop_drawdown_buffer, session_overlap, auction_profile, and causal_spillover. Each tool returns structured JSON with quantitative metrics, confidence intervals, and source attribution.
Key design choices:
- Snapshot vs. streaming: Tools return point-in-time snapshots. Real-time updates require polling or external websocket subscriptions. MCP does not define streaming primitives, so the server batches recent ticks into a queryable state.
- Normalization layer: Exchange-specific formats (Binance depth snapshots, Coinbase L2 order books, traditional equity feeds) get translated into a common schema before exposure. The server maintains adapters per exchange and asset class.
- Rate limit pooling: Multiple agents querying the same server share a connection pool. The server enforces per-exchange rate limits and queues requests when capacity is exhausted.
- Compliance boundaries: Tools like price target prediction or direct trade recommendations return refusal messages. The guardrail logic runs server-side before the response reaches the agent.
Tool Call Flow
When an agent calls expected_volatility with parameters {symbol: "EUR/USD", horizon: "1h"}, the server:
- Checks the request against compliance rules (no price targets, no direct trade advice).
- Queries the normalized order book and tick cache for recent data.
- Calculates Parkinson and Garman-Klass variance estimators.
- Constructs a 90% conformal prediction band.
- Returns JSON with the volatility estimate, band bounds, and source metadata.
The agent sees a structured response, not raw exchange data. The server handles the translation, caching, and statistical computation.
Data Normalization
Market microstructure data arrives in incompatible formats:
| Exchange | Depth Format | Tick Precision | Rate Limit |
|---|---|---|---|
| Binance | Snapshot + deltas | 8 decimals | 1200 req/min |
| Coinbase | Full L2 book | Variable | 10 req/sec |
| Traditional | FIX protocol messages | 4 decimals | Session-based |
The normalization layer:
- Converts all depth data into a canonical bid/ask ladder with standardized price levels.
- Resamples tick timestamps to a common granularity (1ms for crypto, 100ms for equities).
- Maps exchange-specific trade flags (maker/taker, auction participation) to a unified schema.
This layer runs inside the MCP server, not in the agent. The agent calls get_order_flow and receives a normalized response regardless of the underlying exchange.
State Management
The server maintains:
- Tick cache: Rolling window of recent trades and quotes, stored in-memory with TTL eviction.
- Order book snapshot: Latest depth state per symbol, updated via websocket subscriptions.
- Session metadata: Active trading hours, upcoming economic events, blackout periods.
When an agent queries session_overlap, the server checks the current UTC time against known session boundaries (London open, New York close) and returns a boolean plus a volatility multiplier derived from historical session overlap patterns.
The cache is not persistent. If the server restarts, it rebuilds state from exchange APIs. For backtesting, agents must query a separate historical data service and pass snapshots as context.
Authentication and Rate Limits
The server uses API keys for exchange connections. Agents do not see these keys. The MCP server acts as a proxy:
- Key rotation: Exchange API keys are stored in environment variables and rotated without agent involvement.
- Rate limit pooling: If three agents query the same symbol simultaneously, the server queues requests and returns cached data when limits are hit.
- Fallback logic: If an exchange connection fails, the server attempts a fallback source (e.g., aggregated data from a backup provider) before returning an error.
This design isolates agents from exchange-specific authentication flows and rate limit logic.
Compliance Guardrails
The server refuses certain queries:
- Price targets: “Predict Gold price” returns a refusal message citing CFTC 4.41 advisory.
- Direct trade advice: “Should I buy 2 lots?” triggers a compliance error.
- Unverified data: Tools only return metrics with source attribution and confidence intervals.
These guardrails run before the agent sees a response. The MCP server does not rely on the agent’s prompt engineering to avoid regulatory violations.
Example Tool Call
{
"tool": "expected_volatility",
"parameters": {
"symbol": "EUR/USD",
"horizon": "1h"
}
}Response:
{
"volatility_pips": 41,
"conformal_band": [35, 47],
"confidence": 0.90,
"estimator": "Parkinson-GK",
"source": "BIS/FX-Fix",
"timestamp": "2026-11-09T12:00:00Z"
}The agent receives a structured metric, not raw tick data. The server handles the statistical computation and confidence interval construction.
Deployment Shape
The MCP server runs as a standalone process:
- Hosting: Single instance per environment (dev, staging, prod). No horizontal scaling yet.
- Connections: Persistent websocket subscriptions to exchanges, HTTP polling for session metadata.
- Observability: Logs tool calls, cache hit rates, and rate limit exhaustion events. No distributed tracing yet.
- Failure modes: If an exchange websocket disconnects, the server attempts reconnection with exponential backoff. If all sources fail, tools return stale data with a staleness warning.
Agents connect via MCP protocol (typically HTTP or stdio transport). The server does not expose a public API; it only responds to authenticated MCP clients.
Trade-offs
| Decision | Benefit | Cost |
|---|---|---|
| Snapshot-only tools | Simple request/response model | No real-time streaming without polling |
| Server-side normalization | Agents avoid exchange-specific logic | Server must maintain adapters per source |
| Shared connection pool | Efficient rate limit usage | Single point of failure for all agents |
| Compliance refusals | Regulatory safety | Agents cannot override guardrails |
Likely Failure Modes
- Stale data: If websocket subscriptions drop and reconnection fails, agents receive outdated snapshots without realizing it.
- Rate limit exhaustion: High agent query volume can exhaust exchange rate limits, causing all tools to return cached data.
- Normalization drift: Exchange schema changes (new tick flags, precision adjustments) can break the normalization layer until adapters are updated.
- Single instance bottleneck: No horizontal scaling means the server becomes a bottleneck as agent count grows.
Technical Verdict
Use Markolis MCP server when:
- You need agents to query market microstructure data without writing exchange-specific API clients.
- You want server-side compliance guardrails that agents cannot bypass.
- You can tolerate snapshot-based data and do not require sub-second streaming.
- You operate in a regulated environment where source attribution and confidence intervals are mandatory.
Avoid when:
- You need real-time tick streaming with sub-100ms latency.
- You require horizontal scaling across multiple server instances.
- You want agents to access raw exchange data without normalization.
- You need persistent state for backtesting without external historical data services.
The protocol design is clean: agents call tools, the server handles exchange complexity, and compliance boundaries are enforced server-side. The missing piece is streaming primitives, which MCP does not yet define. For now, agents must poll or subscribe to external websockets and use the MCP server for snapshot queries and derived metrics.