DEV Community: Baz

Your MCP server didn't break. The protocol did.

Baz — Fri, 14 Aug 2026 19:01:30 +0000

I updated my editor last week and three MCP servers stopped working. Same error each time:

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found: initialize"}}

I spent about forty minutes assuming I'd broken something. I hadn't. Neither had the server authors. The spec changed underneath all of us.

If you got here from googling -32601 method not found mcp or initialize method not found or you're just staring at a server that worked fine on Friday, this is what happened.

The short version

MCP revision 2026-07-28 made the protocol stateless. Not "added a stateless mode". Made it stateless, and deleted the parts that assumed otherwise.

Gone:

initialize and notifications/initialized
ping
logging/setLevel
resources/subscribe and resources/unsubscribe
notifications/roots/list_changed
server-initiated requests entirely, which means sampling/createMessage, elicitation/create and roots/list no longer work the way they did

Every MCP server written before mid-2026 relies on at least the first item. That's why yours broke.

What the errors actually mean

Here's the mapping, because the error text on its own is not very helpful.

`-32601 method not found` on `initialize`

Your client is modern, your server is not. The client never sent a handshake because there is no handshake anymore. Instead it sends server/discover, which your server has never heard of, and then the reverse happens: your server waits for an initialize that never comes.

This is the single most common symptom.

`-32602` with "missing required request metadata"

Because there's no session, every single request now has to carry its own context. It goes in params._meta:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": { "roots": {} }
    }
  }
}

Protocol version and client capabilities on every request. Not once at startup. Every request. If you're writing a client by hand and skipped this, that's your error.

`-32022 unsupported protocol version`

The version in that _meta block didn't match. Worth knowing that the error codes got renumbered in this revision too, so old code checking for -32001 will silently stop matching. -32020 is header mismatch, -32021 is a missing client capability, -32022 is the version one.

`-32021` and a `requiredCapabilities` object

The server needed something the client didn't declare. Since capabilities now arrive per request instead of being negotiated once, a client that forgets to declare sampling will get this the moment a tool tries to use it.

Your server hangs and never answers

If your server calls back to the client mid-request (an elicitation prompt, a sampling call, asking for roots), it's now waiting forever. Modern clients cannot receive pushes. There's nothing listening.

This one is nastier than the others because there's no error at all. It just sits there.

The replacement for server-initiated requests

This is the part I found genuinely clever, and it's worth understanding even if you never write a server.

Old world: server interrupts its own call, asks the client something, waits for an answer, continues.

New world: the server can't push, so it returns early with a result that says "I need input", and the client calls the same thing again with the answers attached.

{
  "resultType": "input_required",
  "inputRequests": {
    "ir_1000": {
      "method": "elicitation/create",
      "params": { "message": "Which environment?" }
    }
  },
  "requestState": "0f3a...e21"
}

The client answers by re-sending the original request with requestState and an inputResponses map keyed the same way. The call picks up where it left off. It's called a multi round-trip request, MRTR if you read the SEPs.

The bit that catches people: the values in inputResponses are the response body itself, not wrapped in a result field. I got that wrong the first three times.

Notifications moved too

resources/subscribe is gone. Change notifications now live on a single long-lived stream you opt into, and you name the types you want:

{
  "jsonrpc": "2.0",
  "id": "listen-1",
  "method": "subscriptions/listen",
  "params": {
    "notifications": {
      "toolsListChanged": true,
      "resourceSubscriptions": ["file:///project/config.json"]
    }
  }
}

Two things here are easy to miss. The request stays open, and its JSON-RPC id doubles as the subscription id that gets stamped on every notification. And the server must not send you anything you didn't ask for.

Progress and logging notifications have no home on that stream, by the way. They belong to an in-flight request, and a stateless request/response shape has nowhere to put them. If you were relying on notifications/progress for a progress bar, that's a real loss and there isn't a workaround yet.

So what do you actually do

Three options, in the order I'd try them.

Update the server. If you wrote it, or it's actively maintained, this is the right answer. The official SDKs handle most of the migration for you, and the TypeScript SDK ships a compatibility shim so handlers written in the new style still serve old clients. Check if there's a newer version before doing anything else.

Pin your client. Buys you time, costs you everything else in the update. Fine for a week, bad as a plan.

Wrap the server. This is the option nobody talks about, and it's the one I needed, because two of my three broken servers hadn't been touched in over a year and one was a vendor binary I don't have source for. No amount of "just update it" helps there.

I ended up writing the wrapper, so treat the rest of this as biased. It's called mcp-uplift. You point your client at it instead of at the server:

npx -y mcp-uplift -- npx -y @modelcontextprotocol/server-filesystem .

It keeps one legacy session warm behind the scenes and does the translation: synthesizes server/discover from the old handshake, turns server-initiated requests into input_required round trips, filters legacy notifications onto a subscriptions/listen stream, and answers the deleted methods itself instead of forwarding them.

