ต้นแบบ · รุ่นทดลอง: มีทุก server ในทะเบียนทางการ อัปเดตทุก 30 นาที รีวิวและบัญชีผู้ใช้จะมาในขั้นถัดไป
PopNx MCPที่รวม MCP สำหรับคนใช้ AI · อธิบายเป็นภาษาคน

Monerometrics

โดย nowi333รุ่น 0.5.2i★ –iรันบนคลาวด์
ชื่อใน registryio.github.nowi333/monerometrics

ติดตั้ง

ภาพรวม

คำอธิบายจากผู้ทำ (ภาษาอังกฤษตามต้นฉบับ)

Live Monero network metrics: reorgs, orphans, pool centralization and the Haveno order book.

สามเสาของ PopNx MCP

สามเรื่องนี้ไม่รวมเป็นคะแนนเดียว เพราะความเห็น การวัด และความนิยม เป็นคนละเรื่องกัน

ใช้ทำอะไรได้

ตัวนี้ยังไม่ได้เรียบเรียงเป็นภาษาไทย ด้านล่างคือข้อเท็จจริงที่เราอ่านจาก registry

  • การเชื่อมต่อ: รันบนคลาวด์
  • ช่องทาง (transport): Streamable HTTP
  • หมวด: อื่น ๆ

ติดตั้ง

เลือกโปรแกรม AI ที่คุณใช้ แล้วคัดลอกค่าตั้งไปวาง

ก่อนติดตั้ง

ต้องเตรียมก่อน

  • รันบนคลาวด์ไม่ต้องลงโปรแกรมเพิ่ม ต่อผ่านอินเทอร์เน็ตได้เลย

คุณใช้แอปไหน

เลือกแอปด้านบน เราจำไว้ให้ ครั้งหน้าปุ่มจะขึ้นว่า “ติดตั้งลง …”

ใช้ได้ทั้ง Claude บนเว็บ แอปคอมพิวเตอร์ และมือถือ:

  1. เปิด Settings → Connectors
  2. กด Add custom connector
  3. วางที่อยู่ด้านล่างแล้วกด Add
  4. ถ้าให้ล็อกอิน ให้ล็อกอินกับผู้ทำ
SettingsConnectors1+ Add2https://…3
https://api.monerometrics.net/mcp

พิมพ์คำสั่งนี้ใน Terminal

claude mcp add --transport http monerometrics https://api.monerometrics.net/mcp

เปิดใน Cursor

หรือคัดลอกค่าตั้งเอง

วางในไฟล์ .cursor/mcp.json ของโปรเจกต์ หรือ ~/.cursor/mcp.json

{
  "mcpServers": {
    "monerometrics": {
      "url": "https://api.monerometrics.net/mcp"
    }
  }
}

เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง

เปิดใน VS Code

หรือคัดลอกค่าตั้งเอง

วางในไฟล์ .vscode/mcp.json ของโปรเจกต์

{
  "servers": {
    "monerometrics": {
      "type": "http",
      "url": "https://api.monerometrics.net/mcp"
    }
  }
}

เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง

ChatGPT ต่อได้เฉพาะ server ที่อยู่บนอินเทอร์เน็ต:

  1. เปิด ChatGPT บนเว็บ → Settings → Connectors (Apps)
  2. กด Create หรือ Add (บางแพ็กเกจต้องเปิด Developer mode ใน Advanced ก่อน)
  3. วางที่อยู่ด้านล่าง ตั้งชื่อ แล้วบันทึก
  4. ถ้าให้ล็อกอิน ให้ล็อกอินกับผู้ทำ
SettingsConnectors1+ Create2https://…3
https://api.monerometrics.net/mcp

ชื่อเมนูอาจต่างกันเล็กน้อยตามแพ็กเกจและรุ่นของแอป

ตัวเลือกเก็บในคุกกี้บนเครื่องนี้ ไม่ต้องมีบัญชี

ค่าตั้งนี้สร้างจากข้อมูลใน registry ของผู้ทำ ถ้าไม่ตรงกับ README ให้เชื่อ README

ทำอะไรได้บ้าง

