DEV Community: Sanjeev Kumar

There are MCP servers for building on Solana. I built one for operating the validators underneath.

Sanjeev Kumar — Fri, 26 Jun 2026 21:10:36 +0000

There are plenty of MCP servers for building on Solana: querying chain data, sending transactions, talking to programs. They all assume the nodes underneath are simply there. But someone has to run those nodes, and for independent operators that someone is doing it by hand. That is the part I spend the most time stressed about.

agave v3.0 dropped prebuilt validator binaries, so now I build from source. Restart a voting validator during its own leader slots and it skips blocks. Remove the last record from a DNS pool and the endpoint goes dark. Push a binary whose geyser plugin does not match and the node will not start. None of these have an undo button.

MCP made me want to hand that work to an agent. The hard part was never wiring up tools. It was making sure an agent operating a live validator could not break it. So I built solfleet, an MCP server (and CLI) for operating independent Solana validators and RPC nodes, designed so an agent can drive it without being able to cause an outage by accident.

What it does

solfleet describes a fleet across devnet, testnet, and mainnet in one config file, and exposes a set of operations: Solana-aware status, in-place upgrades that build agave from source and distribute it, voting-validator provisioning, and health-driven DNS failover. The read operations are open. Every operation that changes a node is dry-run by default, checked against a policy, written to an audit log, and never goes near a keypair.

What it looks like

Status is the first place the design shows up. A generic health check sees HTTP 200 and calls it healthy. A Solana node can be 500 slots behind and still return 200, so the status is Solana-aware: slot lag against the cluster head, delinquency, and version drift.

CLUSTER  NODE   ROLE  HEALTH  VERSION     SLOT LAG  VOTE
devnet   rpc-1  rpc   ok      4.1.0-rc.1  0         -
devnet   rpc-2  rpc   ok      4.1.0-rc.1  0         -

The more important behavior is what happens when you ask for a change. Asking to upgrade a node does not upgrade it. It returns the ordered plan and the gate decision:

{
  "decision": {
    "operation": "upgrade",
    "node": "rpc-1",
    "mode": "dry-run",
    "allowed": true,
    "plan": [
      "on builder 'build-1': build agave 4.1.0 from source",
      "distribute artifact set to rpc-1; checksum-verify each (abort on mismatch)",
      "stop solana-validator, swap, start",
      "swap /usr/local/bin/agave-validator + geyser .so + version marker atomically",
      "wait until healthy + caught up to https://api.devnet.solana.com",
      "verify reported version == 4.1.0; record before/after"
    ],
    "reasons": ["dry-run: preflight checks pass; pass confirm=true to execute"]
  }
}

To actually run it, the call needs confirm=true. A model that forgets to confirm, or decides it already did, produces a plan, not an outage.

Why MCP, not a CLI

I wrote the CLI first, and it still exists. But the reason I reached for MCP is that the work I want help with is conversational and judgment-heavy, not scripted. "Is anything in the fleet behind?" "Plan an upgrade of the Frankfurt RPC to 4.1.0 and tell me what it would do." "One node looks delinquent, what does its vote account show?" Those are questions, and an agent that can call fleet_status, vote_status, and plan_node_upgrade and reason over the results is genuinely useful in a way a flag-heavy CLI is not.

The CLI is the right tool for cron and CI. MCP is the right tool for the operator sitting with the fleet at 2am trying to understand what is actually wrong. solfleet ships both over the same core.

Architecture and deployment

solfleet runs on the operator's machine (or a small VM), not on the nodes. It talks to the fleet over JSON-RPC to read and over SSH to act. Upgrades are build-and-distribute: a dedicated builder host compiles agave together with the ABI-matched Yellowstone geyser plugin (the .so is locked to the agave version, so the two move in lockstep or the node bricks), caches the artifact set, and the executor distributes it. Each target re-computes the sha256 and compares it to the builder before any swap. Only verified files are swapped, atomically, then the node is cycled and watched until it catches up.

The MCP server is stdio, so it runs locally next to your keys and config. There is no hosted endpoint holding your fleet's access.

Why this is differentiated

