Skip to main content
Glama
dushaorighthere

RiskPilot

by dushaorighthere
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

RiskPilot

Risk-controlled crypto trading agent built with Binance Agent OS and Binance MCP.

Risk before execution. A risk-controlled crypto agent workflow designed for Binance Agent OS.

RiskPilot turns market snapshots and structured agent proposals into LONG, SHORT or NO_TRADE decisions. A deterministic engine checks every candidate before a local paper fill. Refusals are first-class outputs, with specific reasons and a verifiable audit trail.

Status: final release candidate verified on 2026-09-05; PAPER execution only. Official OAuth, four real read-only tools, concrete schema binding, CLI/UI decisions and risk-refusal audit evidence are complete. Codex owns the credentials. The earlier unauthenticated HTTP 401 probe is historical. Public GitHub, video, X publication and the final survey remain participant actions. See integration verification and security audit.

Problem and approach

An AI-generated trade idea can be wrong, oversized or explicitly unsafe. RiskPilot separates proposal from authority: market data and an agent may propose an action, while an independent deterministic engine decides whether it is allowed. This makes refusals, position sizing and the exact policy visible and auditable.

AI can propose a trade, but it cannot override deterministic risk controls.

RiskPilot is not a conventional auto-trading bot. It has no exchange execution adapter. The implemented workflow ends in a local PAPER decision and, when approved, a simulated entry recorded in SQLite.

Related MCP server: forge-agent-gate

Start in under a minute

Offline/public REST modes require Python 3.11+, with no runtime pip dependencies or build step. Agent OS mode additionally requires an installed, authenticated Codex CLI (verified with 0.149.1); no API key is entered into RiskPilot.

On Windows, double-click START_DEMO.cmd. It detects an available Python runtime and opens the page. Keep the server window open.

Portable command, from this repository:

python -m riskpilot serve

Open http://127.0.0.1:8765. If the port is occupied, use python -m riskpilot serve --port 8766 and the URL printed by the server. All servers bind to 127.0.0.1 only. Ctrl+C stops the process. No system security settings need to change.

Optional isolated environment:

python -m venv .venv
# Windows (activation is not required):
.venv\Scripts\python -m riskpilot serve
# macOS/Linux:
.venv/bin/python -m riskpilot serve

The 90-second demonstration

Click New paper session to start with an empty simulated portfolio while retaining history.

  1. Select Agent OS MCP · read only, ETH/USDT, then Analyze & check. Confirm AGENT_OS_HOST_BRIDGE, the current market snapshot and a natural LONG, SHORT or NO_TRADE result. Do not force a trade.

  2. Switch to Synthetic demo · offline, select 02 · Valid long, then analyze. Expect APPROVED, about 2.60:1 net R:R, 0.9933 ETH, $44.94 modeled stop risk, and SIMULATED_FILL.

  3. Select 03 · Unsafe request, then analyze. The request asks for 50x leverage and more size. Expect REJECTED, including RISK_LIMIT_EXCEEDED, LEVERAGE_LIMIT_EXCEEDED and POSITION_LIMIT_EXCEEDED; no new fill.

  4. Inspect Audit trail, expand the full decision and show the verified chain.

01 · No setup and 04 · Valid short provide reproducible NO_TRADE and SHORT results. The short is a local directional simulation; it does not short spot ETH or open a derivatives account. Synthetic prices are illustrative. Live market prices and decisions will differ.

See the script, shot list and replication guide.

Binance Agent OS / MCP and system architecture

Mode

Implementation

Evidence / limitations

Synthetic demo

Deterministic generated hourly candles and a demo command router

Offline, explicitly labeled; no LLM used inside the page

Binance public data

Three fixed public GET routes: exchangeInfo, klines, bookTicker

No credentials; no fallback on errors; unfinished candle excluded

Local MCP tools

riskpilot_policy, riskpilot_analyze, riskpilot_audit over stdio

AI hosts can supply structured proposals; every candidate enters the same engine

Agent OS host bridge

Codex app-server uses its stored OAuth; verified spot.exchangeInfo, spot.klines and spot.depth feed the same engine

Authenticated CLI/UI reads, PAPER fill, rejection and audit verified; no LLM turn is required for acquisition

Execution

SQLite paper entry simulation only

No LIVE adapter, environment switch, order endpoint or funds-transfer operation

The page is a reliable demonstration surface, not an LLM chat service. Connect a compatible AI host to the local MCP server to give natural-language reasoning access to the guarded tools. Use the host prompt and connection guide. The model may propose price levels and quantities; it cannot set policy, approve its own trade, or access exchange writes through RiskPilot.

