In principle, I agree with you. The problem I have with articles like this and people commenting is that it's framed as if MCP's vulnerability is discovered, that MCP "needs fixing." When it's not. It's not the database's fault if you don't hash your password - it's yours.
It's a fundamental user experience flaw with the MCP server. It does indeed need fixing - e.g. it could have a permissions system itself, so even if the GitHub token has permissions, different projects have their tool calls filtered to reduce access to different repos. Or it could have a clearer UX and instructions and help making multiple tokens for the different use cases. The MCP server could check the token permissions and refuse to run until they're granular.
At a high level I think it's still appropriate to question the role MCP is playing, even if you can still blame AI enthusiasts for being cavalier in their approach to installing MCP servers and giving them blanket permissions.
The more people keep doing it and getting burned, the more it's going to force the issue and both the MCP spec and server authors are going to have to respond.
The role is very simple. It provides an interface for the AI to access the data. Whatever it has access to (via MCP), it will access. Simple as that.
> The problem I have with articles like this and people commenting is that it's framed as if MCP's vulnerability (...)
You're extrapolating. The problem is clearly described as a MCP exploit, not a vulnerability. You're the only one talking about vulnerabilities. The system is vulnerable to this exploit.
It's not even an exploit. MCP is doing what it is MADE TO DO. It's made for interacting with the GitHub API. Whatever it has access to, it will access. If it has access to delete the repo, it will delete the repo. If it has access to the private repo, it will access the private repo.
> It's not even an exploit. MCP is doing what it is MADE TO DO.
You still don't understand the problem, do you? I mean, do you even understand the concept of an exploit?