Enables Binance trading with pre-trade AI risk assessment, natural-language trade intent parsing, yield arbitrage comparison between Binance Earn/funding rates and CHAINZ vaults, and safety-gated spot/futures order execution.
Uses NVIDIA NIM GPU-accelerated inference to evaluate cryptocurrency trade risk, calculate liquidation hazard scores, and recommend safe leverage levels.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@chainz-sentinel-mcp Should I open a 10x long on BTCUSDT right now?"
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.
Binance Agent OS Mini Hackathon Entry
Primary Track: Track B ā Connect your MCPs and trade ($40,000 USDC)
Secondary Track: Track A ā Build an AI agent with Agent OS ($20,000 USDC)
CHAINZ Sentinel MCP is an institutional Model Context Protocol (MCP) server that supercharges Binance Agent OS with sub-millisecond AI trade risk assessment (powered by NVIDIA NIM) and cross-venue zero-debt real-yield arbitrage.
While traditional trading agents execute orders blindly based on raw prompt matching, CHAINZ Sentinel introduces an automated capital preservation guard:
Pre-Trade Risk Sentinel: Before any Binance trade executes, NVIDIA NIM evaluates market volatility and calculates exact liquidation hazard scores in $<50\text{ ms}$.
Natural Language Intent Router: Translates conversational user goals into validated spot and futures trading parameters.
Real-Yield Alpha Arbitrage: Real-time benchmarking comparing Binance Earn / Funding rates with CHAINZ Layer 1 on-chain real-yield vaults (AMM fee sharing + RWA dividends).
Execution Safety Gate: Blocks unsafe trades and automatically downsizes high-leverage orders to prevent liquidation spirals.
Related MCP server: Binance Trading Agent MCP Server
flowchart TB
subgraph Binance_Ecosystem [Binance Agent OS & Client Layer]
User["User Prompt / Autonomous Trader"] --> AgentOS["Binance Agent OS"]
end
subgraph MCP_Layer [Chainz Sentinel MCP Server (JSON-RPC 2.0 stdio)]
AgentOS <-->|"Model Context Protocol"| MCP["chainz-sentinel-mcp (Node.js)"]
MCP --> Tool1["evaluate_trade_risk"]
MCP --> Tool2["parse_trade_intent"]
MCP --> Tool3["query_yield_arbitrage"]
MCP --> Tool4["execute_hedged_trade"]
end
subgraph Intelligence_And_Execution [AI & Settlement Engines]
Tool1 & Tool2 <-->|"Inference API"| NIM["NVIDIA NIM GPU Sentinel (integrate.api.nvidia.com)"]
Tool3 <-->|"Real-Yield Oracle"| L1["CHAINZ Layer 1 Staking Vaults (Chain ID: 999402778)"]
Tool4 <-->|"Order Routing"| BinanceAPI["Binance Spot / Futures API"]
endevaluate_trade_riskDescription: Evaluates cryptocurrency trade risk, liquidation probability, and systemic volatility using NVIDIA NIM GPU-accelerated inference.
Inputs: symbol (e.g. BTCUSDT), side (BUY/SELL), amount, leverage (default 1), currentPrice (optional).
Outputs:
risk_score ($0 - 100$)
verdict (APPROVED / CAUTION / REJECTED)
liquidation_buffer_pct (Distance to liquidation)
max_recommended_leverage
parse_trade_intentDescription: Translates conversational prompts into structured Binance trading parameters.
Inputs: prompt (string)
Outputs: symbol, action, order_type, amount_usd, leverage, notes.
query_yield_arbitrageDescription: Benchmarks Binance Earn / Funding rates against CHAINZ zero-debt fee-sharing vaults (55% AMM fees + 30% RWA dividends + 15% bridge relayers).
Inputs: symbol (USDT, USDC, BTC, ETH), capitalUsd.
Outputs: Baseline yield, CHAINZ yield, Net Alpha APY spread, and recommended capital allocation.
execute_hedged_tradeDescription: Gates order execution against the pre-trade risk score, executing only when capital safety criteria are met.
Inputs: symbol, side, amountUsd, riskScore, overrideApproved.
Outputs: status (FILLED or REJECTED), order_id, zero_debt_guard status.
Node.js v18+ (tested on Node v20/v24)
No external npm package installations required! Zero internet drain.
cd binance-agent-mcpRun the automated MCP test suite to simulate Binance Agent OS:
node test_mcp_client.mjsExpected output:
======================================================================
š Testing Chainz Sentinel MCP Server for Binance Agent OS
======================================================================
1. Testing 'initialize' handshake...
ā
Server Name: chainz-sentinel-mcp
ā
Protocol Version: 2024-11-05
2. Testing 'tools/list' discovery...
ā
Found 4 Tools: evaluate_trade_risk, parse_trade_intent, query_yield_arbitrage, execute_hedged_trade
3. Testing 'evaluate_trade_risk' (NVIDIA NIM GPU Sentinel)...
ā
Risk Score: 58 / 100
ā
Sentinel Verdict: CAUTION
4. Testing 'parse_trade_intent'...
ā
Derived Symbol: ETHUSDT, Action: BUY
5. Testing 'query_yield_arbitrage'...
ā
Binance: 7.2% APY vs CHAINZ: 18.4% APY (+11.2% Net Alpha)
6. Testing 'execute_hedged_trade'...
ā
Execution Status: FILLED (No liquidation hazard detected)
š ALL TESTS PASSED (100% SUCCESS) ā READY FOR BINANCE AGENT OS!Add the server configuration into your Binance Agent OS MCP registry (binance_agent_config.json):
{
"mcpServers": {
"chainz-sentinel": {
"command": "node",
"args": ["<PATH_TO_DIR>/index.mjs"],
"env": {
"NVIDIA_NIM_BASE_URL": "https://integrate.api.nvidia.com/v1",
"NVIDIA_API_KEY": "<YOUR_NVIDIA_API_KEY>",
"NVIDIA_DEFAULT_MODEL": "meta/llama-3.1-8b-instruct"
}
}
}
}Evaluation Criteria | How CHAINZ Sentinel Exceeds Expectations |
Technical Complexity | Combines the Model Context Protocol (MCP) standard with NVIDIA NIM sub-millisecond GPU inference and EVM Layer 1 smart contracts. |
Real Trading Utility | Prevents retail and algorithmic traders from catastrophic liquidation cascades through pre-trade AI safety gating. |
Zero External Bloat | Fully self-contained Node.js JSON-RPC stdio engine that adheres to strict zero-dependency bandwidth guidelines. |
Cross-Ecosystem Synergy | Bridges Binance's world-leading liquidity with CHAINZ asset-backed zero-debt financial architecture. |
MIT License ā Free and open-source for the Binance & Web3 AI community.
Evaluates cryptocurrency trade risk and liquidation probability using NVIDIA NIM sub-millisecond GPU inference.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Order side | |
| amount | Yes | Trade size in USD or asset units | |
| symbol | Yes | Trading pair (e.g., BTCUSDT, ETHUSDT, SOLUSDT) | |
| leverage | No | Proposed leverage multiplier (default 1) | |
| currentPrice | No | Current market price if known |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It reveals a performance trait (NVIDIA NIM sub-millisecond GPU inference) but says nothing about side effects, required permissions, output format, or read-only/read-write behavior. This is insufficient given the absence of annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that wastes no words and front-loads the core purpose. Mentioning the NVIDIA NIM performance detail adds relevant context without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotation support, the description needed to explain what the tool returns and how to interpret the risk/liquidation result. It omits prerequisites, return shape, and relationship to the sibling trade-execution workflow, leaving an agent without key information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no extra meaning to parameter semantics and does not resolve ambiguities such as whether amount is in USD or asset units. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('evaluates') and a precise resource ('cryptocurrency trade risk and liquidation probability'), which clearly distinguishes it from siblings like parse_trade_intent and execute_hedged_trade. The purpose is immediately recognizable and not a tautology of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus parse_trade_intent, query_yield_arbitrage, or execute_hedged_trade. It implies a pre-trade risk assessment use case but never states conditions, exclusions, or which alternative to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Routes a trade with pre-trade risk sentinel gating to prevent liquidation cascades and preserve capital.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Order side | |
| symbol | Yes | Trading pair (e.g., BTCUSDT) | |
| amountUsd | Yes | Notional trade size in USD | |
| riskScore | Yes | Risk score from evaluate_trade_risk (0-100) | |
| overrideApproved | No | Set true to override CAUTION recommendations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing behavior. It mentions risk gating but gives no concrete details about what gates or rejects a trade, how overrideApproved interacts with gating, whether an order is actually placed, or what side effects or failure modes exist. This is especially significant for a trade-execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It briefly states what the tool does and why. It loses a point only because the phrase 'pre-trade risk sentinel gating' is jargon-heavy and compresses a lot of unexplained behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a potentially irreversible financial action with no annotations and no output schema, yet the description omits crucial context: what happens when risk gating blocks, how override works, and what the caller should expect after execution. The provided schema covers parameters but not the behavioral context needed to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description adds no specific parameter-level semantics beyond the general notion of risk gating, which is appropriately at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: routing a trade with pre-trade risk sentinel gating. It also conveys the intended outcome (prevent liquidation cascades, preserve capital), and the verb 'routes' distinguishes this execution tool from the risk-evaluation and parsing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pre-trade risk sentinel gating' implies this is the execution step after risk evaluation, and the riskScore parameter references evaluate_trade_risk. However, the description never explicitly states when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translates natural language user trading prompts into structured parameters for Binance Agent OS.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Free-form user prompt (e.g. 'Hedge 20% of my BTC position if price drops below 60k') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'translates' without detailing the output shape, error behavior, or side effects. It does not clarify whether parsing is purely local or involves remote calls, nor does it describe how the structured parameters are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It conveys the essential purpose efficiently and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not explain the structure or format of the 'structured parameters' it produces. An agent would need to know the keys, types, or example output to correctly chain this tool with downstream trading tools. The one-liner is too sparse for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the single 'prompt' parameter with an example. The description does not add parameter-level meaning beyond calling it a 'user trading prompt', which is consistent with the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Translates natural language user trading prompts') and a resource ('into structured parameters for Binance Agent OS'), making the core function immediately understandable. It is distinct from siblings like evaluate_trade_risk and execute_hedged_trade, though it does not explicitly name them to preempt confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 its siblings, nor does it mention any preconditions or follow-up steps. It simply defines the action, leaving the agent to infer that this is a natural first step for trade intent processing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares Binance Earn and funding rates with CHAINZ on-chain zero-debt real-yield vaults (AMM fee sharing + RWA dividends).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Asset symbol (USDT, USDC, BTC, ETH) | USDT |
| capitalUsd | No | Total capital allocated for yield generation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the comparison scope but does not mention what the output looks like, whether the data is live or delayed, any rate limits, or that this is a read-only operation beyond the verb 'compares'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, substantive sentence that front-loads the main action and includes valuable specifics about the compared sources. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The two fully documented parameters make invocation straightforward, and the description conveys the core purpose. However, there is no output schema and no description of the return format or comparison results, leaving some ambiguity about what the agent will actually receive after calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already described with defaults and examples. The description adds no additional meaning about how 'symbol' or 'capitalUsd' affect the comparison, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Compares') and the exact resources being compared: Binance Earn/funding rates versus CHAINZ on-chain yield vaults. This clearly differentiates it from sibling tools like evaluate_trade_risk, parse_trade_intent, and execute_hedged_trade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The comparison wording implies it should be used for yield-arbitrage assessment, but the description never explicitly states when to use this tool versus the siblings or any exclusions. There is no 'use when' language or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0evaluate_trade_riskexecute_hedged_tradeparse_trade_intentquery_yield_arbitrageEach tool has a generally distinct role: parsing intent, evaluating risk, querying yield opportunities, and executing hedged trades. The only mild overlap is that execute_hedged_trade includes pre-trade risk gating, which could make an agent unsure whether to call evaluate_trade_risk separately.
All four tools follow the same verb_noun snake_case pattern: evaluate_trade_risk, parse_trade_intent, query_yield_arbitrage, execute_hedged_trade. This makes the tool set predictable and easy to navigate.
Four tools is a well-scoped size for a focused risk-sentinel and trade-orchestration server. Each tool provides a distinct, necessary capability without unnecessary bloat.
The set covers an end-to-end flow from intent parsing to risk evaluation to hedged execution and yield comparison. However, it lacks supporting operations such as trade status lookups, position/balance queries, or risk parameter configuration, so an agent cannot fully manage a trade lifecycle natively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Brain Layer for AI Trading Agents ā quant calls + cross-venue arb across perp venues via MCP.
Pay-per-call trading intelligence for AI agents: live market regime, trading signals, composite conv
Crypto trading intelligence MCP ā 34+ endpoints, x402 pay-per-use, AI agent strategy & execution
Non-custodial trading for AI agents: 1,900+ assets ā US stocks, treasuries, gold, 250+ perps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Chainz-Blockchain/binance-agent-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