ชื่อและคำอธิบายเครื่องมือตามที่ server ตอบมาเมื่อ 6 พ.ย. 2569 ผู้ทำเป็นคนเขียน ไม่ใช่เรา แสดงเป็นข้อความล้วน

  • network_info

    Current Monero network state: latest indexed height, difficulty, network hashrate and mempool size.

  • price

    Current Monero (XMR) price: centralized spot plus both sides of the Haveno peer-to-peer book. Returns the best offer and the amount-weighted average on each side, resting depth, offer counts, and round_trip_cost_pct: the cost of buying XMR and selling it straight back, which is f

  • haveno_book

    The live Haveno XMR/USD order book, both sides, priced against centralized spot. Each price level carries its cumulative depth, offer count, payment methods and a reversible flag. `asks` are makers selling XMR, so taking one means buying; `bids` are makers buying, so taking one m

  • haveno_premium

    Haveno peer-to-peer quotes against centralized spot over time, both sides. window in 24h,7d,30d,90d,1y. History starts on 24 August 2026, when recording began.

  • haveno_payment_methods

    Executed Haveno trades grouped by payment method, with the premium over spot. window in 30d,90d,180d,1y,all. currency in USD,EUR. The premium tracks how reversible and convenient the payment rail is, not privacy: every one of these trades is equally non-KYC. The reversible flag i

  • network_hashrate

    Network hashrate time series. window in 1h,24h,7d,30d,90d,1y,5y.

  • network_blocktime

    Block-time variance time series (seconds between blocks). window in 1h,24h,7d,30d,90d,1y,5y.

  • network_mempool

    Mempool size time series (number of pending transactions). window in 1h,24h,7d,30d,90d,1y,5y.

  • network_emission

    Block reward / emission time series (XMR per block). window in 1h,24h,7d,30d,90d,1y,5y.

  • reorgs

    Detected Monero chain reorganizations, most recent first, with fork point, depth and affected transactions.

  • reorg_stats

    Aggregate reorg statistics over windows: counts, average and maximum depth, affected transactions.

  • recent_orphans

    Most recent orphan blocks with their canonical counterpart at the same height, newest first. limit 1..50; window in 24h,48h,7d,30d,90d,180d,1y,all (default all, so the last N orphans are returned however old they are).

  • pool_distribution

    Mining-pool distribution over a window: block share per pool, largest-pool share and the Nakamoto coefficient (minimum pools controlling >50% of blocks). window in 1h,6h,24h,48h,7d.

  • pool_sources

    Reachability status of each mining-pool API used for block attribution.

  • chain_provenance

    How mining-pool attribution was established over a window: share proven by view key, claimed by pool API, inferred from coinbase, or unattributed. window in 1h,6h,24h,48h,7d.

  • get_block

    Full detail for one block by its 64-character block hash: height, previous hash, size, difficulty, reward, coinbase, transaction list and merge-mining tags.

  • search_block

    Find a block by height (a number) or by 64-character hash, anywhere in the chain down to the genesis block (height 0). Returns the block detail plus whether it is canonical or an orphan.

  • lookup_transaction

    Look up a transaction by its 64-character hash: whether it is in the mempool or mined, its block, confirmations, whether it is spendable yet, the pool that mined its block, and whether that height was ever contested by a reorg. No amounts, senders or recipients: the protocol encr

  • chain_fork_window

    Canonical chain plus any competing orphan blocks around a height. 'to' is the highest height in the window (defaults to the current tip); lower it to browse older history down to the genesis block. limit 10..500.

ผลตรวจเบื้องต้นi

เราตรวจจากข้อมูลที่ใครก็เปิดดูได้ ยังไม่ได้อ่านโค้ด ข้อที่ไม่เกี่ยวกับตัวนี้ไม่นับในตัวหาร · ตรวจเมื่อ 7 พ.ย. 2569

  • ✓ ผ่าน

    ตัวตนผู้ทำตรงกับ repo

    ชื่อใน registry ยืนยันด้วยบัญชี GitHub nowi333 ซึ่งเป็นเจ้าของ repo

  • … ยังไม่ตรวจ

    ยังมีคนดูแล

    ยังไม่ได้อ่านข้อมูล repo จาก GitHub

  • … ยังไม่ตรวจ

    มีสัญญาอนุญาต (license)

    ยังไม่ได้อ่านข้อมูล repo จาก GitHub

  • ✓ ผ่าน

    endpoint ตอบ

    ตอบกลับใน 589 ms (HTTP 200)

  • – ไม่เกี่ยว

    ล็อกอินแบบ OAuth

    ไม่ต้องล็อกอิน

  • ✓ ผ่าน

    คำอธิบายเครื่องมือไม่มีคำสั่งแอบแฝง

    อ่านคำอธิบายเครื่องมือ 19 ตัวแล้ว ไม่พบคำสั่งแอบแฝงถึง AI

เทียบกับตัวอื่นในหมวด อื่น ๆi

  • ดาวมากกว่า 0% ของอีก 32680 ตัวในหมวดนี้
  • ส่งรุ่นใหม่เข้า registry ล่าสุดกว่า 95% ของอีก 32680 ตัวในหมวดนี้
  • ผลตรวจเบื้องต้นดีกว่าหรือเท่ากับ 100% ของอีก 32680 ตัวในหมวดนี้

