Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP Hello Page

hybridlogic.co.uk

Post reply on HN
Print view View original

21–30 of 58 posts

Re: MCP Hello Page

#21

Post by tekchip »

stavros wrote: post #7

But why would you show the MCP server URL as a clickable link in the first place, if it's not meant to be clicked? Put it in a monospaced box with a "copy to clipboard" button, it's not the fault of the user for not "thinking ahead" when they click a clickable link that wasn't actually meant to be clicked.

I call this "dev think". Blames user for not thinking ahead when they themselves haven't thought ahead about how users use things. It's everywhere these days, as an end user of things myself, it's maddening.

Re: MCP Hello Page

#23

Post by eoskx »

kami23 wrote: post #16
eoskx wrote: post #10

Doing a workshop this week on MCP for an enterprise client and explaining the 406 returned by GET against /mcp w/o text/event-stream is exactly one of the things that I have to bring up when I do these. The specification still leaves a lot to be desired, especially as it relates to auth. There are lots of bad ways to do auth with MCP and only a couple of good ways. It also puts a lot of pressure on the various IdP ve…

Hey thanks for the note about the discord! I have also been finding the MCP auth story to be really lacking was excited to see OAuth 2 support until I tried to get it to work at work and realized our idp implementation didn't support 2.1, and went into the spec and started wondering if anyone had a good experience yet. Luckily most of our environment can settle on a OAuth token env var standard until that's all in or…

A lot of how well it works or won't work depends on your clients, as not all clients have support for things like RFC 9728 (Protected Resource Metadata). Assuming your client has good support for most of the OAuth 2.0 standards that MCP uses (you don't need DCR as you can statically register clients, assuming that is viable for your environment), then it is possible now with most IDPs to get an OAuth 2.0 auth code flow working just fine. You would then do a token exchange to the upstream to ensure to get the appropriate new audience and rescope/downscope as necessary. Gateways can also help here a lot as instead of baking in all of the auth concerns into your MCP Servers and upstreams, you delegate that to the MCP Gateway. Again, gateway here means different things to different vendors, but Kong, for example, has the ability to act as an MCP proxy (gateway), expose tools based on consumer role or group, apply OAuth 2.0 to it and do an upstream token exchange, while also acting as a regular API gateway that can protect an endpoint with OAuth 2.0/OIDC.

Re: MCP Hello Page

#24

Post by stavros »

tekchip wrote: post #21
stavros wrote: post #7

But why would you show the MCP server URL as a clickable link in the first place, if it's not meant to be clicked? Put it in a monospaced box with a "copy to clipboard" button, it's not the fault of the user for not "thinking ahead" when they click a clickable link that wasn't actually meant to be clicked.

I call this "dev think". Blames user for not thinking ahead when they themselves haven't thought ahead about how users use things. It's everywhere these days, as an end user of things myself, it's maddening.

Yep, unfortunately, not many developers think about good UX.

Re: MCP Hello Page

#26

Post by singpolyma3 »

Waterluvian wrote: post #8

> Instead, I did something a little bit hacky: if the request is for GET /mcp and the Accept header includes text/html and NOT application/json or text/event-stream, I return a HTML page explaining to the user they're trying to view an mcp server and they need to add it to their client. This feels like less of a hack and more of discovering what some of the HTTP headers are for. You’re choosing rather reasonably how…

Indeed! Far from a hack it is the entire purpose to the accept header!

Re: MCP Hello Page

#27

Post by BoxedEmpathy »

didip wrote: post #14

I never quite understand why /mcp endpoint is needed. You can still keep using Rest API with swagger docs and tell the AI to read the swagger docs. It's the same thing. The entire Rest API specification is a lot more flexible than the JSON RPC format /mcp uses.

MCP is fine for exposing tools that don't have APIs, but wrapping an API is an MCP is fine if you like consistency.

Personally, for just tools, I wire up tool calls with context captured via system prompt.

Re: MCP Hello Page

#28

Post by epistasis »

> Despite the fact that MCP is an utterly terrible attempt at a "specification",

Can I just say that anybody involved with MCP's launch should be ashamed of what they put out there. I understand tool calling. I understand specs. I read MCP's "spec" and I used useless word salad that alternates between baby's first wire format and pie-in-the-sky marketing speak. Several of the navigation links I encountered were broken.

Poorly thought out, poorly communicated, but it's the only thing out there that 1) meets the need, and 2) published by people with a huge amount of reach. Right place, right time, shit effort. So it gets adoption. Like the history of PCs, of the internet, or everything, I guess. Worse truly is better.

Re: MCP Hello Page

#29

Post by efitz »

I love this. The best documentation is that which is presented at the exact place and time that it is needed, and users self support really well if you do that.

I once worked for $COMPANY and we had a network scanning application. Always generated a lot of tickets from angry people wanting to scream about bots.

So we put a web page page on each worker that would inherit some details from whatever job was running, and say “I’m a $TYPE_OF_SCANNER FROM $COMPANY doing $THING_THAT_BENEFITS_YOU.

This behavior is covered by our terms of service page at $LINK.

If you believe that we should not be doing this, please contact $SUPPORT and provide this code:

$SCAN_JOB_IDENTIFIER”

Call volume and unhappy customers went way down.

Post reply on HN