201–210 of 415 posts
Earlier quoted context omitted.
My main complaint with mcp is that it doesn't compose well with other tools or code. Like if I want to pull 1000 jira tickets and do some custom analysis I can do that with cli or api just fine, but not mcp.
Right, that feels like something you'd do with a script and some API calls. 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.
Where I DO see MCPs getting actual use is when the auth story for something (looking at you slack, gmail, etc) is so gimped out that basically, regular people can't access data via CLI in any sane or reasonable way. You have to do an oauth dance involving app approvals that are specifically designed to create a walled garden of "blessed" integrations.
The MCP provider then helpfully pays the integration tax for you (how generous!) while ensuring you can't do inconvenient things like say, bulk exporting your own data.
As far as I can tell, that's the _actual_ sweet spot for MCPs. They're sort of a technology of control, providing you limited access to your own data, without letting you do arbitrary compute.
I understand this can be considered a feature if you're on the other side of the walled garden, or you're interested in certain kinds of enterprise control. As a programmer however I prefer working in open ecosystems where code isn't restricted because it's inconvenient to someone's business model.
Earlier quoted context omitted.
> MCP is the absolute best and most effective way to integrate external tools into your agent sessions Nope. The best way to interact with an external service is an api. It was the best way before, and its the best way now. MCP doesn't scale and it has a bloated unnecessarily complicated spec. Some MCP servers are good; but in general a new bad way of interacting with external services, is not the best way of doing i…
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 creat…
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.
Don't focus on what you prefer: it does not matter. Focus on what tool the LLM requires to do its work in the best way. MCP adds friction, imagine doing yourself the work using the average MCP server. However, skills alone are not sufficient if you want, for instance, creating the ability for LLMs to instrument a complicated system. Work in two steps: 1. Ask the LLM to build a tool, under your guide and specification…
I completely agree with you. There was a recent finding that said Agents.md outperforms skills. I'm old school and I actually see best results by just directly feeding everything into the prompt context itself.
https://vercel.com/blog/agents-md-outperforms-skills-in-our-...
Earlier quoted context omitted.
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.…
[flagged]
I still use vanilla Claude Code without MCP or skills, am I in the minority? Not trying to be a luddite.
An agent will eventually forget, or hallucinate, guardrails and requirements. Yes to AGENTS.md, but when you're actively managing the whole context window in a long-running task you don't want to just keep jamming stuff in there and hope for the best. Skills help budget tokens and stabilize around specific outcomes.
If your use case is not agentic, as you build a skill corpus you can begin having the model reason at higher and higher levels about the outcomes you're aiming at.
Eg: I'm super lazy now and ask Claude to launch the project instead of just running the command myself. This is probably best done as a skill.
I still use vanilla Claude Code without MCP or skills, am I in the minority? Not trying to be a luddite.
Me too just use AGENTS.md and it seems to work. I don't understand what problem MCP is trying to solve and skills just sounds like something you can do in AGENTS.md What am I missing out on?
Earlier quoted context omitted.
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…
The same thing plays out at the language layer. The pain of C++ multiple inheritance drove people toward better abstractions. If LLM's absorb that friction before it reaches anyone, the signal that produces the next Go never gets felt by the people who could act on it.
Wrote about where that leads: https://blog.covet.digital/a/the_last_language_you_can_read....
Is MCP for in-house LLMs or can it work with ChatGPT as well? As far as I know it's a server with small self-contained task scripts. But don't get how the coordination works and how it's used.