7 ms·

Let's say I made a calendar app that stores appointments for you. It's local, installed on your system, and the data is stored in some file in ~/.calendarapp.

by prohobo 5mo ago

Let's say I made a calendar app that stores appointments for you. It's local, installed on your system, and the data is stored in some file in ~/.calendarapp. 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.

frotaur 5mo ago
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.
- prohobo 5mo 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.
  - noodletheworld 5mo 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.
    - prohobo 5mo 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.
      - noodletheworld 5mo ago
        [flagged]
        prohobo 5mo ago
        You do understand that what it sounds like you're talking about is essentially a proto-MCP implementation right? Except more manual work involved.
        throwanem 5mo ago
        This has devolved into "MCP is web scale." https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
        prohobo 5mo ago
        You're clearly very intelligent and a real software engineer, maybe you can explain where I'm wrong?
        throwanem 5mo ago
        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.
  - juped 5mo ago
    Why would you put a second, jankier API in front of your API when you could just use the API?
saberience 5mo ago
You realize you can just create your own tools and wire them up directly using the Anthropic or OpenAI APIs etc? It's not a choice between Skills or MCP, you can also just create your own tools, in whatever language you want, and then send in the tool info to the model. The wiring is trivial. I write all my own tools bespoke in Rust and send them directly to the Anthropic API. So I have tools for reading my email, my calendar, writing and search files etc. It means I can have super fast tools, reduce context bloat, and keep things simple without needing to go into the whole mess of MCP clients and servers. And btw, I wrote my own MCP client and server from the spec about a year ago, so I know the MCP spec backwards and forwards, it's mostly jank and not needed. Once I got started just writing my own tools from scratch I realised I would never use MCP again.
redsocksfan45 5mo ago
[dead]

by prohobo 5mo ago

frotaur 5mo ago

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.

prohobo 5mo 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.
- noodletheworld 5mo 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.
  - prohobo 5mo 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.
    - noodletheworld 5mo ago
      [flagged]
      - prohobo 5mo ago
        You do understand that what it sounds like you're talking about is essentially a proto-MCP implementation right? Except more manual work involved.
        throwanem 5mo ago
        This has devolved into "MCP is web scale." https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
        prohobo 5mo ago
        You're clearly very intelligent and a real software engineer, maybe you can explain where I'm wrong?
        throwanem 5mo ago
        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.
- juped 5mo ago
  Why would you put a second, jankier API in front of your API when you could just use the API?

saberience 5mo ago

You realize you can just create your own tools and wire them up directly using the Anthropic or OpenAI APIs etc? It's not a choice between Skills or MCP, you can also just create your own tools, in whatever language you want, and then send in the tool info to the model. The wiring is trivial. I write all my own tools bespoke in Rust and send them directly to the Anthropic API. So I have tools for reading my email, my calendar, writing and search files etc. It means I can have super fast tools, reduce context bloat, and keep things simple without needing to go into the whole mess of MCP clients and servers. And btw, I wrote my own MCP client and server from the spec about a year ago, so I know the MCP spec backwards and forwards, it's mostly jank and not needed. Once I got started just writing my own tools from scratch I realised I would never use MCP again.

redsocksfan45 5mo ago

[dead]