For our soft launch last week, my engineering lead (Donnie) and I deliberately chose a sub-optimal way to share context. Well, what we think is sub-optimal. We used the feature that would get us to “market” fastest, not the one we think is the best long-term solution.
We’re building the plane while it’s taking off–we won’t really know the best solution until we try it.
But experimenting creates a release problem.
Users need a skill that knows how to connect to our Data 626 MCP server and use the context there to write queries. The more people who download that skill, the more people I eventually need to upgrade the skill when we change where context is stored and how it’s structured.
We have no idea how to release updates to a skill. I’m sure if I dug into Teh Intertubes, I could find a dozen different approaches. Probably more like dozens and dozens of approaches.
But it’s not a binary, right? A skill is just text. It can’t be that hard.
So I asked Claude:
“Can we put the skill on the MCP server so users are always using the latest and greatest?”
I expected the answer to be no.
Claude hemmed and hawed a little. There were problems. Users would have to reload sessions to get updates, among other things.
But a few prompts later, Claude had solved the problem.
I need two skills.
One lives on the user’s machine. Its job is simply to configure and connect their client—Claude, Cursor, VS Code, whatever—to our MCP server. And it points to the second.
The second lives on the MCP server. That’s where the actual context product logic goes. We can change that whenever we please. No release management at all!
The surprising part wasn’t that Claude wrote some code for me. It’s that it helped me realize I’d put the product boundary in the wrong place.
Leave a Reply