David Mohl works with Claude Code, Codex, and Gemini daily. He's waded into the MCP versus Skills debate with a clear take: MCP is the better architecture for connecting LLMs to services, and the industry is making a mistake treating Skills as a universal replacement. Skills have a real role. They work for pure knowledge transfer and teaching LLMs how to use existing tools. But when a Skill requires installing a CLI to actually do something, the approach falls apart. Mohl's argument is simple. MCP treats service connections as API abstractions. The LLM calls devonthink.do_x() and the MCP server handles the implementation. No local installs. No manual secret management. No context window bloat from loading entire instruction manuals. Remote MCP servers work from any device, update instantly for all clients, and handle authentication through proper OAuth flows instead of plaintext tokens in .env files. This mirrors tools like Pace, which connects Claude AI to wearable health data. As Mohl puts it: "Why not just use a remote MCP instead?" Hacker News pushed back hard. The core objection: local CLI tooling is simpler, and adding MCP as an abstraction layer violates Occam's Razor. But commenters also acknowledged the choice depends on context. Skills and local execution for solo builders who want direct control. MCP's standardized interfaces and authentication for enterprises managing agents at scale. Solo developers want to run CLIs directly. Teams need standardized protocols and proper auth flows. Both camps have a point. The friction shows up when a local-first agent needs to talk to an MCP-standardized service. That's when the choice actually matters.