เทียบกับทุก server ที่ยังใช้งานในหมวดนี้ทั้งทะเบียน ดาวนับเฉพาะเมื่อผู้ลงทะเบียนเป็นเจ้าของ repo

คำถามที่พบบ่อย

Monerometrics ปลอดภัยไหม?

จากการตรวจเบื้องต้นของเรา ผ่าน 3 จาก 3 ข้อที่ตรวจได้ เรายังไม่ได้อ่านโค้ด ก่อนใส่กุญแจหรือ token ให้ดูว่า server ขอสิทธิ์อะไร และเลือกกุญแจที่ทำได้เท่าที่จำเป็น

ต้องใช้กุญแจหรือรหัสอะไรบ้าง?

registry ไม่ได้ระบุว่าต้องใช้กุญแจ แต่บางตัวจะขอให้ล็อกอินตอนใช้ครั้งแรก

ตัวนี้รันบนเครื่องหรือบนคลาวด์?

รันบนคลาวด์ของผู้ทำ ต่อผ่านอินเทอร์เน็ตได้เลย ไม่ต้องลงโปรแกรม แต่ข้อมูลที่ส่งให้จะผ่านเซิร์ฟเวอร์ของผู้ทำ

ยังมีคนดูแลอยู่ไหม?

repo บน GitHub มีการแก้โค้ดล่าสุด – และส่งรุ่นล่าสุด (0.5.2) เข้า registry เมื่อวาน

ใช้กับโปรแกรมไหนได้บ้าง?

โปรแกรมที่รองรับ MCP เช่น Claude Desktop, Claude Code, Cursor และ VS Code ตัวนี้ต่อผ่าน URL จึงใช้กับโปรแกรมที่รับ remote MCP ได้ เช่น ChatGPT ที่เปิดโหมดนักพัฒนา

มีตัวไหนใช้แทนได้บ้าง?

ในหมวดเดียวกันมี Spec Driven Development, Remote Desktop Commander, EmbeddedCI BenchPod

ตัวที่ใช้แทนได้

server หมวดเดียวกันจากผู้ทำคนอื่น เรียงตามดาว

อ่านการ์ด:★ ดาว GitHubiสามเสา: รีวิว · ผลตรวจ · การใช้งานiอัปเดต = วันที่ส่งรุ่นล่าสุดเข้า registryi

Spec Driven Development

โดย formulahendry

MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.

รันบนเครื่อง★ 440MITอัปเดต 14 เดือนที่ผ่านมา
ติดตั้ง

Remote Desktop Commander

โดย desktop-commander

Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.

รันบนคลาวด์★ 211อัปเดต เมื่อวานซืน
ติดตั้ง

EmbeddedCI BenchPod

โดย embeddedci-com

Drive a BenchPod hardware-in-the-loop bench: power, flash, UART, I2C, CAN, analog and logic.

รันบนเครื่องอัปเดต วันนี้
ติดตั้ง

README จากผู้ทำ

เปิดอ่าน README

ส่วนนี้คัดจาก repo ของผู้ทำตามต้นฉบับ PopNx MCP ไม่ได้ตรวจหรือรับรองเนื้อหา ตัด HTML รูปภาพ และสคริปต์ออกแล้ว ลิงก์จะพาออกนอกเว็บ

monerometrics

A reorg-aware observatory for the health of the Monero network: public dashboard + API.

monerometrics is community-funded. A Kuno campaign funds the next two years: hosting, FCMP++ readiness, free reorg alerts, open data export and a second node.

monerometrics measures and historizes the health of the Monero network: network hashrate, block time, mempool state, mining-pool distribution and, above all, chain reorganizations (reorgs) and orphan blocks, which most block explorers surface poorly.

The project was born from the August 2025 Qubic episode, during which a mining pool paying miners in its own token approached a majority of the network hashrate, then withheld blocks and released a longer private chain. On 14 September 2025 that produced an 18-block reorganization at height 3,499,659 that erased about 36 minutes of history, well past the 10 confirmations everyone treated as final: transactions thought settled were suddenly unconfirmed again. The public debate lacked reliable, accessible data to settle it. monerometrics fills that gap with a neutral, verifiable, reorg-aware observatory.

It is open-source and self-funded, with no ads and no tracking. The dashboard and the API are free and open, permanently: there is no paid tier, and there will not be one.

From a diploma project to a community tool. monerometrics V1 was built and defended as a

French professional IT-infrastructure project, and it earned the diploma. With that chapter

