CharlieDigital

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 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.

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.

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.

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.

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).

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.

"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.

It is, but I view it as more of a niche company and product still whereas Rivian has commercial products (Amazon) as well as mainstream consumer products like the R2 (shipping) and R3 (in pipeline). Still on the high end, but clearly moving mass market as their production capacity ramps up. Not sure about Lucid.

This was the easiest call and many like me made it in March[0] among all of the anti-MCP wave of influencers claiming it dead (many, many prominent folks in tech including Garry Tan). Literally every tech influencer in every social feed in March was calling MCP dead and crowning CLI the winner (completely ignoring every reasonable argument around security, observability/telemetry, ease of deployment and operations, etc.)

A direct quote from March, 2026[1]:

    > If you’re still not convinced that a lot of this discourse [regarding the death of MCP] lacks nuance and is just hype, congrats on buying into the current AI-influencer FOMO hype cycle; see you in 6 months when the influencers move on to the next revelation of the moment to stay relevant and get your eyeballs and dollars.

It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack of "what works for Me" versus "what works for My Team", particularly in an enterprise context. The key mistake people made was thinking in terms of their own workflows and own local stacks instead of a team's workflow and a team's operational stack. There was also an ignorance of MCP's stateless HTTP mode (yes, it was already a thing in March; the 2026-07-28 revision of the spec just prioritizes it as the primary focus moving forward) versus local `stdio`.

My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec[2] and in general, the major clients have spotty implementation for some of the features in the spec.

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

[1] https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/

[2] https://github.com/openai/codex/issues/5059

RJ Scaringe (CEO) is who everyone thought Elon was in the early days.

Really good listen:

https://podcasts.apple.com/us/podcast/rivian-rj-scaringe/id1...

    > ...considering their realistically the only American car companies that make their cars in the US

Rivian says "Hi"

It's your own infra because there's a distinct line item cost for it versus OpenAI.

Same way you say "my apartment" and not "my landlord's apartment". It's your place while you're renting it.

"Running your own infra" also includes managed infra like Bedrock, Foundry, etc.

Not just your local machines.

Enterprises are where you see this adoption. Legal, finance, tax; sensitive context where the data must be contractually opaque to external parties.

Even if folks are not running their own inference infra, there are still services like Fireworks, AWS Bedrock, and others that are running the open models. I suspect anyone doing serious work with it is likely using a US hosted provider and I'd guess that by volume, US use of Chinese open models is using a US hosted platform (enterprise).

If one thing is clear: Trump admin is pliable with money and this concern spans both Anthropic, OpenAI, SV elite, investors. Neither are going to be viable without US regulatory action, IMO.

Anthropic has to use this wedge (and future ones) to move regulatory action against the Chinese models or their IPO is going to be really problematic.

