🎓 Thinking about MCP as "npm for LLMs"

Technical content rating: 🎓 basic coding literacy assumed

In these early days, MCP means a lot of things to different people. It's not really clear what the ecosystem will evolve into, or if it will even exist in a few years. But I wanted to share a theme that's been emerging in how we use MCP at DeepStructure.

An MCP skeptic could reasonably ask, "what can MCP do that LLM tool calls and APIs can't do?" The answer "well, not much" might seem off-putting at first. But let's compare with prior art.

In the node.js community, npm (node package manager) is probably the most valuable thing that JavaScript developers have collectively built. But have you ever asked yourself, "what can npm do that JavaScript code and APIs can't do?" Probably not — but the answer is the same: "well, not much".

So here are three parallels I see between MCP (in its infancy) and npm, that speak to why the "well, not much" answer is beside the point.

1. You could write it, but now you don't have to

If I want to add Stripe payments to my node.js app, sure, I could write a bunch of boilerplate JavaScript code that talks to the very-well-documented Stripe API. Or, I could npm install stripe.

Likewise, if I want to enable my LLM to use Stripe payments (slight frisson of disquiet writing that), sure, I could build some tool-calling glue and custom code that uses the Stripe SDK. Maybe that's the right approach for some use cases. Or, I could just install Stripe's MCP server and use their tools.

The "but now I don't have to" aspect can actually be a massive shift across the developer ecosystem as a whole, even if the quantum of improvement for each individual developer is relatively small.

And there's another related shift, which may be a better motivating example. We've been building an agent that can use Grafana tools (we'll share more about this soon). Sure, we could have taken the time to write our own Grafana tools. But for our use case, we likely wouldn't have budgeted the engineering cycles.

So the Grafana MCP server unlocks functionality that we wouldn't have budgeted the time for otherwise. Or for another less-technical team, may not have had the capability to build otherwise.

2. And now it's the vendor's problem

Building an integration isn't a one-time event. APIs grow and change over time. It saves me a ton of pointless headaches as a developer to enter into an informal contract with Stripe via npm, which allows me to update to Stripe's latest and greatest using npm update stripe (even though that does occasionally cause me some smaller headaches). I've made it mostly Their Problem (TM).

This kind of rigor doesn't quite exist in the MCP ecosystem yet, but the concept of an informal contract may carry across. I want it to be Grafana's problem to keep the Grafana MCP server working with the latest and greatest. We'll see if this becomes true in practice.

3. … with all that the npm analogy entails

While npm may be the most valuable thing that JavaScript developers have collectively built — or perhaps you disagree — it's not a uniformly pleasant system to deal with. npm packages have different levels of quality, and many of them are just crap. Some of them follow Best Security Practices (TM), and some of them are openly malware. And don't get a node.js developer started on the various JavaScript / TypeScript module formats and compatibility hacks. The fact that there's a lot of crap and pain on the margins doesn't diminish the value to developers who stay on the straight and narrow with best practices.

And to conclude, there are a few areas where the MCP as "npm for LLMs" analogy definitely doesn't hold up yet:

• Where are the production applications that actually do something useful with MCP? There are a few here and there. But there's not really a common pattern for building and deploying MCP apps in the same way that there are for node.js apps that use npm.

• What's the "MCP runtime"? Is it managed, or self-hosted? We've long known what this looks like for node.js apps. But MCP servers can be written in node, Python, Golang, and more.

• What's the package manager, packaging format, versioning and dependency story, etc. for MCP servers?

We'll share more thoughts about some of these loose threads in future posts!

[Note to pedants like me: I'm intentionally glossing over the details about MCP servers vs. clients, tools vs. resources, etc., and likewise for npm manifests, packages, repos etc. Let's call this a "vibe analogy" that focuses on the overall developer experience and value proposition.]