The interesting part is not that it manages Solana nodes. It is the set of rules that make it safe to put in front of an agent, and those rules are the whole point:

Dry-run by default. Every mutation returns its plan and preflight and changes nothing without confirm=true. This single default removes most of the risk of pointing an agent at the tool.
A policy gate that runs in both modes. Per-cluster allowed versions, a disk-free floor, and a minimum leader-free window for voting validators. The gate runs in dry-run too, so the preview predicts whether the real run would be allowed. There is no "looked fine in dry-run, failed on execute" gap.
It never touches keys. solfleet does not read, move, or generate identity or vote keypairs. Voting-validator identity failover is deliberately out of scope, because automating it invites double-signing.
Everything is audited. Every call, dry-run or execute, goes to a SQLite log: operation, node, decision, reasons.
The domain knowledge is in the safety, not just the status. Restarts are leader-aware. The failover loop refuses to ever empty a pool, even if every member is failing, because serving a degraded node beats serving NXDOMAIN.

That last category is what a generic "run commands over SSH" MCP server cannot give you. The safety has to understand validators to be safe.

What's next

The read path, upgrades, provisioning, and the DNS driver are tested live on a disposable devnet node and a real Cloudflare zone. The autonomous failover loop and the Route53 driver are still unit-tested only, and an HTTP transport (for a team sharing one server over a tailnet) is the next milestone. The README has an honest status breakdown of what is proven live versus not.

It is open source under Apache-2.0, on PyPI, and in the official MCP registry:

pipx install solfleet

Source and design notes: github.com/sanjeevkkansal/solfleet.

If you operate your own validators, I would like to hear how you handle upgrades and failover today, and what a tool like this would have to do before you would let an agent near it. And if you have a story about a validator upgrade that went sideways, those are the cases I want to design against.

What one week of new Ethereum contracts looks like through a scam-detection lens

Sanjeev Kumar — Sat, 06 Jun 2026 06:46:02 +0000

I pulled every top-level contract deployed on Ethereum mainnet in the week ending 2026-04-10. There were 8,257 of them. I enriched each one with its deployed bytecode, verified Solidity source where available, and its deployer's first-tx history. Then I scored each contract against five rule families (contract name, bytecode shape, source patterns, deployer reputation, known-drainer hashes) and used Claude Opus 4.7 to write structured walkthroughs for the top scores.

192 contracts came back as high-confidence scam patterns. All 192 are one specific scam family: "FlashUSDT" and its liquidity-bot variant, a fake-Tether template used in off-chain social engineering. Manual review of a stratified sample confirmed 100% precision in the very-high score band. Cross-referencing against ScamSniffer's public blacklist found zero overlap, because public scam lists track established drainer infrastructure, not freshly-deployed scam tokens. The lead time is the story.

Method

The pipeline is four stages. Each stage writes JSON to disk so the run is resumable and the dataset is inspectable end-to-end.

Ingest. Block-by-block scan of mainnet blocks 24,795,371 to 24,845,605 (seven days). For every transaction with to == null, record the deployed contract address, deployer, gas used, and init bytecode. ~17 minutes against QuickNode at concurrency 10. The v0.1 ingest catches only top-level deploys; contracts spawned by internal CREATE and CREATE2 from factories are out of scope for this run.

Enrich. For each of the 8,257 contracts, call eth_getCode for the deployed runtime bytecode, then Etherscan's getsourcecode for the verified Solidity if it exists, and txlist against the deployer for their first-tx timestamp. Throttled to 2.5 calls per second to stay safely under Etherscan's free-tier rate cap. Per-contract files on disk make the ~75-minute run resumable.

Score. Five rule families produce findings, each tagged with a severity (blocker / warn / info) and a confidence (0.0 to 1.0). The score is a weighted sum, capped at 1.0:

name: contract-name pattern match against a known-scam dictionary
bytecode: empty runtime (deploy-and-destruct), tiny runtime, known-drainer sha256
source: regex over verified Solidity for blacklist, pause, owner-mint, asymmetric fees
deployer: fresh EOA, no prior tx, high-volume deployer
drainer-hash: optional bytecode-hash list (empty in v0.1)

