Sablier MCP Serverofficial
A
licenseA
qualityD
maintenanceAn MCP server that lets AI assistants analyze portfolios, stress-test scenarios, generate synthetic market paths, and scan SEC filings — in under 2 minutes.
83
3
MIT
ThinChain
by SnipMCP
Integrates with Polygon.io to fetch market data and options chains, providing sanitized and compressed data for AI trading agents.
ThinChain
The catalytic converter between raw broker data and your AI trading agent.
Battle-tested. Sanitization logic extracted from a production options trading app. Handles every bad tick Tradier has thrown at us in production.
☁️ Moving to production?
The open-source server runs locally with your own API keys. For hosted infrastructure with multi-broker failover, SLA guarantees, and webhook alerts — join the managed cloud waitlist.
Related MCP server: Crypto Options Desk MCP
The Problem
Tradier's MCP dumps 500-row JSON chains. One bad print can corrupt an agent's reasoning. ThinChain sanitizes, compresses, and circuit-breaks that data before it reaches your model.
Installation
git clone https://github.com/snipmcp/thinchain.git
cd thinchain
pip install -e ".[dev]"
cp .env.example .envOr with Docker:
docker-compose up --buildConfiguration
TRADIER_API_KEY=your_key_here
TRADIER_BASE_URL=https://api.tradier.com/v1
POLYGON_API_KEY=your_key_here
POLYGON_BASE_URL=https://api.polygon.io
DEFAULT_BROKER=tradier
CACHE_TTL_SECONDS=30
LOG_LEVEL=INFOUsage
Three example prompts to send to Claude (or any MCP-compatible agent):
Use get_compressed_chain to get an iron condor setup on SPY expiring 2026-06-19Check if SPY options data is trustworthy before I place my tradeGet me the ATM straddle strikes for AAPL expiring 2026-06-19
Run it in two terminals
# Tab 1 — start the MCP server
python -m thinchain.server# Tab 2 — call a tool from a Python shell or your MCP client
# Tool signatures:
# get_compressed_chain(symbol, expiration, strategy="raw",
# delta_range=None, broker="tradier")
# get_sanitized_quote(symbol, broker="tradier")
# get_circuit_status(symbol, expiration, broker="tradier")How it works
Three layers between raw broker output and your model:
Broker API → [Sanitize] → [Compress] → [Circuit Break] → MCP Tool → AI Agent
hygiene strategy anomaly gate
rules slicing + cacheSanitize: Drops ghost quotes (0.0/0.0), inverted spreads, NaN/empty/dash values, clamps deltas to [-1, 1], normalizes positive theta on long options, flags illiquid strikes.
Compress: Slices the chain to only the strikes relevant to your strategy (iron condor, straddle, etc.) — typically 95%+ token reduction.
Circuit Break: Four-tier data quality (
clean/noisy/degraded/circuit_breaker_active). When >65% of rows are anomalous, refuses to serve stale data and falls back to last known-good cache.
Real numbers from a live SPY iron condor (2026-06-19 expiration)
RAW TRADIER PAYLOAD THINCHAIN OUTPUT
─────────────────────────────────────────────
Rows: 482 Rows: 25
Est tokens: 38,560 Est tokens: 2,000
Token savings: 95%
Anomalous rows removed: 217
Data quality: noisy → still safely servedThinChain compresses 482 rows / 38,560 tokens down to 25 rows / 2,000 tokens — and flags 217 anomalous strikes (illiquid, ghost quotes, wide spreads) that would have polluted the agent's context.
Roadmap
Managed cloud tier (hosted, multi-tenant, webhook alerts)
Polygon connector hardening (live SIP feed)
Webhook alerts for circuit breaker trips
Contributing
PRs welcome. Run pytest before submitting.
Available Tools
3 toolsget_circuit_statusC
Check whether live options data for a symbol is currently trustworthy.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| expiration | Yes | ||
| broker | No | tradier |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, description only says 'check whether trustworthy' but fails to define trustworthy, criteria, side effects, or return behavior.
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?
Single sentence, front-loaded with action and object, no wasted words. Could be slightly more informative but not verbose.
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?
With 3 parameters, 2 required, no annotations, and an output schema present, the description is too brief; does not explain what 'trustworthy' means or what the tool returns.
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?
0% schema description coverage; description does not elaborate on symbol, expiration, or broker parameters, leaving meaning underspecified.
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 uses specific verb 'check' and resource 'live options data for a symbol', clearly distinguishing from siblings like get_compressed_chain and get_sanitized_quote.
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 when-not or usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_compressed_chainC
Fetch, sanitize, and compress an options chain for AI agent use.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| expiration | Yes | ||
| strategy | No | raw | |
| delta_range | No | ||
| broker | No | tradier |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.6/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 responsibility. It mentions sanitization and compression but does not explain what these entail, what data is affected, or any side effects. Minimal behavioral disclosure.
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?
Single sentence with a front-loaded verb and clear resource. Efficient but could be slightly more informative without losing conciseness.
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?
Despite having an output schema, the description fails to explain input parameters or the meaning of 'sanitize' and 'compress.' With 5 parameters and no annotations, the description is inadequate for correct tool invocation.
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 adds no explanation for any of the 5 parameters (symbol, expiration, strategy, delta_range, broker). The agent must infer meaning from names alone, which is insufficient.
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 specifies 'fetch, sanitize, and compress an options chain,' which clearly indicates the verb and resource. It distinguishes from siblings like get_circuit_status and get_sanitized_quote, but does not explicitly contrast them.
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. The phrase 'for AI agent use' implies a context but does not set exclusions or provide selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sanitized_quoteC
Get a single underlying quote with data quality check.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| broker | No | tradier |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behaviors. It mentions 'data quality check' but does not explain what that entails (e.g., normalization, filtering), nor does it disclose any side effects, permissions, or latency implications. This is insufficient for an unannotated tool.
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 extremely short at one sentence. While it is concise, it lacks necessary detail to be informative, making it borderline under-specified.
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 absence of schema descriptions and annotations, the description is too minimal to fully prepare an agent. The output schema exists but the description does not leverage it to reduce burden. The 'data quality check' aspect remains vague.
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%, so the description must explain parameters. However, it does not describe the meaning or usage of 'symbol' or 'broker'. The broker parameter has a default but no explanation of how it affects results.
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 verb 'Get' and resource 'underlying quote' with a qualifier 'data quality check', indicating a specialized quote. It is distinct from sibling tools (get_circuit_status, get_compressed_chain) due to the focus on quotes and data quality, but the term 'sanitized' is not explained.
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 siblings or under what conditions. There is no mention of alternatives or exclusions, leaving the agent without context for selection.
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.
3 tool updates
v0.1.1- First observed
get_circuit_status - First observed
get_compressed_chain - First observed
get_sanitized_quote
TDQS
B3/5.0
Disambiguation5/5
Each tool targets a distinct purpose: checking data reliability, fetching compressed options chain, and getting a single quote with validation. No overlap in functionality.
Naming Consistency5/5
All tools follow a consistent 'get_' prefix and snake_case convention, making the pattern predictable and easy to understand.
Tool Count4/5
With only 3 tools, the set is compact but well-scoped for a focused domain of options data retrieval with quality checks. Slightly on the smaller side but appropriate for the narrow purpose.
Completeness3/5
The tools cover core actions (status check, compressed chain, single quote) but lack support for raw chain retrieval, individual option details, or batch operations, leaving notable gaps for comprehensive data access.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP for stocks, options, Greeks, brokers, order previews, alerts, and workflows.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Research-only MCP server: turn your AI into a quant research desk — backtests, no trades.
Agent-native crypto market-data over MCP+REST: order flow, whales, liquidations, calibrated scores
Related MCP Servers
- AlicenseBqualityCmaintenanceAn MCP server that gives an LLM agent a typed, audited tool surface over quant crypto-options desk analytics: gamma exposure, vanna, skew, vol surface, options flow, technicals, portfolio greeks, scenario analysis, and live positions.221MIT
- AlicenseNot gradedqualityDmaintenanceA production-grade MCP server that integrates Polygon.io market data with an 18-layer technical analysis engine to generate actionable options trading signals and high-probability playbooks.1MIT
- AlicenseNot gradedqualityFmaintenanceMCP server for spread-only options execution on Base L2, enabling AI agents to trade options via a defined tool loop.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/SnipMCP/thinchain'
If you have feedback or need assistance with the MCP directory API, please join our Discord server