Select Agent OS MCP · read only in the UI to use the authenticated bridge. The CLI binds CodexMarketBridge through AgentOSAdapter; library users can inject the same bridge. Codex must expose exactly spot.ticker24hr, spot.exchangeInfo, spot.klines and spot.depth. tool_execute, account reads and exchange writes are excluded. The bridge rejects unsupported tools and symbols before transport and rejects mismatched schemas/data. Authentication errors never switch silently to REST or fixtures. See setup and actual tool schemas.

The implemented flow is:

Binance MCP read-only market data
        ↓
validated normalized snapshot
        ↓
strategy or untrusted agent proposal
        ↓
deterministic risk engine
        ↓
NO_TRADE / REJECTED / approved local PAPER fill
        ↓
hash-linked audit trail

See the detailed architecture.

Hard rules and calculations

Immutable policy: $10,000 paper equity, default requested risk 0.5%, maximum risk 1%, minimum net R:R 2, leverage 1–3x, one position ≤30% of equity in notional, ≤3 open positions, total notional ≤100% of equity and aggregate modeled stop risk ≤2%.

Stop loss and take profit are required. Direction, price tick, quantity step, minimum notional, spread ≤20 bps, quote age ≤90 seconds, market/proposal symbol match and entry within 0.3% of midpoint are checked. Public symbol filters are fetched; fixtures use declared paper filters.

Quote age is measured from the public request start, not an exchange event timestamp: bookTicker does not provide one. The last closed hourly bar must end within 3,700 seconds. This is a data validation boundary, not a guarantee that an upstream quote was never delayed.

For entry E, stop S, target T and combined per-side fee/slippage rate c = 0.001 + 0.0005:

loss_per_unit   = abs(E - S) + (E + S) * c
reward_per_unit = abs(T - E) - (E + T) * c
net_rr          = reward_per_unit / loss_per_unit
risk_budget     = equity * min(requested_risk_pct, 0.01)
auto_quantity   = floor_to_step(min(risk_budget / loss_per_unit,
                                   equity * 0.30 / E,
                                   available_margin * leverage / E))

Oversized explicit quantities and excessive requested risk are rejected, never silently approved after capping. Leverage changes margin, not the calculation of loss at the stop. Costs are illustrative conservative assumptions, not a representation of a specific Binance fee tier. Stop gaps, liquidity, funding, liquidation, partial fills, stop/target order placement, exits and mark-to-market P&L are not modeled. Actual losses are not bounded by these estimates.

The illustrative strategy uses SMA8/SMA21 separation greater than 0.3%, slow-SMA slope and the last closed price relative to SMA8. Stop distance is the larger of 1.5×ATR14 or 1.2% of price. Target distance is 3.5×stop distance before tick rounding. There is no trained prediction model, optimized backtest or profitability claim.

Audit and duplicate protection

  • Full market snapshots, policy hash/version, proposal, checks, portfolio before/after, decision and execution outcome are logged.

  • SQLite BEGIN IMMEDIATE commits paper fill, exposure, result and audit events atomically. Audit-write failure rolls back the fill.

  • A request ID is persistent across restarts. Reusing it returns the stored result; changing its inputs returns IDEMPOTENCY_CONFLICT.

  • A second request ID for an identical proposal on the same closed candle is blocked as DUPLICATE_ACTION within the paper session.

  • Each audit event hashes its exact payload, sequence and previous hash. Startup and transactions verify the chain.

  • New paper sessions retain previous positions and events; they do not claim realized P&L or settlement.

  • Hashes detect accidental or partial changes. There is no external anchor: someone controlling files can rewrite a whole chain, truncate its tail, modify other tables or change code. This is not tamper-proof storage.

  • Free-form prompts and raw rejected model text are not persisted. Never paste secrets into the demo.

Reproduce the tests

python -m pip install -r requirements-dev.txt
python -m pytest -q
python -m compileall -q riskpilot tests scripts

Optional independent SDK and lint gates, in a project environment:

python -m pip install -r requirements-dev.txt
python -m ruff check .
python -m ruff format --check .
python scripts/verify_sdk.py

The SDK check starts a real subprocess and tests initialization, tool discovery, paper fill, rejection, retry and audit retrieval. It connects only to local RiskPilot. It does not prove Binance OAuth or a real LLM session. Saved results are in evidence/.

CLI examples:

python -m riskpilot analyze --scenario danger
python -m riskpilot analyze --scenario short
python -m riskpilot analyze --source binance_public --symbol ETHUSDT
python -m riskpilot audit
python -m riskpilot new-session
python -m riskpilot --db runtime/agent.sqlite3 mcp