Narrate. For the top 20 contracts by score, send the source code + heuristic findings + deployer info to Claude Opus 4.7. The model returns structured output via tool use: a plain-English summary, an attack narrative, a confidence assessment, a suggested user action, and a verdict from {matches_scam_pattern, ambiguous, likely_legitimate}. The model explains; it does not score. ~$3 total cost for the run.

Headline numbers

Metric	Value
Top-level deployments in the week	8,257
Unique deployers	2,428
Verified source rate	32.1%
Contracts with empty runtime bytecode	580 (7.0%)
Total findings	~6,600
BLOCKER-severity contracts	192
Multi-blocker (score >= 0.8)	7

Score distribution:

Bucket	Contracts
0.0 (no findings)	2,698 (32.7%)
0.0 - 0.2	4,441 (53.8%)
0.2 - 0.4	911 (11.0%)
0.4 - 0.6	47
0.6 - 0.8	153
0.8 - 1.0	7

The shape is what you'd expect: a long tail of low-signal contracts, a thin cluster of obvious bad ones.

The 192 are one family

Top 10 verified contract names in the dataset:

Name	Count
FlashUSDT	134
ERC1967Proxy	119
MintBurnTeamToken	113
EVMToken	111
SimpleSwapToken	102
TransparentUpgradeableProxy	62
FlashUSDTLiquidityBot	58
Forwarder	41
Token	25
ProxyAdmin	23

134 FlashUSDT + 58 FlashUSDTLiquidityBot = 192. That is the entire BLOCKER tier. The other top-frequency names (ERC1967Proxy, TransparentUpgradeableProxy, ProxyAdmin) are OpenZeppelin upgrade-pattern boilerplate and largely benign; MintBurnTeamToken / EVMToken / SimpleSwapToken / Token are generic token-generator boilerplate that scores as WARN, not BLOCKER.

The FlashUSDT family was distributed across 59 unique deployer EOAs in the seven-day window. The top deployer accounts for 12 FlashUSDT deployments and zero non-scam deployments. The next four account for 11, 8, 7, and 5 respectively. This looks like a campaign with at least dozens of operators using a shared template, not one author.

Worked example: FlashUSDT

