Hacker News Reader

Everyone is so afraid of being left behind in this period of rapid AI change. The influencers are exploiting that to create anxiety and fear of missing trends.

I follow several influencers from pre-AI times who were (or were trying to become) social influencers thought leader types. People like Theo or many of the JavaScript and training course people. Following them was helpful to follow the trends that more chronically online juniors would be picking up and pushing at the workplace, which set me up in a better position to understand and then defend against it.

All of them, every single one, have dropped their previous influencer topic and pivoted to being AI influencer. Every time I see a post they’re either saying you need to adopt a new trend or that last month’s trend is dead. “Prompting is dead! Graphs are the future!” or “Claude Code is OVER! This new harness is 10X better”

MCP was one of these topics. Everyone went from telling you that you needed to use MCP or be left behind, to declaring that MCP was dead almost in unison.

The only pro-MCP holdouts were the influencers who had built their own MCP courses for sale.

It kind of repulses me when these people will make a video about anti-AI sentiment and splice in an ad for an AI tool at the halfway mark.

Do content creators have a lot of say over what advertising gets spliced in to their creation?

Spliced in likely refers to ads they splice into their own videos, which they control completely. The platform ads are separate from the video and the creators do not have control over what is shown.

Yes. I'm talking about the sponsored segment where the creator reads ad copy of whoever's sponsoring that episode that day.

> My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec

MCP servers provide three things: tools, resources, and prompts. Of these, tools seem to be the only part implemented consistently across major clients like ChatGPT, Claude.ai, Claude Code, etc.

For prompts and resources, there doesn't seem to be a common understanding of how clients are supposed to consume them.

For example, if an MCP server exposes resources, Claude Code can discover them and consume them when needed without you explicitly asking for a specific resource. Claude.ai behaves differently. It doesn't automatically discover and consume those resources. Instead, it gives you a way to manually add an MCP resource to the prompt.

So while MCP defines tools, resources, and prompts at the protocol level, the actual user experience for resources and prompts varies quite a bit across clients.

In practice, the problem with resources is that many resource collections are too large to list exhaustivley, and if that's the case you will need to need to implement a proper search tool anyways (as the Completions utility isn't a good fit), at which point there is little use in also implementing all of that as a resource, rather than `list_`,`search_`,`get_` for a resource.

That feels like it should be the obvious use case for something like a `?q` query param, formalized or not, but it seems like nobody working on the spec and libraries ever considered query params as a use case, since they're still broken in the Typescript library.

The idea of "model controlled", "application controlled" and "user controlled" for tool, resources and prompts (respectively) was aligned with the chat interface. It breaks for the autonomous agent paradigm where the agency is the user and the lines are blurred. Unfortunately MCP has been mostly relegated to tool calling leaving potentially powerful capabilities on the table due to lac of client support for them.

I disagree on Prompts since virtually all of the mainstream harnesses implement them: Cursor, Claude, OpenCode, Copilot. Prompts are very clearly just a remotely delivered `/` command and it is easy to see why this is really powerful (single entry point, no need to update/sync skills, dynamic sets by audience, dynamic construction of the payload by audience, etc). For all intents and purposes, it should be viewed as an analog to local, text-only skills.

Codex is the only mainstream harness that does not implement this in the client.

Prompts I am not that sold on but it seems silly to not implement it in clients.

A good use case for resources is small amounts of commonly needed state that can be fetched and proactively updated by the mcp server, saving latency when the model requests it.

An MCP server should be self-describing, so I use prompts to deliver skills or skill-like context.

Prompts is possibly one of the most useful enterprise features for MCP.

Dynamically target sets of `/` commands to teams in an enterprise by their identity+claims? Legal team gets a set of skills? Finance team gets another just by their roles? Always up-to-date delivery of what are effectively remotely served skills? Telemetry on who is using which skill? Server-side rendering of skills so that common skills can be composed? With placeholders replaced by user- or team-custom options? Easy to ship new skills as long as the user has connected the MCP? Easy to retire skillsets that are outdated across the entire enterprise?

