A Critical Look at MCP  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: A Critical Look at MCP - Category: #podcasts - URL: https://share.snipd.com/episode/a9fe81f7-47ce-41a8-800e-76ee7e052319 ## Document Notes ## Highlights - **MCP Critiqued for Poor Engineering** - Rasmus Holm criticizes the lack of mature engineering in MCP rollout despite heavy investments in model training. - Poor documentation and weak SDKs overshadow advanced AI models, indicating bureaucratic panic in tech industry. Transcript: Jerod Santo Rasmus Holm is astonished by the apparent lack of mature engineering practices he sees as all the major players roll out model context protocol servers at a blistering pace. Quote, all the major players spend billions of dollars on training and tuning their models only to turn around and from what I can tell have an intern write the documentation providing Subpar SDKs and very little in terms of implementation This trend seems to have continued with MCP, resulting in some very strange design decisions, poor documentation, and an even Worse specification of the actual protocols. His conclusion after diving deep into his own implementation of the protocol in Go, Rasmus was gobsmacked by what he found. Quote, I'm just kind of feeling sad about it all. It seems like the industry is peeing their pants at the moment. It feels great now, but it's going to be hard to deal with later. ([Time 0:01:04](https://share.snipd.com/snip/15b67c76-d06f-4862-a510-acd415665068)) - **Stringly Typed Frustration** - Stringly typed means passing strings when better types exist, a term learned from Stefan Judis and Scott Hanselman. - This practice frustrates developers due to lack of type safety, especially when connecting to external APIs. Transcript: Jerod Santo Stringly typed. I learned a new software development term from Stefan Judas, who learned it from Scott Hanselman, who describes stringly typed as follows, quote, whenever you are passing strings Around, when a better type exists, end quote. In a language like TypeScript, this is rare in first-party code, but when dealing with OPC, that's other people's code, via an API, you're often still stuck with stringly typed things. This makes Stefan mad, quote, after building all these SPAs, connecting to APIs, being maintained by different teams, I've never considered to be a huge problem. But now that I have a name for this pattern, stringly typed interfaces started to bother me. I realized that I want type safety over the network and I don't want to deal with stringly typed apps at all. ([Time 0:02:14](https://share.snipd.com/snip/bd27e092-faeb-4b1a-b7da-836359bee91a)) - **The Curse of Knowing How** - Raph shares the 'curse of knowing how,' seeing software flaws once you can program. - He wrestles with the reality that not everything can or should be fixed, embracing some breakage as human. Transcript: Jerod Santo The Curse of Knowing How. Raph beautifully describes the plight of the enlightened who don't just use computers, but have the ability to program them. Quote, before I could program, broken software was frustrating but ignorable. For years, I've simply used a computer as a consumer. I was what companies were concerned with tricking into buying their products or subscribing to their services. Not the technical geek that they prefer to avoid with their software releases or banning from their games based on an OS. Now it has become provocative. I can see the patterns that I wish I couldn't, find oversights that I can attribute to a certain understanding or lack thereof of a certain concept, This is problematic for a bunch of Reasons, one of which, as Raph states, is that pesky thing called entropy. Quote, software doesn't stay solved. Every solution you write starts to rot the moment it exists. Not now, not later, but eventually. Libraries deprecate, APIs change, performance regressions creep in, your once perfect tool breaks silently because libfoo.so is now libfoo.so End quote. Yes, we can fix computers, but we can't fix everything. So what's a dev to do? Quote, after the excitement, after the obsession, after the burnout, I'm trying to let things stay a little broken because I've realized I don't want to fix everything. I just want to feel okay in a world that often isn't. I can fix something, but not everything. You learn how to program, you learn how to fix things, but the hardest thing you'll ever learn is when to leave them broken. ([Time 0:03:15](https://share.snipd.com/snip/3a24add8-2464-4d49-a4d1-dbcd861f8cef)) - **Know When to Leave Things Broken** - After burnout, accept that not all software issues must be fixed immediately. - Prioritize mental well-being by allowing some problems to remain unresolved. Transcript: Jerod Santo And maybe that's the most human skill of all. It's now time for Sponsored News. Terrence Lee shares his thoughts on the next generation of Heroku. Adam had a chance to sit down with Terrence Lee to talk about what's coming for the next generation of Heroku being built on open source standards. Here's what Terrence had to say. FUR represents the next decade of Heroku. Cedar lasted for 14 years and more. It's still going. We've used Stacks to kind of usher in this new technology. And what that means for FUR is we're replatforming on top of open standards. A lot has changed over the last decade. Things like container images and OCI and Kubernetes and CloudNave, all these things have happened in this space. And instead of being on our own island, we're embracing those technologies and standards that we help popularize and pulling them into our technology stack. So we're providing this access to tools and things that people, developers are already using and extensibility on the platform that you haven't had before. ([Time 0:04:53](https://share.snipd.com/snip/5553c90b-de79-4966-b0c4-6f5faa16f396))