solfleet
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fleet_statusB | Health of every node in the fleet, grouped by cluster: reachability, getHealth, version, slot lag vs the cluster reference RPC, and delinquency/stake for voting validators. |
| node_detailC | Full probe result for a single node by name, including its cluster's reference data. |
| version_driftA | Compare each node's solana-core version against its cluster's reference RPC version. Drift does not always mean outdated (the reference may itself lag a release), but it flags what to look at. |
| vote_statusB | Voting health of a validator that a plain RPC check can't show: in the vote set, voting vs delinquent, epoch credits, last vote, root slot, commission, activated stake, identity SOL balance (+ low-balance warning; a validator pays vote fees every slot), catch-up, and the next leader window. Read-only. |
| leader_scheduleA | Upcoming leader slots for a validator and whether it's safe to restart now (no leader slot within min_window_minutes). Read-only; helps plan restarts/upgrades without skipping your own slots. |
| validateA | Read-only readiness check of the whole fleet: per-node SSH/service/ binary/disk/RPC, per-builder cores/RAM/disk/toolchain, and DNS credential presence. Returns pass/warn/fail per check; ok is true only when nothing failed. Changes nothing. |
| plan_node_upgradeA | Dry-run plan for upgrading one node in place to target_version, using artifacts from the cluster's dedicated builder. Read-only: produces the ordered steps and policy preflight, changes nothing. |
| restartA | Restart a node and wait for catch-up. RPC nodes cycle via systemctl; voting validators use a leader-aware safe-exit so they don't skip slots. Defaults to a dry-run that returns the plan and policy preflight. Pass confirm=true to actually cycle the service; gated by policy and recorded in the audit log. Never touches keys. |
| bootstrap_builder_hostA | Install the build toolchain + deps (Rust, protoc, libclang-dev, ...) on a builder host so it can compile agave from source. Dry-run by default; confirm=true runs it (idempotent) and records to the audit log. Run once per builder before the first upgrade/provision. |
| provisionA | Bring up a bare host into a serving node: preflight, user, system tuning, disks, software install (via the builder), systemd unit, key check, start + catch-up. |
| upgradeA | Upgrade one node in place to target_version: build on the cluster's builder, distribute + checksum-verify the agave + geyser artifact set, swap atomically, cycle (leader-aware for validators), and verify. |
| dns_pool_statusB | Current members of each managed DNS pool, mapped back to node names. Read-only. |
| dns_pool_ejectA | Manually pull a node from its DNS pool(s). Dry-run unless confirm=true. Refuses to empty a pool (last-member protection). Audited. |
| dns_pool_restoreA | Manually add a node back to its DNS pool(s). Dry-run unless confirm=true. Audited. |
| audit_logA | Recent audit entries (every dry-run and execute), newest first. Optionally filtered to one node. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Each tool targets a distinct operation (e.g., provisioning, upgrading, DNS management, health checks) with no overlapping purposes. Even related tools like plan_node_upgrade and upgrade are clearly separated by dry-run vs execution.
All names use snake_case and are descriptive, but they mix verb-initial (e.g., bootstrap_builder_host, plan_node_upgrade) and noun-initial patterns (e.g., dns_pool_eject, fleet_status). This minor inconsistency does not hinder readability.
15 tools is well-scoped for a fleet management server covering provisioning, upgrades, DNS, monitoring, and auditing. Each tool serves a clear purpose without redundancy.
Core lifecycle operations (provision, upgrade, restart, DNS management) are covered, but a decommission tool is missing. Minor gap considering the server's scope.