MCP Prompts is one of the most powerful capabilities in the spec for enterprises.

OpenAI team: if you are angling for enterprise, you need to get this solved. Your FDEs are going to make a killing getting this set up for enterprises. Build an enterprise skills management platform around this that's integrated to their directory. Streamlined setup of the MCP via MDM. Telemetry on enterprise wide usage of curated skills across the enterprise, by team, by individual. You need this.

I’m still not entirely sold. I do hear you about team workflows, I’m just not sure MCP does that dramatically better (as of today).

I can see the snap appeal. One protocol, we can chuck an auth reverse proxy in front of all the MCPs, compliance has their integration point, etc.

I don’t think MCP is structured enough to give a huge edge over bash there. Looking at MCP messages, they aren’t immediately more legible than a bash command, output and exit code. You also don’t own a lot of the MCP servers you use, so backtracking for audits will require knowing what MCP commands did what back then.

I do suspect something more like MCP than bash will be the winner. MCP just feels very open source rather than enterprise. Eg I don’t think I’ve seen any sort of privilege escalation and logging scheme. The enterprise will want some sort of “request admin privileges” scheme. Likewise they’ll probably want more context on ACP requests; who is calling this MCP, using what agent, and for what project?

You’re out of the loop! I’ve myself implemented access escalation on top of MCP and it’s not rocket science. It’s already being used by Enterprise everywhere!

MCP is about the server side, not the client side.

MCP over HTTP buys you server side telemetry, composability, remotely held credentials (security), etc.

MCP is about enterprise control of the server side; no advantages on the client side at all.

To be fair, the MCPs of 8 months ago are not the MCPs of today. You had to mess around with headers and .env files and local npm proxies and other bullshit only cli jockeys would tolerate. The MCPs of today are fully remote, stateless, oauth enabled, and integrated much more nicely into the the user experience. Click a button and it works.

I do agree, the "MCPs are dead" narrative was overblown, but there were legit reasons we weren't ready to go all in on them back then.

You could serve MCP over HTTP 8+ months ago and deal with none of that? Lots of people did? Especially internally within Enterprise

>It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack

This was already happening back in March. Lesser technical users were looking to hook up web LLMs to various SaaS apps so they could pull data in.

It was quite surprising people were forming such strong opinions when there were very clear and objective differences in use case.

Yeah I always just thought of MCP as best for the average user and then CLI as one of the tools of choice for power users. Never had to be one or the other, I use both daily

With stateless MCP, the MCP rube goldberg everyone was calling dead in March is effectively dead though.

MCP was already stateless capable in March. All the build I was doing was already stateless HTTP (which is why it felt certain that it was the future).

These reason why they were proclaiming MCP dead and crowning CLI the influencer is that they aren't serious people. They're either vibe coders who never knew what the meaning of engineering for production or they are those who chose to forget the meaning because it fits their chosen vibe coder narrative.

Yep, number of new MCP servers this month is on track to be the highest it has ever been: https://bloomberry.com/data/mcp/

"MCP" is the new "API" (MCP over streaming HTTP, after all, is just an API with a structured payload wrapper and defined interactions).

It is only going to continue to proliferate in usage and adoption.

With the v2 spec, MCP became a lot closer to APIs by becoming stateless. And there is now a push to use HTTP verbs more extensively to improve caching even better in v3. MCP is converging into APIs but wit great auth and auditing

... Are both of you using "API" as a synonym for "REST"?

This is the worst moment in time to talk about "REST".

Do you mean the Roy Fielding "REST" or the HTTP API "REST"?

Calling the latter "REST" is wrong. It's like calling a hermit crab a snail.

Edit: I forgot to mention, the former is gaining relevance as the elusive evolvable clients are now a thing.