Contract: 0x07d0aacdb2603ed053f2a362c0d4ac618a46f1dc
Score: 0.90 (blocker)
Findings: name:high-confidence:FlashUSDT, deployer:fresh-eoa (deployer's first tx 0.2 days before deployment), source:owner-mint

Claude's walkthrough, verbatim:

Summary. The contract is a minimal ERC20-like token that hardcodes the name "Tether USD" and symbol "USDT" with 6 decimals, mints an initial 1,000,000 units to the deployer, and exposes an owner-only mint function that can create unlimited additional supply at any time. It is not affiliated with Tether; it is an independent token deployed by a fresh externally-owned account that simply impersonates USDT's metadata.

Attack narrative. This contract matches the well-known "Flash USDT" scam template, which is typically used in social-engineering schemes rather than as a direct on-chain drainer. The mechanism by which a user loses funds generally proceeds as follows: (1) The operator sends a victim a large balance of this token, which appears in wallets and block explorers as "Tether USD (USDT)" because the name and symbol strings are spoofed. (2) The victim is convinced the transfer is real USDT. Common pretexts include OTC trades, "test" payments, escrow proofs, job-offer signing bonuses, or "flash loan" demonstrations. (3) The victim then sends real value (real USDT on the legitimate Tether contract, ETH, goods, services, or grants approvals) to the operator in exchange. (4) Because this token lives at a different contract address than canonical USDT, it has zero market value and cannot be sold or redeemed; the victim is left holding worthless balances while the operator keeps the real assets.

Confidence assessment. Confidence that this matches the fake-USDT scam pattern is very high. The structural signals are unambiguous: the contract name is literally "FlashUSDT", the public metadata is verbatim "Tether USD"/"USDT"/6 decimals, an owner-mint function with no cap exists, the deployer EOA is hours old, and the source comment itself describes mint as "allows owner to create tokens out of thin air."

Suggested user action. Treat any balance of this token as worthless and do not send real assets, USDT, or ETH to anyone who points to it as "proof of funds" or payment. There is no need to revoke approvals; the contract cannot pull tokens from your wallet. Remove or hide the token in your wallet UI so it does not get confused with real USDT (canonical Tether on Ethereum is at 0xdAC17F958D2ee523a2206206994597C13D831ec7).

Verdict. matches_scam_pattern

Worked example: FlashUSDTLiquidityBot

Contract: 0x42ca40f4d556c50d943de4b6bf427925bba8adc4
Score: 0.76 (blocker)
Findings: name:high-confidence:FlashUSDTLiquidityBot, deployer:fresh-eoa

The companion contract to the FlashUSDT class. The narrative (in the full dataset) describes the operator simulating a "liquidity bot" that the victim is sold access to or convinced is generating real yield; it pairs with a FlashUSDT deployment to make the demo look credible. Same family, same operator profile, same deploy-time signal.

Validation

Manual stratified sample. I picked 30 random contracts (6 from each of five score bands) and opened each one on Etherscan. Verdict: 6/6 confirmed scam in the very-high band (score >= 0.8), 1/1 confirmed in the low band (the rest were unclear without further tooling), and 0 confirmed-non-scam anywhere. The "unclear" rate in the middle bands is itself a finding: a human reviewer cannot easily evaluate unverified-bytecode-only contracts without decompilation or interaction simulation. This is the gap the analyzer fills.

Band	yes	unclear	Precision (where decided)
very-high (>= 0.8)	6	0	100%
high (0.6 - 0.8)	0	6	n/a
medium-high (0.4 - 0.6)	0	6	n/a
medium (0.2 - 0.4)	0	6	n/a
low (0.0 - 0.2)	1	5	100%

ScamSniffer cross-reference. I downloaded ScamSniffer's public blacklist (2,530 addresses) and checked overlap with the 192 flagged contracts and their 59 unique deployers. Zero overlap. This is a real finding, not a bug. Public scam lists are weeks-to-months lagging indicators: they require a victim to report, a maintainer to confirm, and an entry to land. Heuristics that run at deploy time produce a lead-time signal that public lists structurally cannot match.

Limitations

The dataset and the analyzer both have honest gaps. Calling them out:

Factory deployments are missing. Only top-level to == null deploys are ingested. Factory routers using internal CREATE / CREATE2 are skipped. Many real scam token launches go through factories. The 8,257 number is a lower bound on actual fresh-contract activity for the week.
Source-only heuristics on a 32% verified rate. Two-thirds of contracts have no Solidity source on Etherscan. The source-text checks (blacklist, pause, owner-mint, asymmetric fees) are blind to those. Bytecode-only heuristics catch some of them (empty-runtime, tiny-runtime), but the long tail of unverified bytecode is the natural next analysis.
One scam family explains the entire BLOCKER tier. The FlashUSDT class is so common in this window that it crowds out other classes from the top scores. A different week with a different active campaign would look different. Generalizing the precision number requires multiple windows.
Hand-curated name patterns. The high-confidence name dictionary (FlashUSDT, FlashUSDTLiquidityBot) was seeded from a quick look at the data. It will not catch novel scam classes whose names I haven't seen yet. A pre-registered name list from public scam taxonomies would harden this.
No on-chain interaction analysis. The first 24 hours of interactions with a deployed contract is a strong signal (real holders vs. only the deployer; transfers in patterns consistent with bots). Pulling that requires either an indexer or expensive log scans. Out of scope for v0.1.
No bytecode decompilation. Runtime bytecode is hashed but not decompiled. A bytecode-level pattern matcher against well-known drainer kits (Pink Drainer, Inferno Drainer, etc.) is the right next addition. The seed hash list ships empty.

Reproducibility

The whole pipeline is one Python project. Everything ships open source under MIT.

git clone https://github.com/sanjeevkkansal/evm-deploy-watch
cd evm-deploy-watch
python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev,narrate]"