Database arguments come before the subcommand. All runtime files are excluded from Git. The sample .env.example is a placeholder; this release reads no credentials and does not load .env. RISKPILOT_MODE=LIVE in the process environment is refused. There is no need to create a Binance API secret.

Binance OAuth and human authorization

RiskPilot never asks for or reads an OAuth token. Configure the official endpoint and four-tool allowlist in a supported Codex client, then run codex mcp login binance-mcp-server. The participant must personally complete Binance login, OAuth consent and any 2FA. Keep optional account, trading, borrowing and transfer permissions disabled. Exact configuration and verification steps are in agent/CONNECT.md.

The participant must also personally confirm eligibility, publish the GitHub repository and video, post on X, and submit the Binance survey. Those public or account-bound actions are listed in HUMAN_ACTION_REQUIRED.md.

Project map

riskpilot/        domain, market, strategy, risk, paper execution, audit, HTTP and MCP
riskpilot/static/ local HTML/CSS/JS demo
tests/            deterministic risk, data, concurrency, persistence, HTTP, MCP tests
agent/            host prompt, connection template and Agent OS handoff
scripts/          independent MCP SDK check and verification utilities
SUBMISSION/       English project copy, demo script, architecture and human checklist
evidence/         test logs, structured demo results, screenshots, integration status
START_DEMO.cmd    Windows launcher

Open source and submission

Original implementation, MIT license. Runtime: Python standard library (including bundled SQLite) and browser standards; zero third-party runtime packages or copied trading projects. Optional QA dependencies: Ruff (MIT), official Python MCP SDK (MIT) and its dependencies. See THIRD_PARTY.md. The project is independent and not endorsed by Binance.

Track A material is prepared under SUBMISSION/. Official entry requires the participant's own eligible account and public entry steps. The current source repository is local: no remote repository, X post, public demo video or contest submission has been created. Official rules and exact sources: COMPETITION_RESEARCH.md.

Limitations and disclaimer

RiskPilot is a hackathon prototype for local PAPER analysis. It does not model real fills, exits, liquidation, funding, slippage under stress, tax, custody or guaranteed stop execution. Market data and software can fail, and historical or simulated behavior does not predict future results.

This project is for technical demonstration and education. It is not financial advice, an offer to trade or a promise of profit. Use of Binance services remains subject to Binance terms, eligibility restrictions and the participant's own judgment.

Available Tools

3 tools
riskpilot_analyzeA
Idempotent

Fetch a validated market snapshot, propose or validate a structured trade, enforce hard guardrails and record an approved PAPER fill. Changes only a local simulated ledger. Never places a Binance order. Agent OS source remains unavailable until its bridge is bound locally.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptNo
sourceNodemo
symbolNoETHUSDT
proposalNo
scenarioNo
request_idYesReuse exactly this ID and inputs after a timeout. New ID for a new intent.

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the annotations, the description adds crucial behavioral context: 'Changes only a local simulated ledger' and 'Never places a Binance order.' It also discloses that the 'Agent OS source remains unavailable until its bridge is bound locally,' which is a significant operational constraint. These statements meaningfully expand on readOnlyHint=false and destructiveHint=false.

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?

Every sentence carries distinct information: core purpose, side effects, safety boundary, and availability constraint. The description is compact, front-loaded with the main capability, and contains no redundant phrasing.

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 nested objects, six parameters, multiple enums, and no output schema, the description does not explain how to construct a proposal, what scenario values mean, or what the tool returns. The only schema-level guidance is the request_id description about idempotency. This is insufficient for an agent to confidently call the tool.

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 only 17%, so the tool description must compensate, but it does not explain most parameters. It clarifies the source enum slightly by noting agent_os unavailability, but prompt, proposal, scenario, symbol, and their relationships remain largely unexplained. The main description gives high-level intent but not enough field-level semantics 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 a multi-step purpose: fetching a market snapshot, proposing or validating a structured trade, enforcing guardrails, and recording a paper fill. It also distinguishes itself from live trading by explicitly saying 'Never places a Binance order,' and the contrast with sibling tools riskpilot_policy and riskpilot_audit is evident from the focus on analysis and paper execution.

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 this is the tool for market analysis, trade proposal/validation, and paper-fill recording, and 'Never places a Binance order' signals it is not for live trading. However, it never explicitly tells the agent when to choose this over riskpilot_policy or riskpilot_audit, and gives no disqualifying conditions beyond the agent_os source being unavailable until locally bound.

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

riskpilot_auditA
Read-onlyIdempotent

Read and verify all local hash-linked audit events. Contains paper data only.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

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