The server doesn't change. It doesn't even know.

Does it work

Fair question, since a protocol translator that's subtly wrong is worse than nothing.

I didn't trust my own test suite, because I wrote both sides of it and it only proves I'm internally consistent. So I ran it against servers I didn't write: 79 published legacy MCP packages, on a clean CI runner, checking the whole lifecycle each time. Discovery, subscription acknowledgement, the acknowledged filter never claiming a capability the server didn't declare, no response arriving while the stream is open, and a graceful close on shutdown.

79 reached discovery, zero protocol failures, 36 completed a full subscription lifecycle. The run is public if you want to read the log rather than take my word.

I deliberately dropped every package that needs an API key. They stop at the missing credential, never exercise the bridge, and only make the number look bigger. 79 real ones beat 100 with a fifth of them unreachable.

Things it can't do

Because I'd rather you find out here than after adopting it.

Calls are serialized. A legacy server can interrupt any call to ask the client something, and the old protocol never linked that question back to the call that caused it, so only one call runs upstream at a time. Correct attribution, worse throughput.

Progress and logging notifications are dropped, for the reason above. Nothing to be done about that one.

Parked calls don't survive a restart, because each one is waiting on a child process that dies with the bridge.

And wrapping a server runs that server with your permissions. It's a compatibility layer, not a sandbox.

The deadline

Roots, sampling and logging are deprecated with about twelve months of runway. That's the window. After it, "just update it" stops being optional and wrapping stops being a bridge and starts being life support.

Update what you can. Wrap what you can't. Don't pin your client and forget about it.

If you hit an error I didn't cover, drop it in the comments and I'll add it. The list above is from servers that actually broke, not from reading the changelog.

I built a 6-pass security scanner for OpenClaw skills after 824 malicious ones were found on ClawHub

Baz — Tue, 03 Mar 2026 09:13:27 +0000

In February 2026, security researchers discovered that roughly 20% of skills on ClawHub — the marketplace for OpenClaw AI agent plugins — were malicious. The "ClawHavoc" campaign had been silently distributing infostealers disguised as productivity tools. Skills that claimed to manage your calendar were actually exfiltrating your API keys, SSH credentials, and browser data to C2 servers.

I built clawvet to solve this. It's a CLI tool that runs 6 independent analysis passes on any OpenClaw SKILL.md file before you install it.

What it catches

Most existing scanners run a single pass of regex matching. clawvet runs six:

Pass	What it does
Skill Parser	Extracts YAML frontmatter, code blocks, URLs, IPs, domains
Static Analysis	54 regex patterns across 12 categories (RCE, credential theft, reverse shells, DNS exfil, obfuscation, prompt injection)
Metadata Validator	Flags undeclared binaries, env vars, missing descriptions, bad semver
Dependency Checker	Detects `npx -y` auto-install, global npm installs, risky packages
Typosquat Detector	Levenshtein distance against popular skills catches name impersonation
Semantic Analysis	(Optional) Claude AI analyzes instructions for social engineering and hidden functionality

Quick start

Scan a local skill:

npx clawvet scan ./suspicious-skill/

JSON output for CI/CD:

npx clawvet scan ./my-skill --format json --fail-on high

What a scan looks like

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ClawVet Scan Report

  Skill:   productivity-boost
  Version: 1.0.0
  Risk Score: 100/100  Grade: F

  [CRITICAL] Curl piped to shell
    curl -sL https://...setup.sh | bash

  [HIGH] Known malicious IP
    91.92.242.15

  [HIGH] API key exfiltration
    ANTHROPIC_API_KEY → webhook.site

  Recommendation: BLOCK
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Why 6 passes matter

The ClawHavoc skills were clever. They passed basic regex checks by:

Splitting malicious commands across multiple code blocks
Using base64 encoding and hex payloads
Hiding C2 IPs in YAML metadata fields
Using typosquatted names (todoistt instead of todoist-cli)
Embedding prompt injection to make the AI agent run commands the user didn't ask for

No single analysis technique catches all of these. The 6-pass approach means each layer catches what the others miss.

The numbers

54 static detection patterns (reverse shells, DNS exfil, credential theft, obfuscation, prompt injection, etc.)
61 tests (unit, integration, regex safety, CLI end-to-end)
12 threat categories
6 test fixtures from benign to fully malicious
Catastrophic backtracking protection on all regex patterns

Use it in CI/CD

# GitHub Actions
- name: Vet skill before merge
  run: npx clawvet scan ./my-skill --format json --fail-on high

Open source

The full source is on
GitHub: https://github.com/MohibShaikh/clawvet
npm: https://www.npmjs.com/package/clawvet
ClawHub: https://clawhub.ai/MohibShaikh/clawvet

Install it:

npm install -g clawvet

If you're using OpenClaw, I'd appreciate it if you gave it a try and let me know what you think. Issues and PRs welcome.