BRS Signals is the science behind the ORE Signals daily plate - Bitcoin's market structure read live by three independent sensors (on-chain, off-chain, absence) every 30 seconds, with an auditable rejection funnel. Free tier, no card; $0.01/query via x402 (USDC, Solana or Base).
Scored across 5 tools
Most tools have clearly distinct purposes: audit record, decision context, market state, rejection funnel, and system status are all identifiable. The main ambiguity is between brs_market_state and brs_system_status, since both surface system health, though one is a bundled summary and the other is a detailed health/SLO read.
All tools follow the same brs_ prefix with descriptive, snake_case noun phrases. The naming is highly consistent and predictable across the entire set.
Five tools is well-scoped for a signal and diagnostics server. Each tool addresses a distinct part of the surface: public audit, paid context, market state, rejection analysis, and system health, with no obvious bloat.
The surface covers current posture, directional context, system health, audit history, and funnel analysis, which is strong for a read-oriented signal server. A minor gap is that there is no direct way to fetch a single emitted signal's full detail outside the track record, but agents can work around this.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tier | No | |
| as_of | Yes | |
| error | No | |
| status | Yes | |
| quality | No | |
| evidence | No | |
| disclaimer | No | |
| request_id | Yes | |
| schema_version | No | |
| freshness_seconds | No | |
| valid_for_seconds | No | |
| methodology_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that outcomes are fixed and never re-scored, which is important append-only/immutability behavior not fully captured by the readOnly/idempotent annotations. It also confirms no auth or payment is needed. No contradiction with the annotations is present.
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 contains redundant marketing-style phrases like 'public proof', 'don't trust us — query us', and 'not marketing' that do not add technical value. It is still relatively short, but some sentences could be tightened to improve signal-to-noise.
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?
Given the output schema is present, the description sufficiently covers the tool's purpose, the meaning of the limit parameter, and the key fields returned (timestamp, side, price, confidence, regime, zone, outcomes). It does not describe error cases or pagination, but these are not essential for a simple read-only list 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?
The only parameter, limit, is fully explained as 'Number of recent calls to return (1–500, default 100)', which directly adds meaning beyond the schema's min/max/default. This is exactly what an agent needs to correctly set the parameter.
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 it returns a track record of past calls and their outcomes, which distinguishes it from the sibling tools focused on market state, rejection funnel, and system status. Some phrasing like 'public proof' and 'keyless track record' is stylistic but does not obscure the core purpose.
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?
It explicitly frames this as the verification surface ('don't trust us — query us') and notes that no API key or payment is required, giving clear when-to-use guidance. It does not explicitly contrast with siblings, but the purpose is distinct enough that an agent can infer when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | ||
| chain | No | solana | |
| tx_signature | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tier | No | |
| as_of | Yes | |
| error | No | |
| status | Yes | |
| quality | No | |
| evidence | No | |
| disclaimer | No | |
| request_id | Yes | |
| schema_version | No | |
| freshness_seconds | No | |
| valid_for_seconds | No | |
| methodology_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds substantial behavioral context: WAIT is common and is context rather than instruction, confidence is normalized against reachable evidence, suppressed reads are explicitly shown rather than hidden, and payment retries are idempotent so the same tx_signature is never charged twice. These are meaningful operational traits not visible in annotations.
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 long, but the length is justified by the x402 payment protocol and the tool's nuanced outputs. It is front-loaded with the core result before explaining payment, and the Args section is cleanly separated. Minor redundancy with the idempotence hint exists, but the extra explanation is useful rather than wasteful.
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 description covers the return payload, the meaning of WAIT, confidence calibration, suppressed-read policy, the full payment flow, auth bypass with a Pro key, and spend caps. Given the tool's complexity and the presence of an output schema, an agent has enough information to call and interpret 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?
With 0% schema description coverage, the description fully compensates by explaining all three parameters: tx_signature is a signed x402 settlement tx and should be empty on first call, chain specifies the payment rail with allowed values and default, and ref is an optional attribution tag. This adds real semantics beyond the bare schema.
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 and resource: it returns the current directional posture (bullish / bearish / WAIT) along with regime, zone, reason, confidence, btc_price and timestamp. It clearly signals the decision-context purpose and differentiates it from a raw data dump, though it does not explicitly distinguish itself from sibling brs_market_state.
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 gives a precise call workflow: call without tx_signature, handle the PAYMENT_REQUIRED response by reading error.payment, pay on an advertised rail, then re-call with tx_signature and matching chain/ref. It also states when a Pro key bypasses payment and imposes spend-cap guidance, but it does not contrast this tool with its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | |
| tier | No | |
| as_of | Yes | |
| error | No | |
| status | Yes | |
| quality | No | |
| evidence | No | |
| disclaimer | No | |
| request_id | Yes | |
| schema_version | No | |
| freshness_seconds | No | |
| valid_for_seconds | No | |
| methodology_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds context about staleness and sensor down states, but does not explicitly reiterate side-effect-free operation; still, no contradiction exists.
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 mostly concise but repeats the idea of bundling three reads in both the intro and the return statement. This slight redundancy does not impede understanding, but a tighter version would be cleaner.
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 description fully covers the tool's purpose, what it returns, the importance of health checks, and the free-tier availability. It provides sufficient context for an agent to decide when and how to invoke it, without needing to inspect the output schema.
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?
There are zero parameters, and the description makes clear that no inputs are required. The coverage is complete, and the description effectively communicates that the tool is a bundled read with no configuration needed.
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 purpose as the canonical current market state, bundles three specific reads, and emphasizes it as the first call to make. It distinguishes itself from siblings by focusing on market state rather than audit, funnel, or system status.
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?
Explicitly instructs to 'Call this FIRST' and advises checking health before trusting a directional read, which is actionable guidance. The mention of bundling three public reads further clarifies typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | ||
| days | No | ||
| since | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tier | No | |
| as_of | Yes | |
| error | No | |
| status | Yes | |
| quality | No | |
| evidence | No | |
| disclaimer | No | |
| request_id | Yes | |
| schema_version | No | |
| freshness_seconds | No | |
| valid_for_seconds | No | |
| methodology_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent; description confirms a read-only query returning data. No side effects mentioned; consistent.
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?
Core purpose and parameters are stated efficiently. Some rhetorical framing (the quoted question) adds color but does not distract.
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?
Covers what, when, and how. Lists return fields. Lacks explicit output schema in the description but that is separate; for an agent understanding the tool, it is sufficient.
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?
Each parameter (day, days, since) is explained with defaults and precedence (ignored if day set). The schema lacks descriptions, so the description fully compensates.
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?
Clear verb and resource: returns cycle counts per gate. Directly tied to a specific question ('why no signal') and distinguishes from siblings by focusing on the rejection funnel.
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?
Explains when to use: to answer the 'prove it' question about rejections. Parameter descriptions clarify how to scope the query. Does not explicitly contrast with siblings but the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | |
| tier | No | |
| as_of | Yes | |
| error | No | |
| status | Yes | |
| quality | No | |
| evidence | No | |
| disclaimer | No | |
| request_id | Yes | |
| schema_version | No | |
| freshness_seconds | No | |
| valid_for_seconds | No | |
| methodology_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description goes further by disclosing keyless reads, the authoritative signals-sent count source, the CONFIGURED vs MEASURED SLO distinction, observation-window coverage, and explicit scope exclusions such as protocol conformance and operational health. This is rich behavioral context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but front-loads a one-line summary and uses bullets and delimiters to keep distinct concepts organized. Nearly every sentence adds decision-relevant detail; minor redundancy such as 'free' and 'keyless reads' appears twice, but the structure remains effective.
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?
For a zero-parameter, read-only status tool with an output schema, the description fully covers what to expect: health fields, counters, SLO semantics, coverage window, and scope limitations. An agent has enough context to decide when to call this tool and interpret its result 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?
The tool has zero parameters, so the schema provides no parameter semantics and the description does not need to compensate. The 100% schema coverage is vacuous but harmless. A baseline of 4 is appropriate since parameter documentation is not applicable.
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 opens with a specific resource ('Instrument health, SLO standing, and the sample size behind every reading') and then enumerates concrete blocks: component health, system counters, and SLO. It names the authoritative source and relates it to the funnel and landing page, making the tool's role easy to distinguish from 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 description gives an explicit trigger: 'Call this when any reading looks stale or absent, and to see exactly how small the sample behind a claim is.' It also warns that small samples cannot prove an edge. However, it does not explicitly name when not to use this tool or compare it against sibling tools by name, so it falls just short of a 5.
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.
brs_decision_contextbrs_audit_track_recordbrs_market_statebrs_rejection_funnelbrs_system_statusget_block_tipget_convergenceget_dashboardget_directional_biasget_fee_histogramget_funding_divergenceget_gamma_exposureget_mempool_feesget_mempool_statsget_regime_currentget_rejection_funnelget_signal_historyget_stablecoin_flowsget_system_countersget_system_healthquery_dbget_rejection_funnelget_block_tipget_convergenceget_dashboardget_directional_biasget_fee_histogramget_funding_divergenceget_gamma_exposureget_mempool_feesget_mempool_statsget_regime_currentget_signal_historyget_stablecoin_flowsget_system_countersget_system_healthquery_dbVerify official facts with Bitcoin-anchored proof. 180+ signals, x402 pay-per-call.
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Bitcoin and YouTube video intelligence for AI agents. Pay-per-call via x402 USDC on Base.
Verifiable crypto signals, recorded history and always-on monitoring for AI agents via x402 on Base.
Add one secure layer between your agents and this server.
