Why couldn't the calendar app expose in an API the read_calendar and update_calendar functionalities, and have a skill 'use_calendar' that describes how to use the above?
Then, the minimal skill descriptions are always in the model's context, and whenever you ask it to add something to the calendar, it will know to fetch that skill. It feels very similar to the MCP solution to me, but with potentially less bloat and no obligation to deal with MCP? I might be missing something, though.
Why would I do that if the MCP already handles it? The MCP exposes the API with those tools, it explains what the calendar app is and when to use it.
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.
> The MCP exposes the API with those tools, it explains what the calendar app is
So does an API and a text file (or hell, a self describing api).
Which is more complex and harder to maintain, update and use?
This is a solved problem.
The world doesnt need MCP to reinvent a solution to it.
If we’re gonna play the ELI5 game, why does MCP define a UI as part of its spec? Why does it define a bunch of different resource types of which only tools are used by most servers? Why did not have an auth spec at launch? Why are there so many MCP security concerns?
These are not idle questions.
They are indicative of the “more featurrrrrres” and “lack of competence” that went into designing MCP.
Agents, running a sandbox, with normal standard rbac based access control or, for complex operations standard stateful cli tooling like the azure cli are fundamentally better.
How would the AI know about the calendar app unless you make the text file and attach it to the session?
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.
[flagged]
You do understand that what it sounds like you're talking about is essentially a proto-MCP implementation right? Except more manual work involved.
This has devolved into "MCP is web scale." https://youtu.be/b2F-DItXtZs
You're clearly very intelligent and a real software engineer, maybe you can explain where I'm wrong?
Sure thing! That probably won't take more than a couple years at 10-20 hours a week of tutelage, and although my usual rate for consulting of any stripe is $150 an hour, for you I'm willing to knock that all the way down to just $150 an hour.
Just give us a taste of what we'd be paying for? I'm sure you're an expert but before I commit to 2+ years of consultation I'd like to see your approach.
I've already pointed this out as the silly, purposeless argument it's become. (Or more become.) Even I at this point can't figure out who is advocating what or why, other than for the obvious ego reasons. You're bikeshedding at each other and wasting all the time and effort it requires, because no one else is enjoying it any more than you two are: if anything you have left your audience more confused than we began, but I see I repeat myself.
Show me you can stop doing that, and I'll happily mediate a technical version of this conversation that proceeds respectfully from the two of you each making a clear and concise statement of your design thesis, and what you see as its primary pros and cons.
For that I'll take a flat $150 for up to 4 hours. I usually bill by the 15-minute increment, but obviously we would dispense with that here, and ordinarily I would not, of course, offer such a remarkable discount. But it doesn't really take $150 worth of effort to remind someone that he should take better care to distinguish his engineering judgment and his outraged insecurity.
I don't get it, you joined this thread to call me an idiot with a meme, and now you're talking about being a neutral arbiter for a technical discussion that I supposedly ruined.
More than anything I'm getting frustrated with HN discussions because people just insinuate that I'm stupid instead of making substantive arguments reasoning how what I'm saying is wrong.
Are we performing for an audience or having a discussion?
I can't make heads nor tails of anyone's position in this mess, precisely because of its devolution into everyone yelling at one another. Yours happened to be the tail comment on this branch at the time I posted. Don't take it more personally than it was meant.
I understand why this website doesn't have DMs except among YC founders. But if it were otherwise, I'd have DMed you instead of posting that first comment publicly. The criticism I remain convinced has merit, but such things are better done in private. If I chose to make an example out of you over the other guy, it was because you looked like offering a better chance than he of redirecting this into the kind of discussion from which someone could conceivably learn something.
> So does an API and a text file (or hell, a self describing api).
That sounds great. How about we standardize this idea? We can have an endpoint to tell the agents where to find this text file and API. Perhaps we should be a bit formal and call it a protocol!
> How about we standardize this idea? We can have an endpoint to tell the agents where to find this text file and API
Good news! It's already standardized and agents already know where to find it!
https://code.claude.com/docs/en/skills
[dead]
Why would you put a second, jankier API in front of your API when you could just use the API?