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

51–58 of 58 posts

Re: MCP Hello Page

#51

Post by 0123456789ABCDE »

efitz wrote: post #29

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…

this reminds: webcrawlers are supposed to include an info url with their user agent header

ex: Googlebot/2.1 (+http://www.google.com/bot.html)

Re: MCP Hello Page

#52

Post by 0123456789ABCDE »

cianmm wrote: post #45

I have spent ~3 months working on various aspects of an MCP server builder at my day job and I hadn’t considered this solution to the nightmare of getting non technical end users connected. I shall be borrowing it next week!

consider also solutions like llms.txt, or variations of it using the same trick mentioned in OP

GET / accept: text/html -> passthrough to existing content

GET / accept: text/markdown -> respond with llms.txt or a stripped down version without html tags or other noisy bits

Re: MCP Hello Page

#53

Post by 0123456789ABCDE »

lurking_swe wrote: post #40
unglaublich wrote: post #36

I thought the concensus was slowly converging to using clear CLIs + skills (i.e. progressive disclosure) instead of MCPs to avoid the context pollution.

what about web apps that requires oauth login - for normal users? For example, is a typical Google Drive user expected to install an official google drive CLI and a skill md file just to interact with Google Drive in the chatgpt app? That seems absurd, IMO. Clicking “install” via an MCP / Plugin marketplace and then logging in via Oauth is less confusing. MCP is also way more convenient (as a user) if i’m interacting…

parent is right, but so are you

note: cli tools do auth too — gh and claude code itself have some of the nicest auth flows i've experienced

Re: MCP Hello Page

#54

Post by luodaint »

Bearer tokens using mcp-remote are the pragmatic way forward out of the authentication mess.

Spec-based implementations of OAuth 2.0/2.1, including dynamic client registration and token exchanges, are absolutely necessary on a large scale but are an enormous barrier for adoption during early deployments. Cookie tricks ignore the spec and produce special cases when client credentials need to be rotated.

Solution in the real world: configure the server to provide the WWW-Authenticate header with value "Bearer" on unauthorized requests, issue limited-scoped tokens, leave the rest up to mcp-remote. The client authenticates once, uses bearer token in its requests, server verifies against scopes. No dynamic client registration required.

The authentication solution becomes clearer if you distinguish between "what the spec allows" and "what you need in your deployment." Not many servers really require OAuth on day 1.

Re: MCP Hello Page

#55

Post by 0123456789ABCDE »

julius wrote: post #38
unglaublich wrote: post #36

I thought the concensus was slowly converging to using clear CLIs + skills (i.e. progressive disclosure) instead of MCPs to avoid the context pollution.

CLIs need installs. What if your customer uses Web-based Agent? What if your customer has IT that does not easily allow install/updates of your CLI? CLIs are working better with current harnesses in my experience, but no idea how I would ship them.

i've used pypi, which enables: `uvx ` or `uv tool install ` for a more permanent setup

some folks go to the trouble of publishing with `brew`

then there's the old `curl -LsSf https://example.com/install.sh | sh`

Re: MCP Hello Page

#56

Post by 0123456789ABCDE »

Jabrov wrote: post #17

"The (annoying) solution is to package our server up into a connector/plugin and release it for each and every LLM client out there." Isn't this literally against the entire point of MCP

no.

you only deploy + maintain one mcp server, all mcp capable harnesses will know how to use it.

you need to publish to each marketplace for discovery, but you can also just put the the incantation on the product page and be done with it.

  claude mcp add --transport http  
  codex mcp add  --url=

Re: MCP Hello Page

#57

Post by reincoder »

pvtmert wrote: post #39

Not a hack at all. In fact, this is how Kubernetes APIs work. Even the CLI asks YAML or JSON content type when `-o yaml` or `-o json` is specified. Also, some other sites (albeit sometimes looking at the User-Agent header, hence more hacky) also doing the same. For example `ipinfo.io` returns HTML page when opened in a browser but a JSON (prettified) when requested via cURL.

Yes, we do use user agents to separate requests to our websites and API service. However, we request users to switch to api.ipinfo.io (dedicated API infrastructure) and use ipinfo.io/json for an explicit request for the API endpoint.

There are indeed some limitations to this implementation. The primary one being IPv6 support. The implementation prioritizes convenience over internet limitations, requiring us to roll out IPv6 dual stacking on the web request level as opposed to the DNS level. On an API level, this results in users with IPv6 addresses making API requests to v6.ipinfo.io.

So, last year we rolled out dedicated API infrastructure for api.ipinfo.io

Re: MCP Hello Page

#58

Post by scottlepp »

deadbabe wrote: post #48

Haven’t people caught on lately that MCP is a dead end and that we’re better off feeding shell scripts to agents with some brief documentation?

I think the death of MCP has been greatly exaggerated. I like that I can easily edit the mcp config and use npx to run a "token efficient" mcp server. Finding those is the hard part.

What gave mcp servers a bad name is the way folks implemented them. They just wrapped rest apis exposing too many tools, too much unnecessary data returned from the apis, and not managing the request context...just shoving everything in and blowing up the context.

I've used a lot of terrible ones for sure, and ended up just building my own using strategies that reduce bloat and token consumption.

Open source and self-healing. https://github.com/scottlepp/ultra-mcp-toolkit

Post reply on HN