Self-describing APIs require probing through calls, they don't tell you what you need to know before you interact with them.

MCP servers are very simple to implement, and the developers of the app/service maintain the server so you don't have to create or update skills with incomplete understanding of the system.

Your skill file is going to drift from the actual API as the app updates. You're going to have to manage it, instead of the developers of the app. I don't understand what you're even talking about.

Connected MCP tools are also always in the model's context, and it works for any AI agent that supports MCP, not just Claude Code.

Now let's say you want all your Claude Code sessions to use this calendar app so that you can always say something like "ah yes, do I have availability on Saturday for this meeting?" and the AI will look at the schedule to find out.

What's the best way to create this persistent connection to the calendar app? I think it's obviously an MCP server.

In the calendar app I provide a built-in MCP server that gives the following tools to agents: read_calendar, and update_calendar. You open Claude Code and connect to the MCP server, and configure it to connect to the MCP for all sessions - and you're done. You don't have to explain what the calendar app is, when to use it, or how to use it.

Explain to me a better solution.

MCP is more for a back and forth communication between agent and app/service, or for providing tool/API awareness during other tasks. Like MCP for Jira would let the AI know it can grab tickets from Jira when needed while working on other things.

I guess it's more like: the MCP isn't for us - it's for the agent to decide when to use.

- If you need to interact with a local app in a one-off session, then use CLI.

- If you need to interact with an online service in a one-off session, then use their API.

- If you need to interact with a local app in a persistent manner, and if that app provides an MCP server, use it.

- If you need to interact with an online service in a persistent manner, and if that app provides an MCP server, use it.

Whether the MCP server is implemented well is a whole other question. A properly configured MCP explains to the agent how to use it without too much context bloat. Not using a proper MCP for persistent access, and instead trying to describe the interaction yourself with skill files, just doesn't make any sense. The MCP owner should be optimizing the prompts to help the agent use it effectively.

MCP is the absolute best and most effective way to integrate external tools into your agent sessions. I don't understand what the arguments are against that statement?

What are you even trying to say? That these projects are totally fake? AI generated or something? Like the Moon landing was fake?

Also SpaceX, Tesla, PayPal, OpenAI, Grok and Neuralink aren't vaporware...

The claim fundamentally doesn't make any sense.

I don't really understand why these kinds of comments persist except as some pathological cope when confronted with a world that doesn't work the way you want it to.

It's not convincing, it immediately outs you as a zealot, it's counterproductive in every single way. Why keep doing it?

Explain to me how that doesn't prevent commercial use? Are you going to say "well technically it doesn't prevent it"? No one cares. Commercial projects avoid GPL like the plague.

Beyond that, marketing is harder than ever. Trying to release an app on Shopify app store without very strong marketing usually just means you drop it into a void. No one trusts any of the new apps, because they're inevitably vibecoded slop and there's no way to share your app on social media because all the grifting and shilling have totally poisoned that avenue.

Take a look at Show HN now - there are tons of releases of apps every day, but nothing gets any traction because of the hostile/weird marketing environment and general apathy. Recently, I saw the only app to graduate from New Show HN likely used a voting cartel to push it to the top. And take a guess at what that app did? It summarized HN's top stories with an AI. Something any dev could make in about 10 minutes by scraping/requesting the front page and passing it through an LLM with a "summarize this" prompt.

The entire "indiehacker" community is just devs shilling their apps to each other as well. The entire space is extremely toxic, basically. Good apps might get released but fall into a void because everyone is both grifting and extremely skeptical of each other.

Rust uses crates to import those dependencies, which was one of its biggest innovations.

This article is really attacking vague prose that pushes ambiguity onto the agent - okay, fair enough. But that's a tooling problem. What if you could express structure and relationships at a higher level than text, or map domain concepts directly to library components? People are already working on new workflows and tools to do just that!

Also, dismissing the idea that "some day we'll be able to just write the specs and the program will write itself" is especially perplexing. We're already doing it, aren't we? Yes, it has major issues but you can't deny that AI agents are enabling literally that. Those issues will get fixed.

The historical parallel matters here as well. Grady Booch (co-creator of UML) argues we're in the third golden age of software engineering:

- 1940s: abstracted away the machine -> structured programming

- 1970s: abstracted away the algorithm -> OOP, standard libraries, UML

- Now: abstracting away the code itself

Recent interview here: https://www.youtube.com/watch?v=OfMAtaocvJw

Each previous transition had engineers raising the same objections: "this isn't safe", "you're abstracting away my craft". They were right that something was lost, but wrong that it was fatal. Eventually the new tools worked well enough to be used in production.