What stood out to me is how much of this comes down to people treating “MCP connected” like a single yes/no state when it’s really three separate systems stacked on top of each other. That framing feels useful. It also explains why the failure mode is so annoying: you can do everything “right,” see the server listed, and still have the first real request bounce.
The part I’d actually keep in my head is the distinction between approval, tool permission, and the external credential. Those are easy to blur together when you’re moving fast. I’ve seen enough tooling to know that once a UI says “connected,” people stop looking for the next layer of failure. That’s probably the mistake this article is trying to correct, and I think it’s a good one.
I’m a little less convinced by the packaging around it. The advice itself is pretty practical, but the article also leans into a broader “production Claude” posture that feels a bit heavier than the problem deserves. Still, the concrete bits are sensible: check the actual tool name before writing permission rules, don’t assume a project-scoped connection means everyone has the same access, and don’t hand an assistant a write-capable token when you only want read access.
That last point is the one I’d underline. “Limit access twice” is the right instinct. A lot of people trust the server configuration and forget the credential, or trust the credential and forget the endpoint shape. In practice, both need to be constrained, because either layer can drift later.
The verification habit at the end is probably the most useful thing here. Ask for one record you can verify by hand, then compare it line by line. That’s boring, which is exactly why it works. If the model can’t give a field, it should say so instead of inventing it. I wish more agent tooling guidance started there instead of with abstractions.
Reference: Claude Code MCP: Connected but Not Working? Check These Three Gates
