[HN Gopher] MCP-Scanner - Scan MCP Servers for vulnerabilities
___________________________________________________________________
MCP-Scanner - Scan MCP Servers for vulnerabilities
Author : hsanthan
Score : 85 points
Date : 2025-10-27 17:18 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| cyberax wrote:
| The MCP landscape is a huge frothing septic tank. Go on, try to
| create a simple MCP server that is protected by a password and
| connect it to ChatGPT or Claude. Or even the one that uses your
| local SSO system for authentication.
|
| I tried and failed after about 3 days of dealing with AI-slop-
| generated nonsense that has _never_ been worked. The MCP spec was
| created probably by brainless AI agents, so it defines two
| authentication methods: no authentication whatsoever, and OAuth
| that requires bleeding-edge features (dynamic client
| registration) not implemented by Google or Microsoft.
|
| The easiest way for that right now is to ask users to download a
| random NodeJS package that runs locally on their machines with
| minimal confinement.
| zingababba wrote:
| Lol yeah, lots going on that will hopefully make it better
| though.
|
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://aaronparecki.com/2025/05/12/27/enterprise-ready-mcp
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://www.okta.com/newsroom/press-releases/okta-introduces...
| https://github.com/modelcontextprotocol/ext-auth/blob/main/s...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| fasbiner wrote:
| Had an almost identical experience. Even if you don't need
| anything with auth, no one has yet made an mcp that wasn't
| ultimately worse or the same as a cli but with a lot more song
| and dance. Security is also a bit of a joke when half the time
| it's installing docker and phoning home. I wanted to like mcp
| and vend out remote mcp but this spec is not ready.
| morkalork wrote:
| I'm still confused as to how mcp is better that say a Fastapi
| endpoint and it's generated swagger docs?
| mbreese wrote:
| In the cases I've tried building/integrating they are the
| same thing...
|
| I think the only difference is the statefulness of the
| request. HTTP is stateless, but MCP has state? Is this
| right?
|
| I haven't seen many use cases for how to use the state
| effectively, but I thought that was the main difference
| over a plain REST API.
| eric-burel wrote:
| My understanding is that it can upgrade to an SSE
| connection so a persistent stream. Also for interprocess
| communication you usually prefer a persistent connection.
| All that to reduce communication overheads. The rationale
| also is that an AI agent may trigger more fine-grained
| calls than a normal program or a UI, as it needs to
| collect information to observe the situation and decide
| next move (lot more get requests than usual for
| instance).
| fasbiner wrote:
| Using SSE was far too inconvenient in theory despite that
| being how nearly all of the MCP that gained traction was
| working, so instead the spec was switched to being better
| in theory but very inconvenient in practice:
|
| https://blog.fka.dev/blog/2025-06-06-why-mcp-deprecated-
| sse-...
|
| There are a million "why don't you _just_ X?"
| hypothetical responses to all the real issues people have
| with streamable http as implemented in the spec, but you
| can't argue your way into a level of ecosystem support
| that doesn't exist. The exact same screwup with oAuth
| too, so we can see who is running the show and how they
| think.
|
| It's hard to tell if there is some material business plan
| Anthropic has with these changes or if the people in
| charge of defining the spec are just kind of out of
| touch, have non-technical bosses, and have managed to
| politically disincentivize other engineers from pointing
| out basic realities.
| bootsmann wrote:
| "Ok, how do we do customer auth" has become my go-to question
| to kill MCP projects. There is no working solution which makes
| any kind of enterprise exploration into the space pointless.
| mbreese wrote:
| Serious question, as I'm starting to go through this process
| myself -
|
| Is it possible for the customer to provide their own bearer
| tokens (generated however) that the LLM can pass along to the
| MCP server? This was the closest to a workable security I've
| looked at. I don't know if that is all that well supported by
| Chat GUI/web clients (user supplied tokens), but should be
| possible when calling an LLM through an API style call, right
| (if you add additional pass thru headers)?
| eric-burel wrote:
| The LLM doesn't intervene much actually, it just tells what
| tool to call. It's your MCP implementation that does the
| heavy lifting. So yeah you can always shove a key somewhere
| in your app context and pass it to the tool call. But I
| think the point of other comments is that the MCP protocol
| is kinda clueless about how to standardize that within the
| protocol itself.
| arscan wrote:
| I think an important thing to note is the MCP client is a
| distinct thing from the 'LLM' architecturally, though
| many LLM providers also have MCP client implementations
| (via their chat ui or desktop / cli implementations).
|
| In general, I'd say it's not a good idea to pass bearer
| tokens to the LLM provider and keep that to the MCP
| client. But your client has to be interoperable with the
| MCP server at the auth level, which is flakey at the
| moment across the ecosystem of generic MCP clients and
| servers as noted.
| maxwellg wrote:
| The initial remote MCP specification was pretty painful, but
| the June spec and the upcoming November spec are much more
| workable - MCP auth is (mostly) just OAuth now. MCP Clients
| are OAuth clients and can be granted access tokens and
| managed just like any other 3rd party app integration.
|
| I'd love to hear more about the specific issues you're
| running into with the new version of the spec. (disclaimer -
| I work at an auth company! email in bio if you wanna chat)
| dorkypunk wrote:
| I'm still laughing on how the error handling for tools is done,
| it's just a boolean field IsError.
|
| https://modelcontextprotocol.io/specification/2025-06-18/ser...
| throwaway314155 wrote:
| MCP works best for tool calling that doesn't require auth (so
| tools that are trusted on your own machine). The whole pitch
| that you should be using it for business facing tools and
| things that require auth is a terrible idea.
|
| Even if you're doing local only - MCP tools can mostly be
| covered by simply asking Claude Code (or whatever) to use the
| bash equivalent.
| cyberax wrote:
| > MCP works best for tool calling that doesn't require auth
| (so tools that are trusted on your own machine).
|
| In other words, downloading random crap that runs unconfined
| and requires a shitty app like Claude Desktop.
|
| BTW, Claude Desktop is ALSO an example of AI slop. It barely
| works, constantly just closing chats, taking 10 seconds to
| switch between conversations, etc.
|
| In my case, I wanted to connect our CRM with ChatGPT and ask
| it to organize our customer notes. And also make this
| available as a service to users, so they won't have to be AI
| experts with subscriptions to Claude.
| tsouth wrote:
| The MCP & DCR OAuth ecosystem was immature at the start, but
| has really evolved and become robust. E.g., WorkOS has some
| really robust OAuth that can act as a standalone proxy for MCP
| connecting to any existing auth infrastructure.
|
| Metadata and resource indicators are solving the rest of the
| problems that came with the change to OAuth spec.
| jngiam1 wrote:
| It's really messy now. ChatGPT in particular makes it really
| hard; it turns out that Custom GPTs with actions can do pretty
| well, if you bridge MCP tools into actions; but setting any of
| these up is a pita.
|
| The LLMs are also really bad at generating correct code for
| OAuth logic - there are too many conditions there, and the DCR
| dance is fairly complicated to get right.
|
| Shameless plug: we're building a MCP gateway that takes in any
| MCP server and we do the heavy lifting to make it compatible
| with any client on the other end (Claude, ChatGPT - even with
| custom actions); as a nice bonus it gives you SSO/logs as well.
| https://mintmcp.com if you're interested.
| oezi wrote:
| Why just a gateway? Why not a serverless way to host tools?
| oezi wrote:
| So where can we host simple single file MCP tools with the ease
| of a lambda?
| whattheheckheck wrote:
| Aws has agentcore
| rdegges wrote:
| At Snyk, we've been working on this for a while. Here's our
| flagship open source project consolidating a lot of the MCP risk
| factors we've discovered over the last year or so into actionable
| info: https://github.com/invariantlabs-ai/mcp-scan
| tsouth wrote:
| I have seen a bunch of demos of this, often building on top of
| open standards like the SAFE-MCP MITRE ATT&CK analysis
| https://github.com/SAFE-MCP/safe-mcp
|
| In general, the only way to make sure MCPs are safe is to limit
| which connections are made in an enterprise setting
___________________________________________________________________
(page generated 2025-10-27 23:00 UTC)