5 ms·
How likely are we to look back on Agent/MCP/Skills as some early Netscape peculiarity? I would dive into adoption if I didn't think some new thing would beat th
by reedf1 10mo ago
How likely are we to look back on Agent/MCP/Skills as some early Netscape peculiarity? I would dive into adoption if I didn't think some new thing would beat the paradigm in a fortnight.
- xnx 10mo agoDon't forget A2A: https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ https://developers.googleblog.com/en/a2a-a-new-era-of-agent-... We'll see how many of these are around in a few years.
- DenisM 10mo agoWhy do you think they will fade out?
- orliesaurus 10mo agoAdoption on most of these has been weak, except MCP (and whatever flavor of markdown file you like to add to your agent context)
- zingababba 10mo agoMicrosoft seems to be pushing MCP pretty hard in the Azure ecosystem. My cynical take is they are very aware of the context bloat so see it as extra inference $$.
- bonesss 10mo agoPure speculation, but I feel the inference money is tiny compared to the speed and permanence of Office integrations MCP enables through the consultancy swarm. MCP lets you glue random assed parts of services to mega-ultra-high critical business initiatives with no go between. Delivered through a personalized chat interface that will tell you how sexy you are and how you deserved to win at golf yesterday… from salesman to auto interface to forever contract in minutes. MS sells to insecurities of incompetent management and facilitates territory marking at the expense of governments and societies around the world for mega bucks. MCP, obvious as it is technically, also lets them plug a library into existing services for a quick upgrade then an atomized upsell directly to the chat interfaces of upper management. Microsoft’s CEO has talked about his agent swarm. Much like RPA this woo appeals strongly to the barely technical.
- amitport 10mo agoHis point, I believe, was that it is early in the innovation cycle and they very well be replaced quickely with different solutions/paradigms.
- wuliwong 10mo agoAgreed. I think if this is overly concerning, developing early in the innovation cycle just might not be the ideal place to be. :)
- DenisM 10mo agoWell, some things fade out and some do not. How do we decide which one it is? The reason I ask is that the pace of new things arriving is overwhelming, hence I was tempted to just ignore it. Not because things had signs of transience, but because I was drowning and didn't know where to start. That is not the same thing as actually observing signs of things being too foamy.
- observationist 10mo agoFrontier models will eventually eat all the tedious tailored add-ons as just part of something they can do. Right now models have roughly all of the written knowledge available to mankind, minus some obscure held out private archives and so on. They have excellent skills and general abilities to construct plausible sequences of actions to accomplish work, but we need to hold their hands to really get decent performance across a wide range of activities. Skills and agent frameworks and MCP carve out different domains of that problem, with successful solutions providing training data for future models that might be able to be either generalized, or they'll be able to create a vast mountain of synthetic data following successful patterns, and make the next generation of models incredibly useful for a huge number of tasks, by default. It might also be possible that by studying the problem, identifying where mode collapses and issues with training prevent the right sort of generalization, they might tweak the architecture and be able to solve the deficiency through normal training runs, and thereby discard the need for all the bespoke artisanal agent specifications.
- DenisM 10mo agoI hear you - model development might overcome the shortcomings one day. However the "waiting out" strategy needs a timeout. It might happen that agentic crutches around LLMs will bear fruit much sooner than high-quality LLMs arrive. If you don't have a timeout or a decent exit criteria you may end up waiting indefinitely, or at least until reality of things becomes too painful to ignore. The "ski rental problem" comes to mind here, but maybe there is another "wait it out" exit strategy?
- mbesto 10mo ago> Right now models have roughly all of the written knowledge available to mankind, minus some obscure held out private archives and so on. Sorry for the nit, but this is a gross oversimplification. Most private archives are not obscure but obfuscated and largely are way more valuable training data then the publicly available ones. Want to know how the DOD may technically tracks your phone? Private. Want to know how to make Coca Cola at scale? Private. Want to know what the schematic is for a Google TPU? Private. etc etc.
- jonahbenton 10mo ago
- wuliwong 10mo agoSo like any early phase, there's risk in picking a technology to use.
- smrtinsert 10mo agoExtremely likely but that doesn't mean it lacks value today
- isodev 10mo agoHow likely is it to even remember “the AI stuff” 2-3 years from now? What we’re trying to do with LLMs today is extremely unsustainable. NVidia/openai will run out of silly investors eventually…
- verelo 10mo agoYes this 100%. Every person i speak with who is excited about MCP is some LinkedIn Guru or product expert. I'm yet to encounter a seriously technical person excited by any of this.
- anthuswilliams 10mo agoI have found MCPs to be very useful (albeit with some severe and problematic limitations in the protocol's design). You can bundle them and configure them with a desktop LLM client and distribute them to an organization via something like Jamf. In the context I work in (biotech) I've found it a pretty high-ROI way to give lots of different types of researchers access to a variety of tools and data very cheaply.
- verelo 10mo agoI believe you, but can you elaborate? What exactly does MCP give you in this context? How do you use it? I always get high level answers and I'm yet to be convinced, but i would love this to be one of those experiences where i walk away being wrong and learning something new.
- anthuswilliams 10mo agoSure, absolutely. Before I do, let me just say, this tooling took a lot of work and problem solving to establish in the enterprise, and it's still far from perfect. MCPs are extremely useful IMO, but there are a lot of bad MCP servers out there and even good ones are NOT easy to integrate into a corporate context. So I'm certainly not surprised when I hear about frustrations. I'm far from an LLM hype man myself. Anyway: a lot of earlier stages of drug discovery involve pulling in lots of public datasets, scouring scientific literature for information related to a molecule, a protein, a disease, etc. You join that with your own data and laboratory capabilities and commercial strategy in order to spot opportunities for new drugs that you could maybe, one day, take into the clinic. This is traditionally an extremely time consuming and bias prone activity, and whole startups have gone up around trying to make it easier. A lot of the public datasets have MCPs someone has put together around someone's REST API. (For example, a while ago Anthropic released "Claude for Life Sciences" which was just a collection of MCPs they had developed over some popular public resources like PubMed). For those datasets that don't have open source MCPs, and for our proprietary datasets, we stand up our own MCPs which function as gateways for e.g. running SQL queries or Spark jobs against those datasets. We also include MCPs for writing and running Python scripts using popular bioinformatics libraries, etc. We bundle them with `mcpb` so they can be made into a fully configured one-click installer you can load into desktop LLM clients like Claude Desktop or LibreChat. Then our IT team can provision these fully configured tools for everyone in our organization using MDM tools like Jamf. We manage the underlying data with classical data engineering patterns, ETL jobs, data definition catalogs, etc, and give MCP-enabled tools to our researchers as front end concierge type tools. And once they find something they like, we also have MCPs which can help transform those queries into new views, ETL scripts, etc and serve them using our non-LLM infra, or save tables, protein renderings, graphs, etc and upload them into docs or spreadsheets to be shared with their peers. Part of the reason we have set it up this way is to work through the limitations of MCPs (e.g. all responses have to go through the context window, so you can't pass large files around or trust that it's not mangling the responses). But also we do this so as to end up with repeatable/predictable data assets instead of LLM-only workflows. After the exploration is done, the idea is you use the artifact, not the LLM, to intact with it (though of course you can interact with the artifact in an LLM-assisted workflow as you iterate once again in developing a yet another derivative artifact). Some of why this works for us is perhaps unique to the research context where the process of deciding what to do and evaluating what has already been done is a big part of daily work. But I also think there are opportunities in other areas, e.g. SRE workflows pulling logs from Kubernetes pods and comparing to Grafana metrics, saving the result as a new dashboard, and so on. What these workflows all have in common, IMO, is that there are humans using the LLM as an aid to dive understanding, and then translating that understanding into more traditional, reliable tools. For this reason, I tend to think that the concept of autonomous "agents" is stupid, outside of a few very narrow contexts. That is to say, once you know what you want, you are generally better off with a reliable, predictable, LLM-free application, but LLMs are very useful in the prices of figuring out what you want. And MCPs are helpful there.
- vessenes 10mo agoI've built a number of MCP servers, including an MCP wrapper. I'd generally recommend you skip it unless you know you need it. Conversely, I'd generally recommend you write up a couple skills ASAP to get a feel for them. It will take you 20 minutes to write and test some. MCP does three things conceptually: it lets you build a bridge between an agent and <something else>, it specifies a UI+API layer between the bridge and the LLM, and it formalizes the description of that bridge in a tool-calling format. It's that UI+API layer that's the biggest pain in the ass, in my opinion. Sometimes you need it; for instance, if you wanted an agent to access your emails, a high quality MCP server that can't destroy your life through enthusiastic tool calling makes sense. If, however, you have, say a CLI tool or simple API that's reasonably self documenting and you're willing to have it run, and/or if you need specific behavior with a different context setting, then a skill can just be a markdown file that explains what, how, why.
- throwup238 10mo agoAgreed. I use only one MCP server regularly and it’s a custom one integrated into my QT desktop app. It has tools for inspecting the widget tree, using selectors to click/type/etc, and take screenshots. Functionality that would otherwise be hard or impossible to reliably implement using CLI calls but gives Claude a closed feedback loop. All public MCP server I’ve seen have been a disaster with too many tools and tokens polluting the context. It’s really most useful when you need tight integration with some other environment and can write a little custom wrapper to provide it.
- deaux 10mo ago> All public MCP server I’ve seen have been a disaster with too many tools and tokens polluting the context. People like to shit on Copilot's UX but something it does well is making it incredibly easy to switch off individual tools you don't need per MCP server. In general I've found its MCP story the best out of all of them (Codex/CC/Gemini), it utilizes VSCode extensions integration very well.
- deaux 10mo agoIf you know you need them though, do use them. There are four MCP servers I use regularly and they're enormously useful. They're all around the same topic though - pulling in context/data from sources. One is dual-use, in that I occasionally also use it for things like dashboard generation. I will say, when using MCP be selective about which tools you enable. A lot of the time they come with say 30 tools and you only personally care about 5 of them. The other 25 are just rotting your context.
- adw 10mo agoSkills are just prompt conventions; the exact form may change but the substance is reasonable. MCP, eh, it’s pretty bad, I can see it vanishing. The agent loop architectural pattern (and that’s the relevant bit) is going to continue to matter. There will be new patterns for sure, but tool calling plus while loop (which is all an “agent” is) is powerful and highly general.
- irrationalfab 10mo agoAgent/MCP/Skills might be "Netscape-y" in the sense that today's formats will evolve fast. But Netscape still mattered: it lost the market, not the ideas. The patterns survived (JavaScript, cookies, SSL/TLS, progressive rendering) and became best practices we take for granted. The durable pattern here isn't a specific file format. It's on-demand capability discovery: a small index with concise metadata so the model can find what's available, then pull details only when needed. That's a real improvement over tool calling and MCP's "preload all tools up front" approach, and it mirrors how humans work. Even as models bake more know-how into their weights, novel capabilities will always be created faster than retraining cycles. And even if context becomes unlimited, preloading everything up front remains wasteful when most of it is irrelevant to the task at hand. So even if "Skills" gets replaced, discoverability and progressive disclosure likely survive.
- veunes 10mo agoThe space is moving fast enough that everything feels provisional
- eddybenchek 10mo agoI've found the "too many tools polluting context" problem to be real. The challenge is that MCP servers often expose everything upfront, even when you only need a subset. The on-demand capability discovery pattern 'irrationalfab' mentioned makes sense having a lightweight index that the model can query, then pulling full tool details only when needed. This mirrors how we actually work with APIs we don't load all endpoints into memory, we discover them as needed.