# Set keys in .env:
#   QUICKNODE=https://your-quicknode-mainnet-url
#   ETHERSCAN_API_KEY=...
#   ANTHROPIC_API_KEY=...   (only for the narrate phase)

# Reproduce this week's run:
evm-deploy-watch find-blocks --start 2026-04-03T00:00:00Z --end 2026-04-10T00:00:00Z
evm-deploy-watch ingest --start-block 24795371 --end-block 24845605 \
  --output data/window_2026_04_w1.json --concurrency 10
evm-deploy-watch enrich --input data/window_2026_04_w1.json \
  --contracts-dir data/contracts --deployers-dir data/deployers
evm-deploy-watch score --window data/window_2026_04_w1.json \
  --contracts-dir data/contracts --deployers-dir data/deployers \
  --output data/scored_2026_04_w1.json
evm-deploy-watch narrate --scored data/scored_2026_04_w1.json \
  --window data/window_2026_04_w1.json \
  --contracts-dir data/contracts --deployers-dir data/deployers \
  --output-dir data/narratives --n 20

Total runtime: ~2 hours for ingest + enrich. Total cost: ~$3 for narration on Claude Opus 4.7 if you run it.

The raw dataset (window + enriched contracts + deployers + scored output + narratives) is roughly 320 MB. Source code for verified contracts is included verbatim, so antivirus tools may flag the directory once it lands. I exclude it from AV scanning locally and recommend the same.

What I'd add next

In rough order of payoff:

Factory-deployment ingest. Use trace_block or a derivable equivalent to catch contracts spawned via internal CREATE / CREATE2. Probably 4-10x the deployment count, mostly weighted toward scam-factory output.
Bytecode-hash matching against a real drainer-kit seed. Pull known runtime hashes from drainer-archive and ScamSniffer reports.
First-24h interaction analysis. "How many distinct callers in the first day" is a much stronger legitimacy signal than name or source matching.
Run on multiple weeks. Lets the precision number generalize beyond the single FlashUSDT-heavy window.
Compare against Base mainnet. Same pipeline, different chain, different scam economy.

Notes

Tools used: Python 3.13, httpx, pydantic, the Anthropic Python SDK, QuickNode for RPC, Etherscan v2 for source and account lookups, Claude Opus 4.7 for narration. No paid security tools, no SaaS pipelines.

Everything is in the repo. Issues, PRs, and disagreement welcome.

HashiCorp built an MCP server for writing Terraform. I built one for reviewing it

Sanjeev Kumar — Thu, 21 May 2026 18:11:24 +0000

A few weeks ago HashiCorp shipped terraform-mcp-server. It's an official MCP server that lets a model lean on the Terraform Registry: search providers, pull module docs, manage HCP Terraform workspaces. The shape is "help the model author IaC." That's a genuinely useful tool and a clear signal that Terraform-via-MCP is now a category, not a curiosity.

But it doesn't help with the part of Terraform I spend the most time stressed about: reviewing somebody else's plan.

terraform plan outputs are long. Real production plans run into the thousands of lines. The risky changes (an IAM grant going *, a security group opening to 0.0.0.0/0, an RDS instance being replaced) hide between a hundred routine attribute updates. Code review tools don't help because the danger isn't in the HCL diff, it's in the planned actions.

So I built tf-review-mcp. It's an MCP server scoped to one job: parse terraform show -json output and surface what a human reviewer actually cares about, structured for an LLM to quote and reason about.

What it does

Two tools:

review_plan(plan_json_path) returns a structured summary: action counts, high-blast-radius resource changes, stateful destroys, and diff-aware public-exposure findings.
suggest_review_comments(plan_json_path) returns a list of {address, severity, comment} objects ready to drop into a PR review.

The server flags three things:

High-risk resource types (warn). A conservative built-in list across AWS, GCP, and Azure: IAM, KMS, RDS, security groups, S3, EKS, GKE, Cloud SQL, GCS, Cloud DNS, GCE firewalls, Key Vault. Easy to extend in source.