(Ironic, though, that I haven't heard of any Chinese models "escaping" which Anthropic and OpenAI both seem to have issues with...)

Like Chinese electric cars, the American producers cannot compete without regulatory action. Yes, I understand that the Chinese government this and that in both the automotive and AI industries.

But reality is what it is as a consumer: it's a cheaper product that's almost as good or better in some cases. And in the case of these open weight models: I can run it on my own infra and not give any data to anyone.

    > But with no benchmarks or price comparison, which likely means it doesn't compare that well.

Doubt that's the case; this was only the announcement and the API isn't even released yet. As I noted, my own testing using a batching strategy (nothing more than "read 20 lines from this file instead of reading 1 at a time") yielded ~the same accuracy on an 800 row dataset we have with ~1.6x the throughput (at only batch_size=20) and 1.2x the cost. Didn't tune to find accuracy dropoff by batch size, but it's easy to see that the decision capability was there (understood that it's not the same without the probabilities, but even without it, the classifications were nearly identical).

Would have to look at their quarterlies.

Reality: there are some companies that are very, very particular about letting their data outside of their purview. Think Wall Street, private equity teams making deals, VC teams, corporate M&A teams, companies dealing with legal contracts, etc.

For these teams that are heavily vested in SharePoint, OneDrive, OneNote, Outlook, etc. specifically for their enterprise controls, there really isn't much option. They can't use a Grok Bot, can't use Muse, can't use many, many things because of the risk of data leaks that will literally be millions/billions of dollars on the line.

You look at the landscape of what's happening with OpenAI and Anthropic agents "escaping", leaving notes on how to hack their way out for the next agent, etc. and it's not very inspiring if you're a CISO/CIO/CTO at one of these firms.

    > I'm starting to feel people are not honest about their experiences...

I think it falls under:

1. They don't actually look at/care what the agent is producing as long as it works (not planning on maintaining/ops yet).

2. They are using 3rd party benchmarks (which is fair given how widely real-world workloads change from day-to-day, feature-to-feature, making it difficult to really know how well the models would perform).

3. They are doing greenfield work where there is no scaffolding, no existing code, no legacy code, nothing to guide the agents along. I believe in these cases, new models can possible do better from a blank slate. But in existing codebases, I feel like the agents are more likely to simply follow existing patterns and existing guidance to begin with so things are a wash and more reliant on harness and existing code hygiene.

No one mentioning Decisions API?

Feels huge. Sounds like Luna on their Ultrafast infra.

I did some internal benchmarking and found that GPT 6 Luna in batch mode at 20 records per batch was about 1.6x faster at 1.2x the cost of Jev with no tradeoff in accuracy. Tuning it up/down would make it faster per-record while also reducing the cost (assuming accuracy holds). Though this was only useful for offline processing.

    > ...maybe they think enterprise will pick up and run with Dots? Seems unlikely.

Read the blurb about Microsoft and Agent 365

    > We’re also working with Microsoft to integrate specialist dots with their enterprise governance and security controls in Agent 365. The goal is to let businesses manage dots through the Microsoft tools they already use.

Very, very likely targeting enterprise

I fully believe that these models perform better in benchmarks versus their predecessors, but in real world usage inside of real, production codebases? They feel just as flawed as ever. I honestly have not seen any significant improvement in a few months. The last thing where I felt "wow" was `/fast` mode and Deepseek.

Sure it has existed, but it's lack of maturity was explicitly cited by Anders as a gap.

Quick scan of the repo and I didn't find the prompt or the setup of the harness, but I'd say that most people using DeepSeek are probably also not use it raw and without any guidance.

Is a zero-shot, zero-context prompt a useful benchmark? Yes, in the absolute sense. Does it reflect how teams would use it in the real world? I think in real-world use cases (IME), DeepSeek gets the job done.

Try using something like Herdr and have an Astra or Opus drive/orchestrate multiple Lunas. Best of both worlds.

Because the TypeScript runtime is not a web app? What part of my statement did not connect?

Likewise, the reason for the Copilot SDK to move to Rust is that it compiles to native binaries with no runtime and the FFI can interface with all of the supported SDK languages cleanly. Don't just read the headline; ready the actual post as well.

    > ...Porting that runtime layer to 100% Rust, resulting in a pure native binary exposing a C ABI for in-process consumption by all the language front-ends 

C# AOT is relatively nascent and not yet propagated through all of the ecosystem and thus is not a great choice for scenarios where the goal is a native binary with no runtime. Hejlsberg also cited the same reason for the TypeScript runtime. IMO, this is not C#'s strong point and sweet spot; sweet spot is web API backends.

Read my assertion carefully: web APIs are C#'s sweet spot. CLI apps, multi-platform SDKs -- makes total sense to use Rust.

Would love more specifics because I think this is an area where C# shines especially with hot reload. Even better if you wire it with CSharpRepl (no rebuild at all).

Do you need to learn Rust to use it at this point?

I think the tooling matters more than the language at this point.

I get that Rust is the new hotness, but I feel like they really address different segments, even post AI.

C# tooling for HTTP and gRPC web services is really, really good and very competitive performance wise. The large set of base class libraries and first party libraries that continuously get patched is a win, too.