You hit the nail on the head regarding Juniors—they are already in a tough spot, and I certainly don't want to build a tool that makes that worse.

However, my hypothesis is that matching on 'Problem Vectors' might actually help break the cycle of 'only getting hired for what you've already done.'

Transferable Complexity: A traditional recruiter sees 'Game Dev' and ignores them for a Fintech role. But a vector model might see that the candidate solved a 'distributed concurrency' problem in a game that is mathematically similar to the 'payment sync' issue in the JD. It matches on capability, not just domain keywords. Signal for Juniors: Currently, ATS filters reject Juniors based on '0 years experience.' If a Junior has tackled a complex logic problem in a hobby project or Hackathon, this system highlights that specific signal. It gives them a fighting chance based on code reality rather than resume keywords. That said, I agree this model naturally leans towards Senior/Specialist roles where specific technical gaps need immediate filling. It's not a silver bullet for 'hiring for potential,' but I hope it's a step up from the current keyword-soup approach.

I love the "mental model" approach here. Most guides I've seen either get bogged down in the minute details of TLS/Handshakes immediately or are way too high-level. The interactive packet visualization is a really nice touch to bridge that gap. Thanks for sharing!

Pavlo is right to be skeptical about MCP security. The entire philosophy of MCP seems to be about maximizing context availability for the model, which stands in direct opposition to the principle of Least Privilege.

When you expose a database via a protocol designed for 'context', you aren't just exposing data; you're exposing the schema's complexity to an entity that handles ambiguity poorly. It feels like we're just reinventing SQL injection, but this time the injection comes from the system's own hallucinations rather than a malicious user.

Totally agree, unfettered access to databases are dangerous

There are ways to reduce injection risk since LLMs are stateless and thus you can monitor the origination and the trustworthiness of the context that enters the LLM and then decide if MCB actions that affect state will be dangerous or not

We've implementeda mechanism like this based on Simon Willison's lethal trifecta framework as an MCP gateway monitoring what enters context. LMK if you have any feedback on this approach to MCP security. This is not as elegant as the approach that Pavlo talks about in the post, but nonetheless, we believe this is a good band-aid solution for the time bein,g as the technology matures

https://github.com/Edison-Watch/open-edison

> Totally agree, unfettered access to databases are dangerous

Any decent MVCC database should be able to provide an MCP access to a mutable yet isolated snapshot of the DB though, and it doesn't strike me as crazy to let the agent play with that.

For this database has to have nested transactions, where COMMITs do propagate up one level and not to the actual database, and not many databases have them. Also, a double COMMIT may propagate changes outside of agent's playbox.

> For this database has to have nested transactions, where COMMITs do propagate up one level and not to the actual database,

Correct, but nested transaction support doesn't seem that much of a reach if you're an MVCC-style system anyway (although you might have to factor out things like row watermarks to lookaside tables if you want to let them be branchy instead of XID being a write lock.)

You could version the index B-tree nodes too.

  > but nested transaction support doesn't seem that much of a reach if you're an MVCC-style system anyway

You are talking about code that have to be written and tested.

Also, do not forget about double COMMIT, intentional or not.

Yes and no. Least privilege has existed in databases for a very long time. You need to implement correct DB privileges using user/roles, views, and other best practices. The MCP server is more like a dumb client in this setup.

However, that's easy for people to forget and throw privileged creds at the MCP and hope for the best.

The same stands for all LLM tools (MCP servers or otherwise). You always need to implement correct permissions in the tool--the LLM is too easily tricked and confused to enforce a permission boundary

i dont know anyone with a brain that is using a DB mcp with write permissions in prod. i mean trying to lay that blame on a protocol for doing something as nuts as that seems unfair.

Was the trade-off so exciting that we abandoned our own principles? Or, are we lemmings?

Edit: My apologies for the cynical take. I like to think that this is just the move fast break stuff ethos coming about.

The 'once a day' fetching limitation is a fascinating idea. It really captures the vibe of reading a physical newspaper in the morning rather than constantly checking for updates. I think many of us could use a tool that enforces a bit of 'digital silence' like this.

In middle school (age 11-13 in the late '90s, USA) I had a hand-me-down Palm Pilot (probably upgraded to Handspring in there). I'd leave it on my serial(?) port cradle and have it download my daily news from sites like IGN and Slashdot over 56K before I woke up. I was also the kid that regularly read the "Time Life for Kids" mags they'd pass out to us in homeroom. That's the outlet I learned about Napster from and hooked my school onto. Your comment reminded me of those days. Now I'm still desperately hooked on RSS since the early days.

ETA: When I was a late teen I ended up managing a bunch of younger teams for a free mod for an indie PC game called Blockland. I had them code up IRC and RSS capabilities into the mod from scratch in the Torque Game Engine's custom TorcueScript. I couldn't believe what those kids were capable of. They all went into programming, engineering, or founding their own companies out of highschool and college. If one of them told me something was impossible I'd just tell them that I saw that a competing mod already figured it out. Magically my dudes had a solution really quick lol. Sometimes when you have limited resources and/or experience the old and proven ways are just as good.

Was great when they had all that XML experience in a weird scripting language and I asked them to implement Jabber in-game from my Dreamhost shared-hosting plan. Crazy what a bunch of teens can do for an online Lego-like game.

Thanks for letting this older dude wax nostalgic off the rails. Hope it reminds others on HN about early hacking days like OP's project.

Love it. It’s funny how we are now building modern tools just to try and get back that simple 'Palm Pilot morning read' vibe.

I've been wanting a browser plugin like this for ages. Basically tell it which sites to limit, then once loaded it won't re-load for a certain amount of time, or until the next day (not necessarily 24 hours). This way there is no reason to keep checking the news, they won't change.

this on an e-reader would be lovely. perhaps limiting the adding / removal of the source list to once a week or month would add another layer of purposefulness to it. want!

Kagi News does something similar, for what it's worth.

I’m currently evaluating whether I’m happy with Kagi News in my RSS reader compared to separate news outlets. So far it seems to capture all the important bits.