if you're running an MCP file just to expose local filesystem resources, then it's probably obsolete. but skills don't cover a lot of the functionality that MCP offers.

What bugs me: if we're optimizing for LLM efficiency, we should use structured schemas like JSON. I understand the thinking about Markdown being a happy medium between human/computer understanding but Markdown is non-deterministic for parsing. Highly structured data would be more reliable for programmatic consumption while still being readable.

*I use a TUI to manage the context.

Over time I would systematically create separate specialized docs around certain topics and link them in my CLAUDE.md file but noticeably without using the "@" symbol which to my understanding always causes CLAUDE to ingest the linked files resulting in unnecessarily bloating your prompt context.

So my CLAUDE md file would have a header section like this:

  # Documentation References

  - When adding CSS, refer to: docs/ADDING_CSS.md
  - When adding or incorporating images, refer to: docs/ADDING_IMAGES.md
  - When persisting data for the user, refer to: docs/STORAGE_MANAGER.md
  - When adding logging information, refer to: docs/LOGGER.md

https://github.com/anthropics/skills/blob/main/document-skil...

There are many edge cases when writing / reading Excel files with Python and this nails many of them.

MCP gives the LLM access you your APIs. These skills are just text files with context about how to perform specific tasks.

Now wherever they're able to convert that house of cards into a solid foundation or it eventually spectacularly falls over will have to be seen over the next decade.

RAG was originally about adding extra information to the context so that an LLM could answer questions that needed that extra context.

On that basis I guess you could call skills a form of RAG, but honestly at that point the entire field of "context engineering" can be classified as RAG too.

Maybe RAG as a term is obsolete now, since it really just describes how we use LLMs in 2025.

"Skills work through progressive disclosure—Claude determines which Skills are relevant and loads the information it needs to complete that task, helping to prevent context window overload."

So yeah, I guess you're right. Instead of one humongous AGENTS.md, just packaging small relevant pieces together with simple tools.

You can drive one or two MCPs off a model that happily runs on a laptop (or even a phone). I wouldn't trust those models to go read a file and then successfully make a bunch of curl requests!

Were also at the point where the LLMs can generate MCP servers so you can pretty much generate completely new functionalities with ease.

Rather than define skills and execution agents, letting a meta-Planning agent determine the best path based on objectives.

I don't mean to be unreasonable, but this is all about managing context in a heavy and highly technical manner. Eventually models must be able to augment their training / weights on the fly, customizing themselves to our needs and workflow. Once that happens (it will be a really big deal), all of the time you've spent messing around with context management tools and procedures will be obsolete. It's still good to have fundamental understanding though!

But I suppose yeah, why not just write clis and have an llm call them

You can drop the new markdown files directly into your ~/.claude/skills directory.

There’s a fundamental misalignment of incentives between publishers and consumers of MCP.

- bundled instructions, covering complex iteractions ("use the id from the search here to retrieve a record") for non-standard tools

- custom MCPs, the ones that are firewalled from the internet, for your business apis that no model knows about

- centralized MCP services, http/sse transport. Give the entire team one endpoint (ie web search), control the team's official AI tooling, no api-key proliferation

Now, these trivial `npx ls-mcp` stdio ones, "ls files in any folder" MCPs all over the web are complete context-stuffing bullshit.

As is often the case, every product team is told that MCP is the hot new thing and they have to create an MCP server for their customers. And I've seen that customers do indeed ask for these things, because they all have initiatives to utilize more AI. The customers don't know what they want, just that it should be AI. The product teams know they need AI, but don't see any meaningful ways to bring it into the product. But then MCP falls on their laps as a quick way to say "we're an AI product" without actually having to become an AI product.

If I learned how to say "hello" in French today and also found out I have stage 4 brain cancer, they are completely different things but one is a bigger deal than the other.

Funnily enough, this was the result: `6.1% mod 3 °F (degrees Fahrenheit) (2015-2019 American Community Survey 5-year estimates)`

I wonder how that was calculated...

As the old adage goes: "Don't hate the player, hate the game?"

To actually respond: this isn't for the median user. This is for the 1% user to set up useful tools to sell to the median user.

For consumers, yes. In B2B scenarios more complexity is normal.

It might be superficial but it's still state of the art.

There is no problem to solve. These days, solutions come in a package which includes the problems they intend to solve. You open the package. Now you have a problem that jumped out of the package and starts staring at you. The solution comes out of the package and chases the problem around the room.

You are now technologically a more progressed human.

My fairly negative take on all of this has been that we’re writing more docs, creating more apis and generally doing a lot of work to make the AI work, that would’ve yielded the same results if we did it for people in the first place. Half my life has been spent trying to debug issues in complex systems that do not have those available.

I don't see how this is bad. Technology makes iterative, marginal improvements over time. Someone may make a video tomorrow claiming a great new frontend framework, even though they made that exact video about Nextjs, or React before that, or Angular, or JQuery, or PHP, or HTML.

>Something in tech went very wrong at some point, and as soon as money men flood the field we get announcments like this

If it weren't for the massive money being poured into AI, we'd be stuck with GPT-3 and Claude 2. Sure, they release some duds in the tooling department (although I think Skills are good, actually) but it's hardly worthy of this systemic rot diagnosis you've given.

What is the "real problem"?

In the pursuit of making application development more productive, they ARE solving real problems with mcp servers, skills, custom prompts, etc...

The problems are context dilution, tool usage, and awareness outside of the llm model.

> People want to log in to an account, tell the thing to do something, and the system figures out the rest.

At a glance, this seems to be a practical approach to building up a personalized prompting stack based on the things I commonly do.

I’m excited about it.

Tool calling was a thing before MCP, but the models weren't very good at it. MCP almost exactly coincided with the models getting good enough at tool calling for it to be interesting.

So yeah, I agree - most of the MCP excitement was people learning that LLMs can call tools to interact with other systems.

I still plan to ship an MCP for one of my products to let it interact with the wider ecosystem, but as an end-user I'm going to continue mostly using Claude Code without them.