How do I use microstructure-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., "@microstructure-mcp show me the 4h liquidity zones and market structure for BTCUSDT" 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.

microstructure-mcp

by Rustamovppl

Overview Schema Related Servers Score Discussions

Python

Remote

microstructure-mcp

Market-microstructure primitives for AI agents, over MCP.

LLM trading agents are usually fed raw candles and asked to "figure out the chart". This server does the deterministic part for them: it computes structured market-structure features — liquidity zones, fair value gaps, order blocks, break of structure — from live exchange data and exposes them as typed MCP tools. The agent reasons; the server measures.

Works out of the box with Claude Desktop, Claude Code, and any MCP-compatible client. Data source: Bybit v5 public API (no API key required).

Tools

Tool	What it returns
`get_liquidity_zones`	Clusters of equal highs/lows (buy-side / sell-side resting liquidity), touch count, swept status, distance from price
`get_fair_value_gaps`	3-candle FVGs with zone boundaries, size %, filled / mitigated status
`get_order_blocks`	Last opposite candle before an impulsive move, with mitigation status
`get_market_structure`	Current trend read + recent BOS / CHoCH events
`get_snapshot`	Everything above in a single call — the cheapest way to give an agent full context

All tools take symbol (e.g. BTCUSDT), timeframe (1m–1w) and limit, plus per-tool sensitivity parameters. Output is compact JSON designed to be token-efficient in agent context windows.

Related MCP server: Bybit MCP Server

Quick start

git clone https://github.com/rustamovppl/microstructure-mcp
cd microstructure-mcp
pip install -e .

Add to Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "microstructure": {
      "command": "microstructure-mcp"
    }
  }
}

Then ask the agent something like: "Pull a 4h snapshot of BTCUSDT and describe where liquidity is resting relative to the current structure."

Example output

get_liquidity_zones("BTCUSDT", "4h") →

{
  "symbol": "BTCUSDT",
  "timeframe": "4h",
  "last_close": 96420.5,
  "zones": [
    {
      "side": "buy_side",
      "level": 97180.0,
      "touches": 3,
      "swept": false,
      "distance_pct": 0.7877
    }
  ]
}

Detection logic (brief)

Swings — symmetric fractal window (lookback candles each side).
Liquidity zones — swing highs/lows clustered within tolerance_pct; ≥ min_touches equal highs = buy-side liquidity, equal lows = sell-side. Marked swept once traded through.
FVG — classic 3-candle gap; tracked to mitigated (price entered the zone) or filled (traded through it).
Order blocks — last opposite-direction candle preceding a move ≥ impulse_pct within impulse_window candles.
Structure — close beyond the last confirmed swing = BOS; against prevailing direction = CHoCH.

The logic is pure-Python, dependency-light, and unit-tested (pytest tests/).

Roadmap

Multi-timeframe confluence in get_snapshot
Volume-weighted liquidity scoring
Additional data sources (Binance, Hyperliquid)
SSE transport for hosted deployment
Backtest harness for detection-parameter tuning

Disclaimer

This server produces descriptive market-structure features, not trade signals. Nothing here is financial advice; markets can and will invalidate any structural read.

License

MIT

Available Tools

5 tools

get_fair_value_gapsC

