We've seen this before. When we built http4k, we were using Kotlin to fight reflection-based magic, untestable architectures, and runtime failures that should have been caught as compile errors. The approach we took - treating everything as composable functions - solved these problems and created a toolkit developers love using.

Now we think MCP SDKs are making the exact same mistakes. Complex frameworks tied to specific transports. Testing that requires running actual servers. Runtime errors from type mismatches that could be caught at compile time. And when the MCP spec shifted from SSE to HTTP streaming, tightly-coupled architectures struggled to adapt. It's 2015 all over again.

Building an MCP SDK gave us a chance to test a hypothesis: were http4k's functional patterns actually universal, or just clever one-time tricks? This talk shows what happens when we applied the same principles to a completely different protocol:

- Layering abstractions - Separating protocol logic from transport mechanics
- Functional capabilities - Binding behaviour to specifications without magic
- In-memory testing - Pure functions that don't need infrastructure to verify
- Compile-time safety - Type systems that catch errors before runtime
- Composable modules - Reusing existing patterns (OAuth, Lenses, JSON-RPC) instead of building new ones

You'll see how Kotlin's features - extension functions, type aliases, operator overloading - enable these patterns to work across domains. More importantly, you'll see why functional simplicity consistently beats complexity, whether you're building HTTP servers or AI integrations.

This is an object lesson in modular design: build simple, composable parts once, then watch them work everywhere.