Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I still prefer MCP over skills

david.coffee

Post reply on HN
Print view View original

191–200 of 415 posts

Re: I still prefer MCP over skills

#191

Post by thecupisblue »

_pdp_ wrote: post #165
thecupisblue wrote: post #161

Earlier quoted context omitted.

I am not 100% sure I follow your train of thought. Isn't in that case an API what they want? An "MCP for a local app" is just an API that exposes the internal workings of the app. An "MCP for mixpanel" is just an API that exposes Mixpanel API behind Auth. There is nothing special about them for any type of user. It's just that MCP's were "made popular". For the same type of user, I have built better and smoother solu…

You are mostly right except forgetting that not all SaaS companies want their users to shoot themselves in the foot by exposing the entire API surface and all of its quirks and risks to AI agents. Furthermore, In many cases some APIs, for better or worse, are not even sufficient. For example, the Notion MCP has full text search capabilities. Their API allows searching by title only. I don't know why but I am sure the…

Honestly it's on them, not on the users.

In today's day and age, it's absurdly easy to create a proxy API for your API that only exposes a subset of operations. And not like other "easy" things which depend on them having done "the right thing" before, like OpenAPI specs, auth scoping etc. This is so easy, even corporations consider it easy, and everything there is a PITA.

This is simple to make, to document and since it's a proxy you're also able to include all bunch of LLM friendly shenanigans and overly verbal errors with suggestions to fix.

Shit, I should obviously make a SaaS for this, huh?

Re: I still prefer MCP over skills

#192

Post by brabel »

noodletheworld wrote: post #164
prohobo wrote: post #138

Earlier quoted context omitted.

I feel like the MCP conversation conflates too many things and everyone has strong assumptions that aren't always correct. The fundamental issue is between one-off vs. persistent access across sessions: - 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…

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

You haven’t actually done that have you. If you did, you would immediately understand the problems MCP solves on top of just trying to use an API directly:

- easy tool calling for the LLM rather than having to figure out how to call the API based on docs only. - authorization can be handled automatically by MCP clients. How are you going to give a token to your LLM otherwise?? And if you do, how do you ensure it does not leak the token? With MCP the token is only usable by the MCP client and the LLM does not need to see it. - lots more things MCP lets you do, like bundle resources and let the server request off band input from users which the LLM should not see.

Re: I still prefer MCP over skills

#193

Post by raincole »

noodletheworld wrote: post #184
prohobo wrote: post #180

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…

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

Re: I still prefer MCP over skills

#194

Post by raincole »

Seriously, the only drawback of MCP is its name. If it were named "API discovery protocol" (which is what it is) none of these debates would have existed.

API vs MCP sounds like a real debate, but it really isn't. It's "API vs API discovery protocol." See how asinine it sounds if we call things for what they are.

Re: I still prefer MCP over skills

#199

Post by addandsubtract »

prohobo wrote: post #138
antirez wrote: post #108

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 feel like the MCP conversation conflates too many things and everyone has strong assumptions that aren't always correct. The fundamental issue is between one-off vs. persistent access across sessions: - 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…

Meanwhile, I'm using MCP for the LLM to lookup up-to-date documentation, and not hallucinate APIs.

Re: I still prefer MCP over skills

#200

Post by xyzzy123 »

insin wrote: post #176
xyzzy123 wrote: post #155

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.

You can make it compose by also giving the agent the necessary tools to do so. I encountered a similar scenario using Atlassian MCP recently, where someone needed to analyse hundreds of Confluence child pages from the last couple of years which all used the same starter template - I gave the agent a tool to let it call any other tool in batch and expose the results for subsequent tools to use as inputs, rather than d…

Hmm, but you can't write a standard MCP (e.g. batch_tool_call) that calls other MCPs because the protocol doesn't give you a way to know what other MCPs are loaded in the runtime with you or any means to call them? Or have I got that wrong?

So I guess you had to modify the agent harness to do this? or I guess you could use... mcp-cli ... ??

Post reply on HN