# io.github.nmxmxh/pronto-stream (remote · pronto.stream)

Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.

- Trust score: 66/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-22

## Components

- remote · `pronto.stream`: 66/100 (this document), [markdown](https://verifymcp.io/servers/nmxmxh-pronto-stream/pronto.md), [page](https://verifymcp.io/servers/nmxmxh-pronto-stream/pronto)

## Channel facts

- Endpoint: `https://pronto.stream/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.1.0-beta`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-22.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 13 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 70/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2990 tokens (~230/item across 13 items; 13 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 13/100
  - Stability observed for 4 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http nmxmxh-pronto-stream https://pronto.stream/mcp
```

### Codex

```toml
[mcp_servers.nmxmxh-pronto-stream]
url = "https://pronto.stream/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "nmxmxh-pronto-stream": {
      "type": "remote",
      "url": "https://pronto.stream/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add nmxmxh-pronto-stream --url https://pronto.stream/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  nmxmxh-pronto-stream:
    url: "https://pronto.stream/mcp"
```

### Other

```json
{
  "mcpServers": {
    "nmxmxh-pronto-stream": {
      "type": "http",
      "url": "https://pronto.stream/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-22 (score 66, +12)

- [functional improvement] Schema quality: unverified → excellent

### 2026-08-21 (score 54, 0)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “get_fused_signal” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: poor → unverified
- [cosmetic] “get_fused_signal” reworded the description of “product”

### 2026-08-20 (score 54, +1)

- [cosmetic] “get_fused_signal” reworded the description of “product”

### 2026-08-19 (score 53, +2)

- [functional improvement] Stability: unverified → 0.03
- [functional improvement] MCP protocol: fail → pass
- [functional] MCP protocol version: 2025-06-18 → 2025-11-25

### 2026-08-18 (score 51)

First indexed and scored.

## MCP tools (13)

### `get_billing_profile` (~107 tokens)

Report who you are resolved as and what your plan grants: the agent identity behind this call, the funded account it acts for, the plan, the per-minute call ceiling, the per-response row budget, and which indicator set you may compute. Returns a CWF BILL line, a CREDIT line when a metering balance exists, and a NOTE line naming your state and its remedy when you are not entitled — unauthenticated, or registered but not yet claimed by a funded account.

### `register_agent` (~214 tokens)

Create your own identity on pronto and receive an API key, with no human present. Send the key back as an Authorization header on later calls and you will be recognised across sessions.

Registering grants no plan. A new identity has exactly the limits an unauthenticated caller has; what raises them is being claimed by a funded account. The response includes a claim code and a URL — hand those to whoever holds the budget, and once they claim you, your calls resolve to their plan with no change on your side.

Supply an Ed25519 public key (base64) if you can keep the private half: it lets you rotate your own credential before it expires without anyone's help. Without one you cannot rotate, and you must register again when the key expires.

Input parameters:

- `label` (string): A name for this agent, for whoever reviews the account later.
- `public_key` (string): Base64-encoded Ed25519 public key, 32 bytes. Optional, but without it you cannot rotate your own credential.

### `get_plans` (~71 tokens)

List the plans, what each costs, and what each raises — the call ceiling, the row budget, and whether the commercial indicator set is included. Machine-readable, so you can decide whether a refusal is worth escalating to your principal instead of parsing a pricing page. Returns one CWF PLAN line per plan.

### `get_latest_signals` (~137 tokens)

Fetch the most recent live signals from the wire in token-efficient CWF format, optionally filtered to one collection.

Input parameters:

- `collection` (string): Signal collection to filter by, e.g. climate, sentiment, security, health, cosmic, energy, macro, market, crypto, knowledge, prediction, logistics. Omit for all collections.
- `limit` (number): Maximum number of signals to return (default 20, max 100)
- `relate` (boolean): Also return the link graph over the rows in this response, as REL lines, so repeats of one story can be collapsed without a second call. Off by default.

### `get_signal` (~208 tokens)

Fetch one signal by its id, when you already know which one you want. Every other read tool returns a set and bounds it, so re-reading a single row through them means re-running a query and hoping the row survives the row budget a second time; this returns that row and nothing else.

Takes either the full correlation id or the short handle in column 2 of any CWF row — cite the handle, pass it back here. The live window turns over in about two minutes, so a signal read several calls ago may have aged out; the error says which of the two happened rather than leaving you to look for a typo. To find signals rather than re-read one, use search_signals or scope_signals; to reach the ones about the same subject, use get_related_signals.

Input parameters:

- `correlation_id` (string, required): Id of the signal to fetch. Accepts either the full correlation id or the short handle in column 2 of any CWF v3 row.

### `search_signals` (~324 tokens)

Find signals by the words in them. Use this when you are looking for a subject — a storm name, a company, a phrase a report would print — and cannot name it as a category. When you can name it as a category instead (a country, a domain, a severity), scope_signals selects that slice exactly and does not depend on any particular word appearing; this tool ranks by word overlap and will miss a matching signal that phrased it differently.

The search covers places, observations, summaries, identifiers, and the country and topic facets of each signal, so "Japan" reaches a Japanese-language article that never writes the word.

A signal is returned when it contains the words you asked for. Inflections count: "flood" reaches "flooding" and "quake" reaches "quakes". Synonyms do not: the match is lexical, not semantic, so "car" does not reach "automobile" and "downturn" does not reach "recession". Use the words the source would have used.

Results are ranked by how much of your query each signal contains, exact phrase matches first. When nothing contains your terms the tool returns an error rather than the closest available rows; an empty result means the wire does not carry it, not that the search gave up. Returns CWF lines.

Input parameters:

- `limit` (number): Maximum matches to return (default 10, max 50)
- `query` (string, required): Keywords describing the anomaly or topic, e.g. 'earthquake pacific' or 'solar flare'

### `list_fusion_products` (~219 tokens)

List every derived intelligence product pronto can compute, with the published index or model each one implements, the signal collections it consumes, and whether it needs a plan. Read this to find out whether pronto computes the thing you need, then call get_fused_signal to actually compute it.

The two tools answer different questions and the difference matters. This one states the catalogue, reads no signals, and returns the same answer on a wire that is still warming up. get_fused_signal states what the current window can support, so a product missing from its output means the inputs are not flowing right now, not that the product does not exist.

Each row states its attribution: "published" is a faithful implementation of an external, citable index, "composed" is authoritative published inputs combined by a rule that is pronto's own and disclosed in the method. Rows marked plan:team are the commercial macro and energy models; when your plan does not include them a NOTE line names them, so a gated product is never mistaken for a missing one.

### `get_fused_signal` (~277 tokens)

Compute derived intelligence products from the live wire. Each result states the method it implements and cites the signals it was computed from; a source row with no citation is labelled as such.

Pick one from the `product` enum, or omit it for everything the current window supports. A product absent from the output has no live inputs right now — list_fusion_products states the whole catalogue and does not depend on the window.

Cross-source products exist only because independent publishers are time-aligned on one wire; no upstream API emits them. seismic_solution_consensus is the sharpest case: several national agencies locate one earthquake and it reports how far apart their solutions are, in magnitude, depth and true three-dimensional hypocentre. Read it before acting on any single magnitude — agencies routinely differ by half a unit while an event is still being located, which is a factor of five in energy.

recession_risk_12m and sahm_recession_indicator disagree on purpose: the first forecasts, the second says a downturn has probably already begun. Read both.

Some indicators are included from the Team plan. A response that withheld one says so on a NOTE line naming what and why, so an absence is never mistaken for a quiet wire.

Input parameters:

- `product` (string): One product to compute. Omit for every product the current window supports.

### `scope_signals` (~267 tokens)

Select a slice of the live wire by facet tags — the structured metadata each signal carries, not the words in its text. Use this when you can name the slice you want: every high-severity climate signal in Japan, everything from one provider, everything in one language. It returns the whole slice whatever words the signals happen to use, which is what separates it from search_signals; reach for search when you have a subject word and no category to name.

Facets cover language, country, region, domain, topic, severity, provider, coverage, and place. Facets that share a key combine with OR. Facets with different keys combine with AND. The filter "country:JP,country:CL domain:climate" selects Japan or Chile, and climate. A locale filter alone cannot answer this question.

Input parameters:

- `filter` (string): Facet expression, e.g. "country:JP domain:climate severity:high". Call list_facets to see live values.
- `limit` (number): Maximum signals to return (default 25, max 200)
- `relate` (boolean): Also return the link graph over the rows in this response, as REL lines, so repeats of one story can be collapsed without a second call. Off by default.

### `get_facet_manifest` (~163 tokens)

Read the shape of the wire in one small response: a two-level tree of domain and the topics under it, each with a signal count, ranked so the busiest lead. This is the map to read first — read it once, choose a scope offline, then make one precise call to scope_signals or search_signals instead of guessing a filter.

It covers two facet keys only, domain and topic, and truncates the topic tail under each domain, so it stays short enough to read in full. When you need the rest of the vocabulary — the languages, countries, providers, severities, coverages and place ids you can also filter by, exhaustively and with counts — call list_facets instead. The manifest states structure, not signal content.

### `list_facets` (~169 tokens)

List the full filter vocabulary: every facet value currently on the wire, across every key — lang, country, region, domain, topic, severity, provider, coverage and place — as one flat list with a signal count each, and a human-readable label for place ids. Every value it returns is a value scope_signals will accept right now.

This is the exhaustive listing and it is long, running to a hundred-odd values on a busy wire. If all you need is to pick a domain and a topic, get_facet_manifest answers that in a fraction of the tokens; come here when you need a value the manifest does not carry, or the counts behind one. Place facets are gazetteer ids; filter them by name with scope_signals rather than by the raw id.

### `get_related_signals` (~150 tokens)

Follow the link graph from one signal to other signals about the same subject. Each link states the reason the link exists. An echo link marks the same story from several sources. A related link marks a similar signal in the same domain. A cross-domain link joins two domains. For example, a seismic record and a news headline name the same place. The two signals arrive from unrelated providers and meet only on the wire.

Input parameters:

- `correlation_id` (string, required): Correlation id of the signal to start from. Accepts either the full id or the short handle in column 2 of any CWF v3 row.
- `limit` (number): Maximum neighbours (default 5, max 10)

### `list_data_sources` (~65 tokens)

List the data-source endpoints feeding the wire, with provider, signal type, country, cadence, and license. Returns one SRC line per source.

Input parameters:

- `signal_type` (string): Filter by signal type, e.g. climate, security, health. Omit for all sources.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/nmxmxh-pronto-stream/pronto#diagnostics

## Score history

- 2026-08-22: 66
- 2026-08-21: 54
- 2026-08-20: 54
- 2026-08-19: 53
- 2026-08-18: 51

## Links

- Remote endpoint: https://pronto.stream/mcp
- Repository: https://github.com/nmxmxh/pronto_v1
- Changelog RSS feed: https://verifymcp.io/servers/nmxmxh-pronto-stream/pronto.xml
- Changelog JSON feed: https://verifymcp.io/servers/nmxmxh-pronto-stream/pronto.json
- HTML version of this page: https://verifymcp.io/servers/nmxmxh-pronto-stream/pronto