← Back to context

Comment by prohobo

6 days ago

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.

16 comments

prohobo

Reply
noodletheworld  6 days ago

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

  • raincole  6 days ago

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

  • prohobo  6 days ago

    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.

juped  6 days ago

Why would you put a second, jankier API in front of your API when you could just use the API?