I'm not trying to be a dick, but it's pretty hilarious that we made these two posts at the exact same time [0]. I totally get what you're saying, but I don't understand the motivation behind it. A properly designed HTTP API is what Roy Fielding was discussing in his dissertation, but he was obviously talking about HTML pages full of hyperlinks. At the end of the day, does it really matter much if the definition is only 80% correct if the majority of the population understands the basic gist of the conversation?

[0] https://news.ycombinator.com/item?id=49908582

Unironically, Roy Fielding had a point.

If you can build the ultimate evolvable client, then you can collapse all UI into a single client.

Basically Roy Fielding told us to build an API that can only be operated by a human like intelligence, nobody could implement that because such an intelligence did not exist (hence the switch to imperfect HTTP APIs), and now that LLMs are a thing, said human like intelligence exists. This means Roy Fielding wasn't wrong, he was 25 years too early and ironically people should be building real REST APIs in the pendantic academic sense from today on and not the "pragmatic" HTTP API.

It's annoying, but that's been pretty common for the last decade. It's just like how everyone uses "REST" to mean "JSON RPC". In the end, we all basically know what the other ones are talking about, so it's pretty pointless to get bogged down in semantics.

It's common when talking about web services, where the kind of API is generally unambiguous. The problem here is we're discussing different kinds of APIs (shell commands, MCP, REST / JSON RPC) and so calling one of those kinds of APIs "API" is very confusing.

Seems like in this context API means HTTP API lol

"REST" is one of many way to implement APIs.

Exactly. It's confusing to talk about MCP vs API when "API" describes the whole class of possible values, of which "MCP" is one of them.

Decent point - but - the same could be said for skills. You can have enterprise skills that don't require use of MCP.

Sure, but now you have a distribution and telemetry challenge.

It's hard to customize those skills. How can I tweak my skill a bit to match my workflow? With MCP Prompts over HTTP, this is easy: you can server render the text with my personalization specific to me.

It's hard to tell which skills are being used. With MCP over HTTP, each Prompt call, each Tool call is an HTTP request and you get telemetry on activation. You can server compose the response and ask the agent requesting it to return a score on how useful it is, too. Or ask it to call another endpoint to rate the skill.

Enterprise skills delivered to the disk you cannot do this. If a skill is flawed or outdated, you cannot revoke the skill at an enterprise level. MCP Prompts: it's easy to do.

"It's hard to customize those skills."

I don't see what you mean?

An MCP and a skill are just two ways of distributing capabilities.

For telemetry ... well the agent should still have it's http logs? Also, I'm not sure MCP Telemetry is the primary point of concern for most things? Like thats a skill debugging thing?

I sync a skill in a file with my repo. I can't edit that skill. I can't combine that skill. I can't customize the skill without affecting the other folks on my team or I have to put that in a gitignore.

A user getting a skill via a plugin and wants to keep it in sync with the source has the same problem. Next update/sync wipes out their changes.

Skills delivered via file system download/git are like Deck.final.v2.real-final.2026-10-01.published.pptx. Skills delivered via MCP over HTTP are "live" and dynamic.

An HTTP MCP server is just a server returning text. The MCP prompt can be a template. It can have placeholders. I can build a UI to allow the user who logs in to customize the prompt/skill by filling in the placeholders. If they don't put a value for the placeholder, I render it to the HTTP response stream with defaults. I can dynamically render the skill, tailored for each user like I can render JSON or HTML for each logged in user. MCP Prompts just returns text. I can render any text I want on a server. I can return a different, more suitable skill text for the user. I can personalize it based on their workflow. The base template is always up to date for every user, etc.

Try it. Go write an MCP HTTP endpoint delivering a prompt. Now make that dynamic and serve different text back based on different users. Now your users are in different teams. Render variants of the same prompt/skill by team. It's powerful.

Use your imagination.

?

You can trivially build a skill that uses a set of customizable, per user values.

You can also build a (non-MCP) 'gateway' to do those things you just described, and not have it bound or limited by 'MCP' at all.

We already do both things.

I don't see what MCP has to do with any of this; it's a standard, that has very narrow value.

