Post URL: Click to jump
The story began like this:
In this post, I wrote a simple MCP Server for L Station.
https://linux.do/t/topic/527169
https://github.com/Pleasurecruise/linux-do-mcp
Initially, I intended to deploy a remote SSE address, so that users only need to enter a link when using it.
Unfortunately, things didn't go as planned.
Nowadays, when we use some MCP servers, we inevitably encounter scenarios requiring high user permissions. These situations can be divided into two types:
- One type requires permission to access local resources.
- One type requires permission to access remote resources (usually from internet service providers).
Currently, there doesn't seem to be a mature way to resolve this issue. Recently, I noticed that AutoNavi (Gaode Map) uses a solution similar to the following for their own MCP server:
https://mcp.amap.com/sse?key=xxx
This method transmits the API key as a request parameter.
So the question comes:
Is this method really secure and universally applicable?
AutoNavi, benefiting from its reputation as a big company and providing their own service, transmitting API keys in this way hardly poses security issues.
However, if an individual developer wants to create an MCP server using their own remote address and requests such high-privilege API keys from you, would you dare to provide it?
Additionally, transmitting env as an HTTP request parameter is inherently unreasonable.
It appears that the mainstream solution currently is to use OAuth2 authentication.
Is it because AutoNavi lacks OAuth2 authentication, or because MCP technology is not yet mature enough to implement this?
So circling back, since transmitting env in such a way is unreasonable, we can only adopt OAuth authentication.
Then I looked into LINUX DO CONNECT's OAuth authorization.
Looking at the user info endpoint: https://connect.linux.do/api/user, the response indeed returns an api_key field, but it only has permission to view basic user information.
As for functionalities in my project that require user authentication—such as viewing posts, bookmarks, etc.—these cannot be achieved.
In summary, my idea to deploy an SSE address for linux-do-mcp can only be shelved for now.