list_metricsLABSCO SUMMARY
Validator telemetry, explained and then turned into a dashboard.
Solana emits far more metrics than anyone remembers the meaning of; the categorisation and the per-metric explanation are what make the raw list usable. Dashboards land as JSON files on disk, so they go into Grafana through import rather than through an API connection.
What it is
A Node.js MCP server that reads Solana metrics from the sol_metrics InfluxDB database, explains them, and writes importable Grafana dashboard JSON.
What you get
- Every metric in the sol_metrics database listed, so you can see what is being collected before designing a panel
- Metrics sorted into Consensus, Network, Banking, Accounts, RPC, Performance and Jito/MEV groups
- An explanation of what a given metric measures and why it is worth watching
- Grafana dashboards written to the grafana/ folder as importable JSON, with timestamped backups kept
- Seven prebuilt dashboards covering epoch rewards and voting, gossip and retransmit, transaction processing and priority fees, account database and cache, RPC and subscriptions, host CPU/memory/disk, and Jito block engine and bundles
- Metric definitions located in the Solana Rust codebase when the name alone is not enough
- Both InfluxDB v1 and v2 supported
Requirements
A reachable InfluxDB holding sol_metrics: its address, an access token, the org and bucket it sits in, and which InfluxDB version you are on, all set as environment variables. Node with npm for the build.
Setup effort
Build from source
USE CASES
01
Seeing what your validator is even measuring
List everything in sol_metrics and read it grouped by consensus, network, banking, accounts, RPC, performance and Jito rather than as one flat list.
02
Understanding a metric before you alert on it
Ask what a specific metric measures and why it matters, instead of inferring meaning from its name.
03
Standing up monitoring quickly
Generate the dashboard JSON for the area you care about and import it into Grafana.
04
Investigating MEV and bundle behaviour
Work from the Jito/MEV grouping — block engine, bundle processing, relayer — rather than picking metrics one at a time.
05
Tracing a metric back to the code that emits it
Locate its definition in the Solana Rust codebase when the description is not specific enough to act on.
4 tools
Listed in project docs. Your client may show a different list.
analyze_metricsgenerate_dashboardsearch_rust_codeBEFORE YOU INSTALL
What to know first
Tools you get
4 tools named in the project's documentation.
Requires
- Node.js with npm
- A reachable InfluxDB (v1 or v2) holding the sol_metrics data
- INFLUX_URL, INFLUX_TOKEN, INFLUX_ORG, INFLUX_BUCKET and INFLUX_VERSION in your environment
INSTALLATION
Connect your client
You clone and build this one yourself.
Server setup
TERMINAL
git clone https://github.com/wcampbellgalaxy/solana-metrics-mcp-server
cd solana-metrics-mcp-server
npm install
npm run buildMCP Clients
Claude Desktop
CLAUDE DESKTOP · JSON
{
"mcpServers": {
"solana-metrics": {
"command": "node",
"args": [
"<YOUR_PATH_TO_SOLANA_METRICS_MCP_SERVER>/build/index.js"
],
"env": {
"INFLUX_URL": "http://<YOUR_INFLUXDB_SERVER>:8086",
"INFLUX_TOKEN": "<YOUR_INFLUX_TOKEN>",
"INFLUX_ORG": "<YOUR_INFLUX_ORG>",
"INFLUX_BUCKET": "sol_metrics",
"INFLUX_VERSION": "v1"
}
}
}
}The INFLUX_* values are your InfluxDB address, token, org and bucket; INFLUX_VERSION is "v1" or "v2". <YOUR_PATH_TO_SOLANA_METRICS_MCP_SERVER> is the folder you cloned and built.
