MCP.so
ログイン

BRS Signals MCP Server

@brssignals

基本情報

トランスポート

streamable-http

認証方式

提供元の文書を確認

カテゴリ

金融とコマース

作者

brssignals

投稿者

BRS Signals

BRS Signals MCP Server について

Bitcoin market-signal research using mempool, funding and flow observations with a public rejection funnel.

接続情報

https://brs-signals.com/mcp

セットアップ

claude mcp add brs-signals --transport http https://brs-signals.com/mcp

BRS Signals MCP Server のツール

5

Canonical current market posture. Call this FIRST. Bundles the three public, keyless reads into one call: - regime structure (which game the market is playing) - three-eye convergence (how much the sensors agree) - system health (whether the instrument is operational) Returns market_structure, convergence, and system_health together with their as_of timestamps. If any read is stale or a sensor is down, that changes what every other answer means — check health before trusting a directional read. Free tier, no API key required.

Directional market context with evidence and caveats (Pro tier). Returns the current posture (bullish / bearish / WAIT) with the regime and zone it was read in, the reason, confidence, btc_price and timestamp. WAIT is the most common answer and means no edge is visible — it is context, not an instruction. Confidence is normalised against how much evidence was reachable: sent signals typically land 0.30–0.50, so compare against that distribution, not 1.0. Suppressed reads are shown (suppressed=true), never hidden. Payment (BRS-017): this is the metered Pro posture and is payable per-call via x402. Call it with no tx_signature first — if the result is status='error' with error.code='PAYMENT_REQUIRED', inspect error.payment: that carries the exact amount, currency, asset, networks, recipient, expiry and request_digest needed to build the settlement. Pay on an advertised rail, then re-call with the tx_signature (and matching chain/ref) to get the metered result. Retries are idempotent — the same tx_signature is never charged twice. A Pro key (BRS_API_KEY or a per-client key) skips payment entirely. Spend caps: max 3 re-calls per request; enforce your own max-per-call/max-per-day policy against error.payment before paying. Args: tx_signature: The signed x402 settlement tx from a prior payment. Empty on first call (you will receive the challenge instead). chain: Rail you paid on — "solana" or "base". Default "solana". ref: Optional attribution tag carried through to the payment ledger.

The public proof: every call BRS has made and what Bitcoin did next. Returns the keyless track record — each entry carries timestamp, side (bullish/bearish), price at call time, confidence, regime, zone, and resolved +4h/+24h outcomes where the paper-trading log has them (return %, worst drawdown, best upside). Outcomes are fixed once written and never re-scored, so this is auditable evidence, not marketing. This is the "don't trust us — query us" surface: no API key and no payment are required. Use it to verify the system's real silence before trusting any signal. Args: limit: Number of recent calls to return (1–500, default 100).

Why no signal? The pipeline funnel in one glance (public). Every cycle that does not become a signal died at a specific gate. This returns the cycle count at each gate in order, so an agent can draw a survival funnel and see where reads are rejected — the direct answer to "BRS rejects almost everything, prove it." Args: day: A specific UTC day (YYYY-MM-DD). Empty = today. days: Sum over the last N UTC days (e.g. 30). Ignored if day set. since: "launch" for every day on record, or a YYYY-MM-DD start date. Returns: cycles_total, emitted, signals_sent, per-gate counts, gate_order.

Instrument health, SLO standing, and the sample size behind every reading (free). Bundles two keyless reads plus a measured SLO block: - component health: collector/engine status and last-good timestamps - system counters: signals sent, data points collected, days collecting. "Signals sent" is the authoritative all-time count from decoder_decision_records — the same figure the funnel and the landing page show, so every surface agrees. - slo: status; CONFIGURED (compliance_pct + scope note) vs MEASURED (uptime_24h_pct, boot-epoch uptime, latency_ms) kept apart; an observation_window discloses the 24h coverage and flags insufficient history explicitly. compliance_pct scope is "registry metadata checks" only (see compliance_note) — NOT protocol conformance (BRS-021f: this server serves 2026-07-28 modern + legacy ≤ 2025-11-25) and NOT operational health (the measured fields above) Call this when any reading looks stale or absent, and to see exactly how small the sample behind a claim is. Small samples cannot prove an edge.

概要

What is BRS Signals?

Bitcoin market-signal research using mempool, funding and flow observations with a public rejection funnel.

How to use BRS Signals?

Add https://brs-signals.com/mcp as a remote HTTP connection in an MCP-compatible client.

Key features

  • brs_market_state — Canonical current market posture. Call this FIRST. Bundles the three public, keyless reads
  • brs_decision_context — Directional market context with evidence and caveats (Pro tier). Returns the current postu
  • brs_audit_track_record — The public proof: every call BRS has made and what Bitcoin did next. Returns the keyless t
  • brs_rejection_funnel — Why no signal? The pipeline funnel in one glance (public). Every cycle that does not becom

Documentation

Repository · Website

よくある質問

1

BRS Signals のリモート MCP サーバーとは何ですか?

BRS Signals のリモート MCP サーバーは、https://brs-signals.com/mcp にホストされた Model Context Protocol エンドポイントです。AI アシスタントはローカルに何もインストール・実行することなく接続できます。

2

BRS Signals の MCP サーバーにはどう接続しますか?

エンドポイント https://brs-signals.com/mcp を Claude Code、Cursor、VS Code など任意の MCP 対応クライアントに追加してください。このページのセットアップ手順で各クライアントを一度に設定できます。

3

BRS Signals の MCP サーバーは認証が必要ですか?

この掲載では BRS Signals の認証要件がまだ確認されていません。接続前に提供元のドキュメントをご確認ください。

4

BRS Signals の MCP サーバーはどのトランスポートを使用しますか?

BRS Signals は streamable-http エンドポイントを公開しており、これはリモート MCP サーバーで広く使われ、主要な MCP クライアントがサポートするトランスポートです。

コメント