[rdlauer]

So this is an artifact of my slow-but-sure march through the DevX repos to migrate some to Namespace. The tl;dr is we are NOT proposing to migrate runners to namespace for this repo, BUT Claude found a number of issues with the existing workflows.

Reviewed with Codex as well.

Here is the full summary:

The MCP SDK (go-sdk) is now on v1.8.0, the latest stable release. The four vulnerabilities are gone: govulncheck reports "No vulnerabilities found". Everything is still uncommitted on rob-namespace-ci.

What changed for the SDK:

• Dependencies: go-sdk v1.1.0 → v1.8.0. That also moved google/jsonschema-go (v0.3.0 → v0.4.3) and golang.org/x/oauth2 (v0.30.0 → v0.35.0). I bumped golang.org/x/sys to v0.44.0 to clear a vulnerability this code never reaches.
• main.go:
  • Removed the deprecated HasTools: true. The server's advertised capabilities are unchanged.
  • Added an MCP_DISABLE_LOCALHOST_PROTECTION=1 environment variable. v1.8.0 rejects any request that reaches the server over localhost with a non-localhost hostname (its DNS-rebinding protection). It's on by default; the variable turns it off without a code change.
• README.md: a line explaining that tunnels like ngrok need that variable.

What clients will notice: I ran the old and new servers side by side with identical requests.

• Same: the handshake, every tool's schema and output, the session-less GET stream, and session DELETE.
• POST without Content-Type: application/json now gets 415.
• Requests over localhost with a foreign Host header now get 403. Run in Docker with an AppRunner-style Host, every request succeeded, so production should be unaffected.
• Bad tool arguments now come back as an error result the model can read and correct, instead of a protocol error.
• tools/list has two new fields (cacheScope, ttlMs) that older clients ignore.

The independent reviewer found nothing that breaks claude.ai, Claude Code or MCP Inspector, including clients on the newest protocol version. I couldn't test docs_search successfully, because it needs an API key from AWS Secrets Manager; it fails the same way on the old server.

After the first full release deploys, run this check. AppRunner's health check bypasses the SDK, so it wouldn't catch MCP failures:

curl -s -o /dev/null -w '%{http_code}\n' https://mcp.blues.io/expert/mcp \
  -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"check","version":"0"}}}'

You should get 200. If you get 403 with "invalid Host header", set MCP_DISABLE_LOCALHOST_PROTECTION=1 in AppRunner's environment variables; no rebuild is needed. AWS documents that requests reach the container from a separate request-router fleet, not over localhost, so I don't expect that.

Follow-ups I left alone:

• Idle MCP sessions never expire, so they stay in memory until the next deploy. That's the same as before this change.
• The SDK's own log messages are discarded.
• Session.Log is deprecated but keeps working for at least 12 more months.
• main.go has an unused sessionManager variable.
• Promoting a prerelease rebuilds the image, so it isn't the exact image you tested.

Final checks pass:

• Go: go mod verify, build, vet and test all pass on Go 1.27.1.
• Docker: the two-architecture build passes.
• Lint: actionlint shows only the known queue false positive.

Should I commit this and open the PR?

Source: Architecting for resiliency on AWS App Runner

[Bucknalla]

LGTM