Detect 3-candle fair value gaps (FVG) with fill/mitigation status.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`symbol`	Yes
`timeframe`	No	1h
`min_gap_pct`	No
`unfilled_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must carry full behavioral transparency. It only states the core detection function, without disclosing auth needs, rate limits, or what 'fill/mitigation status' entails. The behavior is implied but not elaborated.

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

Conciseness3/5

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

The description is a single sentence with no fluff, but it may be too brief for a tool with five parameters. It front-loads the core purpose but lacks structure for detailed guidance.

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

Completeness2/5

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

Given the complexity of 5 parameters and no schema descriptions, the description is insufficient. The presence of an output schema partially compensates, but the tool lacks usage guidelines and parameter context, making it incomplete.

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 adds no information about the five parameters (symbol, limit, timeframe, min_gap_pct, unfilled_only). Parameter names are somewhat self-explanatory, but the description provides no additional semantics.

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 ('Detect') and resource ('3-candle fair value gaps'), clearly distinguishing from sibling tools like 'get_liquidity_zones' or 'get_market_structure'. It also specifies the additional feature of fill/mitigation status.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites or context that would help an agent choose between this and sibling tools.

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

get_liquidity_zonesB

Detect resting-liquidity levels (clusters of equal highs = buy-side, equal lows = sell-side).

Returns levels sorted by distance from current price, with touch count and whether the level has already been swept.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`symbol`	Yes
`timeframe`	No	1h
`min_touches`	No
`tolerance_pct`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

With no annotations, the description must disclose behaviors. It states the detection algorithm (clusters of equal highs/lows) and output sorting, but omits details like computational cost, data requirements, or how parameters like tolerance_pct affect results. It is moderately transparent but lacks depth.

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 totaling 40 words, with no filler. The first sentence clearly defines the tool's purpose, and the second describes the output. Every sentence adds value.

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

Completeness2/5

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

Given five parameters (one required), no schema coverage, and no annotations, the description should explain how each parameter influences the detection algorithm. It does not, leaving the agent without enough context to set parameters correctly for specific analysis goals. The return structure is only vaguely described.

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

Parameters1/5

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

Schema description coverage is 0%, meaning no parameter is explained in the description. The description does not add any meaning beyond the input schema's titles and defaults, leaving all five parameters (limit, symbol, timeframe, min_touches, tolerance_pct) unexplained.

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 specific verb 'detect' and resource 'resting-liquidity levels', defines them as clusters of equal highs (buy-side) and lows (sell-side), and mentions output characteristics (sorted by distance, touch count, swept status). This clearly distinguishes it from sibling tools like get_fair_value_gaps or get_order_blocks.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or scenarios where this tool is preferred. The agent is left to infer usage context from the purpose alone.

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

get_market_structureC

Current trend read plus recent break-of-structure (BOS) and change-of-character (CHoCH) events.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`symbol`	Yes
`timeframe`	No	1h

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as data freshness, error handling, or required permissions. It only states the output content.

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

Conciseness3/5

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

The description is concise with two clauses, but it lacks structured organization. It could benefit from breaking down the components or providing more detail without adding verbosity.

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

Completeness2/5

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

Given the presence of an output schema and three parameters with no descriptions, the description fails to provide sufficient context about return format or parameter usage, leaving the agent underinformed.

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

Parameters1/5

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

Schema coverage is 0% and the description does not explain any of the three parameters (symbol, timeframe, limit). No additional meaning is added beyond the schema field titles.

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 provides a current trend read and identifies break-of-structure (BOS) and change-of-character (CHoCH) events, which distinguishes it from sibling tools like get_fair_value_gaps and get_liquidity_zones.

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

Usage Guidelines2/5

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

No guidance on when or when not to use this tool, nor any mention of alternatives. The description only states what the tool does without providing context for selection.

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

get_order_blocksC

Detect order blocks: the last opposite candle before an impulsive move, with mitigation status.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`symbol`	Yes
`timeframe`	No	1h
`impulse_pct`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.3/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It mentions 'mitigation status' as an output detail, but does not disclose any behavioral traits (e.g., read-only, required permissions, computational cost, side effects). The description is too sparse to inform safe usage.

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

Conciseness2/5

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

The description is extremely concise (one sentence), but it fails to cover essential aspects like parameters, usage, or behavior. It is under-specified, not efficiently informative. Every sentence should earn its place; here it barely does.

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

Completeness1/5

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

Given the complexity (4 parameters, no schema descriptions, no annotations), the description is woefully incomplete. It does not explain how to configure the tool for typical tasks, nor does it leverage the existing output schema. An output schema exists, but the description still lacks necessary input behavior context.

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

Parameters1/5

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

Schema coverage is 0%, yet the description provides no information about parameters. The 4 parameters (symbol, limit, timeframe, impulse_pct) remain entirely unexplained. The description adds zero value beyond the schema's raw JSON structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: detecting order blocks with mitigation status. It uses a specific verb ('detect') and resource ('order blocks'). However, it does not explicitly distinguish from sibling tools like get_fair_value_gaps or get_market_structure, but the concept is distinct enough.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. No context on prerequisites, typical scenarios, or when not to use it. Users must infer based solely on the concept name.

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

get_snapshotB

One-call snapshot: structure + nearest liquidity + unfilled FVGs + recent order blocks.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`symbol`	Yes
`timeframe`	No	1h

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns structure, liquidity, FVGs, and order blocks, but it does not discuss any behavioral traits such as read-only nature, performance, or how 'nearest' or 'unfilled' are determined. The description is adequate but lacks depth.

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 a single sentence that is concise and front-loaded with the key concept 'One-call snapshot'. However, it could be slightly more detailed without losing conciseness, such as clarifying the parameters.

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

Completeness2/5

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

Given the complexity of the tool (aggregating three concepts) and the existence of an output schema, the description is partially complete but fails to explain the decision criteria for the aggregated elements (e.g., what 'nearest' means) and leaves parameter semantics entirely undeclared.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no explanation of the parameters (symbol, limit, timeframe) beyond their names. The agent must infer their meaning, which is insufficient for correct invocation.

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 it provides a 'snapshot' combining market structure, nearest liquidity, unfilled FVGs, and recent order blocks, which differentiates it from sibling tools that focus on individual components. The verb 'snapshot' implies a composite view, making the resource and action specific.

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 for a quick overview of multiple market concepts in one call, but it does not explicitly state when to use this tool versus the more specific siblings, nor does it provide when-not scenarios or alternatives.

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.

5 tool updatesv0.1.0Jul 10, 2026
- First observedget_fair_value_gaps
- First observedget_liquidity_zones
- First observedget_market_structure
- First observedget_order_blocks
- First observedget_snapshot

Install Server

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

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct microstructure concept (FVG, liquidity zones, market structure, order blocks) with clear, non-overlapping descriptions. The snapshot tool aggregates others but serves a different convenience purpose.

Naming Consistency5/5

All tools follow a consistent 'get_' prefix pattern with descriptive noun phrases (fair_value_gaps, liquidity_zones, etc.), making it easy to predict tool behavior from names.

Tool Count5/5

With only 5 tools, the server is tightly scoped to essential microstructure analysis concepts. Each tool earns its place, and the count is ideal for this specialized domain.

Completeness5/5

The set covers the core microstructure concepts (FVG, liquidity, market structure, order blocks) and adds a snapshot tool for convenience. There are no obvious gaps for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessSyncing

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

midasflow-mcp-quickstart A
io.github.midasflowai-lab
Agent-native crypto market-data over MCP+REST: order flow, whales, liquidations, calibrated scores
Cryptocurrency Finance
142
xfinlab A
io.github.lnanology
Real-time market events, sentiment, and technical analysis as MCP tools, backed by real data.
Finance AI & Machine Learning
51
AgentHC Market Intelligence B
com.traderhc
Market intelligence for AI agents. Real-time data, cross-market analysis, and regime detection.
Finance Search Research & Data
2
market-data B
ai.iturri
Verified market data for AI trading agents: quality-flagged candles, funding, OI, order flow. x402.
Finance Cryptocurrency
222

Related MCP Servers

Enterprise Crypto MCP Gateway
Jinzo03
F
license
Not graded
quality
C
maintenance
Enables MCP-compatible AI clients to access live crypto market data and AI-driven quantitative analysis, with structured outputs and full observability.
Updated a month ago (2026-07-30 23:53 UTC)
-
Bybit MCP Serverofficial
Cryptocurrency Blockchain Finance
bybit-exchange
A
license
B
quality
C
maintenance
A production-ready MCP server for Bybit — 206 tools covering market data, trading, positions, account management, assets, and real-time WebSocket streams. Enables AI assistants to interact directly with the Bybit cryptocurrency exchange through natural language.
Updated 3 days ago (2026-09-03 07:32 UTC)
382
447
31
MIT
SMC-MCP
Finance Cryptocurrency
AkhileshSelvan
A
license
A
quality
B
maintenance
Enables AI agents to analyze price action using Smart Money Concepts (market structure, order blocks, fair value gaps, liquidity sweeps) for stocks, forex, gold, indices, and crypto without an API key.
Updated 3 months ago (2026-06-14 04:09 UTC)
10
5
2
MIT
Data Puller MCP Server
Cryptocurrency Finance
arisloth
F
license
Not graded
quality
B
maintenance
Enables fetching live crypto market data from Binance, Bybit, and Hyperliquid via MCP tools, including klines, orderbook, funding rates, technical indicators, and market breadth for real-time analysis by LLMs.
Updated a month ago (2026-07-23 19:05 UTC)
-

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/Rustamovppl/microstructure-mcp'

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

microstructure-mcp

Tools

Quick start

Example output

Detection logic (brief)

Roadmap

Disclaimer

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Bybit MCP Serverofficial

Latest Blog Posts

MCP directory API