You can't do it in a team environment. You are missing the key point. Teams.

Please, go build the simplest MCP server you can that serves a prompt. Now make it dynamic by user. Now let you users share a common template. Now look at the telemetry you see on the server when someone uses the skill. Now add a flag to turn some on and off. Now imagine you are in an enterprise and you want to centrally manage all skills across the teams mapping some skills to some teams, revoke skills, force update skills, compose skills by user automatically using rules.

Please. Just try it. You can literally vibe code this in a few minutes and connect the dots.

A file on disk is static. An HTTP request-response for text is not. Build just one prompt endpoint. Now imagine dynamically injecting text into the skill as well because it's just HTTP.

You are arguing why we need web servers when we can just email text files to each other, save them on disk, and open them in Notepad. Do you not understand the power of using an HTTP server for sending text?

I built an MCP server almost on the first day MCP came out; and have built many.

I have been working on 'teams' with MCP since then.

Similarly with 'skills'.

I have been working with NLP and AI for decades.

I've worked (a little bit) with one of the 'Godfathers of AI'

And FYI (although I can't be certain obviously) odds are I have been coding since before you were born.

By your answers - don't seem to have demonstrated a grasp of the technology in question, and are glibly project as though you have some kind of insight.

The 'general service concept' you are describing can be quite useful, yes, but at that level of sophistication - especially with 'user management', and the inherent issues around that aka privileges, SSO, telemetry, whatever etc. - that would likely be best used as a common service, accessed via regular REST calls. The 'agent instructions' for that service would be trivially described in a 'skill'.

Alternatively, a 'skill' which merely instructs the Agent on how to use a local tool via CLI (which can be anything really), is very useful as well. Almost universally so.

After that 'skills' oriented towards REST services and local CLI tooling - MCP has little to no value.

The only scenario in which we continue to use MCPs, are for those published by 3rd parties, for which MCP provides a relatively plug-and-play solution. But even then, if MCP were to be deprecated, everyone would merely switch to rest/cli-facing skills, and nothing would be lost.

MCP has a bit of value due to it's incumbency, but it never existed, nobody would invent it today, it really doesn't solve any real problem, given how much better AI is at using standard tooling.

I mean it was a pretty classic hype cycle - MCP was massively inflated, the blowback was also inflated, and now we're in the happy state where there are same cases where it's genuinely better and differentiated and everyone will keep iterating on it. (statelessness was a big step forward).

Either way still seems like the issue is people giving influencers too much power over them.

> The key mistake people made was thinking in terms of their own workflows and own local stacks

We need a dunning-kruger for empathy: people least able to imagine situations not their own trying hardest to influence others.

Important to remember most ai influencers are a joke and spewing nonsense, claiming things are “over” is one of the only reliable and viable ways to for a person not at OpenAI/anthropic to actually make money in this wave.

I was watching something on YouTube last night and it really reminded me of informercials from the 80s/90s. Imagine trying to divine actual useful information about business, technology, and industry from infomercials..

There is no reason to think about team workflows. Focus on your workflow. Your own custom local workflow is basically your competitive advantage as an employee. The moment everyone else can do exactly the same things you do, there is no reason to really keep you around.

The game has changed in the AI era. Horde secrets, skills, custom processes. Don’t share everything. Stop giving things away or you will have nothing left.

If that works for you great but I am where I am in my career by helping everyone I can around me. Making my team and the company better pays dividends and you stand out from people that only work for themselves.

This is now an outdated mentality in the AI era, where people will quickly use whatever you put out to make themselves better but little to no benefit will return to you beyond maybe a fuzzy feeling. People already feel proud just prompting huge projects out and claiming it as their own work. You will not be recognized.

“When a favor becomes too large to repay, the gratitude turns to resentment.”

It sounds like you and I are having very different experiences in the AI era.

Good luck

> prominent folks in tech including Garry Tan

lmao not sure if you are being sarcastic but that guy is joker and a poster child of ai psychosis .