The annotations already declare read-only, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds useful context about the data being 'local hash-linked' and 'paper data only', but the meaning of 'paper data' is unclear, and it does not disclose anything about verification semantics or output behavior. This is adequate but not rich.

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 short sentences with no filler. The core action and resource are front-loaded in the first sentence, and the second sentence adds a meaningful scope qualifier. Every word earns its place, apart from minor ambiguity in 'paper data'.

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?

For a parameterless, read-only tool with supportive annotations, the description is largely complete: it states what the tool operates on and its scope. The lack of an output schema means return values are not specified, but the simplicity of the tool and the strong annotations reduce the need for that detail. The main gap is the undefined 'paper data' term and lack of guidance on output shape.

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

Parameters4/5

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

There are zero parameters and schema description coverage is 100% vacuously, so the description has no burden to explain parameter details. The baseline of 4 applies here because there is nothing parameter-related that needs clarification.

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 uses the specific verb phrase 'Read and verify' with a clear resource, 'all local hash-linked audit events', which distinguishes it from the sibling tools dealing with policy and analysis. The scope is well-defined, though the phrase 'Contains paper data only' is ambiguous and may confuse an agent about what 'paper data' refers to.

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 gives clear context that this tool is for reading and verifying local hash-linked audit events, which makes its intended use apparent relative to the sibling tools. It does not explicitly state when not to use it or name alternatives, but the domain is specific enough that an agent can infer appropriate usage.

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

riskpilot_policyA
Read-onlyIdempotent

Read immutable risk limits and the paper-only execution boundary.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context with 'immutable' and 'paper-only execution boundary,' reinforcing that this tool only reads policy and does not affect live execution. This is consistent with the annotations.

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 sentence that front-loads the action and includes only informative phrases. Every word contributes meaning, and there is no filler or redundant restatement of the tool name.

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?

For a parameterless read-only tool with strong annotations, the description adequately identifies what is returned at a high level: risk limits and the execution boundary. It does not describe the exact output structure, and no output schema exists, but the scope is clear enough for correct invocation.

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

Parameters4/5

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

The tool has zero parameters and schema description coverage is 100%, so the description does not need to document parameter behavior. The baseline of 4 applies because there is no parameter burden to compensate for.

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 opens with a specific verb ('Read') and identifies two concrete resources: immutable risk limits and the paper-only execution boundary. This clearly distinguishes the tool as a policy accessor compared to the sibling tools, though it does not explicitly name those siblings or the conditions for choosing among them.

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?

There is no explicit 'use this when...' guidance or mention of alternatives. The phrasing implies this is the tool for reading risk policy data, but an agent receives no direct rule for choosing between riskpilot_policy and the siblings riskpilot_analyze or riskpilot_audit.

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.

  1. 3 tool updatesv0.1.0
    • First observedriskpilot_analyze
    • First observedriskpilot_audit
    • First observedriskpilot_policy
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a distinct responsibility: policy reads immutable limits, analyze executes validated paper trades under guardrails, and audit verifies hash-linked events. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent pattern of 'riskpilot_' prefix followed by a clear verb-like noun (policy, analyze, audit). The uniform lowercase and consistent structure make the set predictable.

Tool Count5/5

Three tools is well-scoped for a focused risk management and paper trading server. Each tool addresses a core function—reading policies, executing validated paper trades, and auditing—without unnecessary bloat or missing essentials.

Completeness4/5

The tool set covers the primary lifecycle: policy reading, trade analysis/execution with hard guardrails, and audit verification. It is missing optional capabilities like manual ledger management or limit updates, but these are intentionally immutable or out of scope, so no critical gaps exist.

Maintenance

ActivityMaintained
ResponsivenessNo issues

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

Related MCP Servers

  • riskstate-mcp

    likidodefi
    A
    license
    A
    quality
    A
    maintenance
    Deterministic risk governance for crypto trading agents. 5-level policy engine with position sizing, leverage limits, and trade blocking. One tool: get_risk_policy. Supports BTC and ETH.
    1
    19
    1
    MIT

  • forge-agent-gate

    forgeorbital
    A
    license
    Not graded
    quality
    F
    maintenance
    Enables AI agents to execute prediction-market trades through a risk-control gateway that enforces signed mandates and generates proof trails for accountability.
    0
    MIT

  • agentrisk

    trycoin-ai
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides risk guardrails for AI trading agents by analyzing portfolio risk, checking trades against policies, and generating risk policies.
    2
    MIT

  • Guardian MCP

    Dozie2001
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to propose stock, ETF, and crypto trades through Alpaca paper trading while enforcing deterministic policy rules and recording every decision in an audit trail.
    11
    MIT

Latest Blog Posts

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/dushaorighthere/RiskPilot'

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