Stateful destroys (blocker). When a stateful resource like aws_db_instance, google_sql_database_instance, or google_compute_instance is scheduled for delete or replace. The GCE case matters more than people realize: a replace on a Compute Engine VM with local SSDs nukes both the boot disk and any local-SSD attachments. Silent data loss if a reviewer misses it.

Public exposure changes (blocker). Diff-aware. The server compares before and after on every google_compute_firewall change and fires when source_ranges newly contains 0.0.0.0/0 or ::/0. That single check has caught more dumb mistakes for me than any static analyzer.

What it looks like

Given a plan that deletes a Cloud SQL instance, replaces a GCE VM, and widens a firewall to the public internet, the server returns:

{
  "counts": {"create": 1, "update": 3, "replace": 1, "delete": 1},
  "stateful_destroys": [
    {"address": "google_compute_instance.op_geth", ...},
    {"address": "google_sql_database_instance.indexer", ...}
  ],
  "public_exposure_changes": [
    {"address": "google_compute_firewall.rpc_public",
     "finding": "source_ranges now includes 0.0.0.0/0 (public exposure)"}
  ],
  "notes": [
    "2 stateful resource(s) scheduled for destroy/replace. Verify backups and migration plan before applying.",
    "1 firewall change(s) widen public exposure. Confirm intent before applying."
  ]
}

Asked to summarize, Claude reads this and produces:

Blocker-severity items (3)

google_compute_instance.op_geth: Delete/recreate of a stateful compute instance. Confirm backup, migration, and rollback plan before merging.

google_sql_database_instance.indexer: Cloud SQL instance is being deleted. Confirm backup, migration, and rollback plan before merging.

google_compute_firewall.rpc_public: source_ranges now includes 0.0.0.0/0 (public exposure). Confirm this is intentional and matches firewall policy.

That's a PR review comment I'd actually merge.

Why MCP, not a CLI

The same parser could be a CLI. The reason MCP matters is the conversational shape. When I'm reviewing a plan, I want to ask follow-up questions: "is the SQL delete a replace or a hard destroy?", "what changed about that firewall?", "draft me a PR comment for the IAM grant." The model can pull the right tool, narrow on the right resource, and write something useful, because the underlying tool returns data, not prose. Lower hallucination surface. Higher signal per token.

Most community Terraform-MCP experiments wrap the CLI ("run terraform plan for me"). That's the wrong abstraction for review. You don't want the model running plan; you want it reasoning about a plan that already ran.

Architecture and deployment

The parser is in review.py as pure functions with no MCP imports: plan JSON in, ReviewSummary out. The MCP wrapper is in server.py, about a hundred lines. The split means the parser can be unit-tested, dropped into CI, or audited without touching the transport.

Deployment is local stdio. Always. The MCP client launches the server as a child process. Plan JSON never leaves your laptop. No auth, no shared state, no network listener.

Plan JSON contains IAM relationships, account IDs, security group rules, and resource counts. Hosted "send us your plan" services are a recon goldmine waiting to happen. The architecture should make leakage impossible by default. A self-hosted HTTP variant for CI is a v2 idea, with auth and a path allowlist, not before.

Why this is differentiated

HashiCorp's official server covers Registry lookup and HCP workspace management. Helpful for writing.

This one covers plan review. Helpful for reviewing.

Both ship as MCP servers. Both can be installed in the same client. The model picks the right tool per task. They're complementary by design, not competitive.

I haven't found another MCP server scoped specifically to plan review with LLM-friendly structured output, as of writing. If one exists, I want to know.

What's next

estimate_cost_delta wrapping Infracost.
check_policy wrapping Conftest, so teams can bring their own Rego.
Configurable HIGH_RISK_TYPES via a YAML file so each team can codify its own blast-radius rules.
More diff-aware checks: aws_security_group ingress widening, IAM * grants, google_storage_bucket force_destroy toggles.

The repo lives here: github.com/sanjeevkkansal/tf-review-mcp. It's MIT-licensed, v0.2, and very much open to PRs, especially if you have a war story about a plan that should have been caught.

Sanjeev Kumar is an infrastructure engineer working on platform tooling, AI-assisted ops, and infra that doesn't wake people up at 3am.