The token you provide to the GitHub official MCP server determines what that server is allowed to access. But the MCP server doesn't just serve requests with responses, which is the normal case. It can read private data, and then publish that private data to something that is outside of the private scope, e.g. is public. This is a problem. The system doesn't need to make an explicit promise guaranteeing that this kind of stuff isn't valid, it's obviously wrong, and it's self-evident that it shouldn't be allowed.
I'm not sure whether you're confused, or I'm just having a horrible time understanding your point. The MCP server really does just serve requests with responses via a mechanism that satisfies the MCP spec. The MCP hosts (e.g. VSCode) work with an LLM to determine which of those tools to call, and ideally work with users via confirmation prompts to ensure the user really wants those things to happen.
What am I missing?
I do believe there's more that the MCP Server could be offering to protect users, but that seems like a separate point.
Sorry, I probably was being imprecise. You're correct that the [GitHub] MCP server really does serve requests with responses. But my point was that certain kinds of requests (like create_new_pr or whatever) have side effects that make mutating calls to third-party systems, and the information that can be passed as part of those mutating calls to those third-party systems isn't guaranteed to satisfy the access control expectations that are intuitively expected. Specifically by that I mean calling create_new_pr might target a public repository, but include a body field with information from a private repo. That's a problem and what I'm talking about.
The problem is that the MCP server does not know that the data being posted is intended to be private. It is provided as a separate disconnected API call. Yes, it would be possible for GitHub to scan the he contents of a request for things they might believe should be private but that would be very brittle.