closed, the goal of V2 is to hand the project over to the Monero community.

  • Dashboard: monerometrics.net
  • Public API: api.monerometrics.net (OpenAPI documented)
  • MCP server: https://api.monerometrics.net/mcp (Streamable HTTP; in the MCP Registry)
  • Tor hidden service: 6wbhchvavey26lbtscl6w6qg76balycixtsklcggrsslyk4xah6sbbad.onion (dashboard + API, no Cloudflare, no IP exposure, see Access over Tor)

What it does

Dashboard, a React SPA in four sections, available in English, French and Spanish, light and dark themes, readable on a phone:

  • *Consensus and reorganizations*: a chain-fork visualizer that draws competing branches as a tree, reorg statistics by window up to everything recorded, and orphan history. Each block names its pool and how the attribution was established, and merge-mined blocks are flagged.
  • *Mining concentration*: pool distribution, the combined share of the two largest pools, and the evidence behind each attribution.
  • *Network state*: hashrate, block-time variance, mempool, emission, and a transaction fee estimator reading the node's four priority tiers live.
  • *Peer-to-peer market*: Haveno premium over spot on both sides of the book, live order-book depth, resting liquidity, and premium by payment method.
  • Transaction search: paste a transaction hash and get what Monero actually makes public about it, plus which pool mined its block and whether that height was ever contested by a reorg. The hash travels in a POST body, so it never lands in a URL.
  • Every time series is navigable: a range strip under each chart, drag to move through time, zoom, and statistics that follow the visible window rather than the whole series.

Public API: FastAPI, read-only JSON endpoints grouped by theme, documented via OpenAPI.

Reorg detection: a Python worker reads each block from a synced node, computes the indicators and detects reorganizations by re-checking a rolling window of recent blocks against the node, recording their real depth and the transactions they displaced.

Architecture

A visitor reaches the dashboard or API through Cloudflare, which terminates TLS and applies its edge protections, then forwards to a hardened edge server (nginx + ModSecurity WAF). The edge serves the static dashboard and reverse-proxies the API to the k3s node, where the application core runs: a Monero node, the indexer, PostgreSQL and the API.

A second, independent path exists: a Tor hidden service running on the edge, which bypasses Cloudflare entirely and serves both the dashboard and the API on a single origin, behind the same WAF.

flowchart LR

User(["Visitor"]) -->|HTTPS| CF["Cloudflare DNS · WAF · proxy"] CF -->|"HTTP/2 origin pull"| Edge Tor(["Tor visitor"]) -.->|"Tor network"| Onion subgraph HZ["Hetzner Cloud · private network 10.0.0.0/24"] Onion["tor daemon hidden service v3"] Edge["edge 10.0.0.20 nginx + ModSecurity WAF static dashboard"] Onion -.->|"127.0.0.1:8080"| Edge subgraph K3S["k3s 10.0.0.30 · no public ingress"] API["FastAPI"] Worker["Python worker (indexer)"] DB[("PostgreSQL 17")] Node["monerod 0.18 pruned"] end Edge -->|"api. proxy_pass"| API API --> DB Worker --> DB Worker -->|JSON-RPC| Node end Node <-->|"P2P sync"| Monero(["Monero network"]) API -.->|"XMR price (cached)"| Price(["CoinGecko · Kraken Haveno (RetoSwap)"])

Access over Tor

The dashboard is also published as a Tor v3 hidden service, giving a path to the data that does not depend on Cloudflare and does not expose the visitor's IP address:

6wbhchvavey26lbtscl6w6qg76balycixtsklcggrsslyk4xah6sbbad.onion
  • One origin, no leaks. The hidden service serves the dashboard on / and reverse-proxies the API under /api. The SPA detects an .onion host at runtime and switches to that relative path, so no browser request ever leaves the hidden service for the clearnet. One build serves both.
  • No TLS, on purpose. Tor already encrypts and authenticates end to end, and the .onion address *is* the service's public key.
  • Same WAF. The hidden-service vhost runs the same ModSecurity rules as the clearnet site, so Tor is not a way around the filtering.
  • Not reachable from the internet. The .onion vhost listens on 127.0.0.1:8080 only, so the Tor daemon is the sole thing that can reach it. Tor makes outbound connections only.
  • No logs. Every request arrives from 127.0.0.1, so access logging on this vhost would record nothing useful and is disabled.
  • Discoverable. The clearnet site advertises it with an Onion-Location header.
  • Rate limiting. Per-IP limiting is meaningless over Tor, so hidden-service traffic is tagged by nginx and isolated in its own bucket with a higher ceiling. The tagging header is stripped on the clearnet vhosts, so it cannot be forged from the internet.

Deployed by the tor Ansible role (config/ansible/roles/tor/).

Infrastructure

The platform runs on Hetzner Cloud (Nuremberg) as two Ubuntu 24.04 servers on a private network, each behind its own firewall. Neither exposes SSH to the internet: administration goes only over a Tailscale (WireGuard) mesh joined by both servers, and Grafana is reachable over Tailscale only. Backups are paused: the tooling (Restic, encrypted, see k8s/monerometrics/BACKUP-PRA.md) stays in the repository, but no scheduled backup runs today.

flowchart TB

Admin(["Administrator"]) -->|"SSH over Tailscale"| Mesh Internet(["Internet"]) -->|"80 / 443 via Cloudflare"| Edge subgraph HZ["Hetzner Cloud (nbg1) · 10.0.0.0/24"] Edge["edge 10.0.0.20 firewall: 80/443 from Cloudflare only"] K3s["k3s 10.0.0.30 + data volume firewall: no inbound (P2P 18080 only)"] Edge -->|"private network"| K3s end Mesh["Tailscale mesh (admin SSH · kubectl · Grafana)"] Mesh --- Edge Mesh --- K3s

ServerTypePublic exposureRole
edgeCX2380/443 from the internetnginx reverse proxy + ModSecurity WAF, serves the dashboard
k3sCX33 + 250 GB volumeMonero P2P onlyk3s cluster: monerod, worker, PostgreSQL, API, OpenBao

Key choices: per-server firewalls, no public SSH anywhere, a WAF on the only public web surface, a zero-trust admin mesh, and a k3s node exposing nothing but the Monero P2P port. A dedicated SSH bastion was dropped in October 2026: Tailscale already gave a zero-trust entry point, so the extra server only added cost. Tailscale's own SSH is disabled; plain OpenSSH with keys runs over the mesh, so access never depends on a browser re-validation. Both hops run HTTP/2 with the WAF active. Everything is Infrastructure-as-Code: Hetzner and Cloudflare resources via Terraform, server configuration and CIS-aligned hardening via Ansible, images published to GHCR. Supervision with Prometheus + Grafana, with alert rules on indexing, node sync, disk and failing workloads. The backup tooling (Restic) is kept but paused.

Secrets. The cluster is provisioned with OpenBao (a free fork of Vault) and the manifests carry no plaintext credential. OpenBao unseals itself on start (static seal, key held in a Kubernetes Secret created outside the repository); the workloads can also fall back to a Kubernetes Secret (postgres-credentials-fallback), so a sealed vault never takes the service down.

Running cost

Hetzner list prices, monthly cap, including 20 % VAT:

ItemMonthly
1 × CX23 (edge)~6.60 €
1 × CX33 (k3s)~10.20 €
2 × primary IPv4~1.20 €
250 GB volume~17.20 €
Total~35 € incl. VAT

Cloudflare, Let's Encrypt, Tailscale and GitHub Actions are on free tiers.

The volume is the item that moves, and the chain drives it, not indexing. The pruned Monero blockchain takes 106 GB; the entire indexed database, 3.77 M blocks and every time series, takes 3.1 GB, about 540 bytes per block, and grows by roughly 150 MB a year.

Growth is measured from the indexed data rather than estimated. Summing the recorded size of every canonical block gives 186.8 GB for the full chain, so this pruned node keeps a bit over half of Monero. The chain grew 22.18 GB over the last twelve full months, which is 12.35 GB a year on disk, steady across years (17.5 GB in 2022, 18.3 in 2023, 29.1 in 2024, 22.2 in 2025). The volume reached 94 % of 128 GB, so it was taken to 250 GB in October 2026, funded by the community (Kuno milestone 1). That leaves room well beyond the two years promised, which also absorbs the heavier transactions FCMP++ will bring. Removing the SSH bastion the same month paid for most of the difference.

How the indexer works

The worker (apps/worker/indexer.py) is the heart of the project. Every POLL_INTERVAL seconds it asks monerod for its state and, when the node is synced, runs three passes:

  1. Confirmation-window rescan (reorg detection). It re-fetches the headers of the last CONFIRMATION_WINDOW blocks (default 60) in one call and compares each hash to the canonical hash already stored. Any mismatch is a reorganization: the stored block is flagged orphan (is_canonical = false), the node's block becomes canonical, and a row is written to reorgs_detected with the real depth and the affected transaction count. This pass is what makes reorg detection work at all: forward-only indexing never revisits the past, so it would silently miss every reorg that rewrites already-indexed heights.

**The window is

ตัดมาแค่ช่วงต้น อ่านต่อใน repo

ถาม PopNx