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

MCP vs. API Explained

norahsakal.com

Post reply on HN
Print view View original

71–80 of 119 posts

Re: MCP vs. API Explained

#71

Post by dinkumthinkum »

nsonha wrote: post #22
rsp1984 wrote: post #16

To be honest I don't understand why this is needed. All the leading AI models can already write code that interfaces perfectly with well-known APIs, and for the niche-APIs I can supply the docs of that API and the model will understand. So all that's needed are API docs. Or what am I missing?

Sorry but I'm extremelly annoyed with this idiotic take that many people seem to have. Is it that easy to prompt AI to write code and call an API predictably?

I am somewhat shocked by the level of incredulity people are having in this thread toward having an alternative to traditional APIs for use with LLMs. It is a lot of the same "If the AI is incapable of then why would anyone use it?". I guess I don't see what the big deal is in having a more robust standard for interfacing with a system such as LLMs. Do they fear the engineering effort is orders of magnitude? I mean really, I think it is more of an anti-AI or anti-LLM sort of sentiment, which, frankly, I am quite sympathetic to, but this is sort a bad argument or position to have.

Re: MCP vs. API Explained

#72

Post by StressedDev »

risyachka wrote: post #33

So how does MCP differ from a regular library like aisuite or vercel ai sdk? Regular SDK lib: - Integration Effort: just like MCP - Real-Time Communication - Sure - Dynamic Discovery - obviously. just call refresh or whatever - Scalability - infinite, it is a library - Security & Control - just like mcp i trully don't get it

I suspect that an MCP is just a rebranded API. We have also seen these sorts of extensibility mechanisms before. Browser extensions, Object Linking and Embedding, Dynamic Data Exchange, and Visual Studio Code extensions are all examples of having a standard API which allows lots of different things to plug into it.

Re: MCP vs. API Explained

#73

Post by saurik »

pests wrote: post #64
nsonha wrote: post #56

Earlier quoted context omitted.

> Keep throwing more "tools" at it and hope to start building stuff on top of it Yes and it's working? People ARE CURRENTLY building things. They are NOT currently whinning that LLM is not smart enough so they must sit and wait for the next model to be able to code any problem, (again RELIABLY) on demand. > People are trying to get these things to do complex multi-step reasoning tasks, including making changes to the…

I feel like you are being overly hostile and you and saurik are both arguing the same point... maybe? Following this thread has not been easy, not sure which positions each of you are even defending.

I honestly clearly don't understand the downstream disagreement myself, am getting tired of being shouted at today, and feel like entering this part of the thread by replying to someone who was clearly already past their breaking point to defend what they had already claimed was an "idiotic take that many people seem to have", was a mistake ;P.

Re: MCP vs. API Explained

#74

Post by westoncb »

electroly wrote: post #23
campbel wrote: post #9

The most important thing for developers to understand when it comes to MCP: MCP is a protocol for dynamically loading additional capabilities into an AI application, e.g. Claude Desktop, Cursor, Highlight.ai etc... If you are building your own applications, you can simply use "Tools APIs" provided by the LLM directly (e,.g. https://platform.openai.com/docs/assistants/tools ). MCP is not something most people need to…

I saw you were downvoted and could not understand why, so I'm both upvoting and replying. This is all correct. MCP is, realistically speaking, the extension API for Claude Desktop and Cursor. It's really cool if you do want to extend those apps, but that's all it's for. The article in this case is really confusing and unnecessary.

This is mistaken. It was effectively true until recently but all kinds of people are building things with it now. This article is likely on HN today because there has been a surge of general interest lately. Here's another example: https://github.com/block/goose. MCP servers are a bit heavyweight but most common case is probably using those developed and/or hosted by others. Clients (e.g. Cursor, Claude Desktop) on the other hand will likely be widespread before long.

Re: MCP vs. API Explained

#75

Post by rwoerz »

norsak wrote: post #63
1116574 wrote: post #7

The article has the same usb-c photo three times, but doesn't actually explain what it is, or how it works.

Author here – fair point! I can def see how it could've used more explanation. I'll update the post - appreciate the heads-up!

How many R's are in "strawberry"? ;)

Re: MCP vs. API Explained

#76

Post by mirekrusin »

nsonha wrote: post #25
gsibble wrote: post #10

Earlier quoted context omitted.

Absolutely correct. You can also use tools everywhere while clients have to be MCP compatible. MCP is not all it's cracked up to be.

It's crack up to be because tools need to be hard-coded. MCP is not. When computer use was demoed it seems like a big deal. However, with MCP, any one can create and MCP server and run it on their computer and hook it up to an MCP compatible client, regardless of the model.

Nobody says that your tools declaration must be hardcoded – you can resolve them at runtime. MCP simply describes convention on how to do it. The benefit is that you can write your own provider this way and if you follow this convention anybody can use it easily similarly to how people can use published packages (npm, python package etc.) that follow their publish/consume conventions.

Their config manifest is like package.json's dependencies.

Their init is like import resolution.

Jsonrpc methods are like exported functions in package.

Json schema declarations are like type declarations (ie. .d.ts) files.

In your config manifest you specify "imports" that llm can use and it handles populating tools - it's like npm for llm sessions.

Re: MCP vs. API Explained

#77

Post by electroly »

westoncb wrote: post #74
electroly wrote: post #23

Earlier quoted context omitted.

I saw you were downvoted and could not understand why, so I'm both upvoting and replying. This is all correct. MCP is, realistically speaking, the extension API for Claude Desktop and Cursor. It's really cool if you do want to extend those apps, but that's all it's for. The article in this case is really confusing and unnecessary.

This is mistaken. It was effectively true until recently but all kinds of people are building things with it now. This article is likely on HN today because there has been a surge of general interest lately. Here's another example: https://github.com/block/goose . MCP servers are a bit heavyweight but most common case is probably using those developed and/or hosted by others. Clients (e.g. Cursor, Claude Desktop) on…

My involvement level here is "I'm deep into the implementation and use of my own MCP server," I very much already knew about Goose. I don't think OP or I made our point clear here if you're seeing Goose as a counterargument. Goose is just another MCP client like Cursor and Claude Desktop and MCP is, indeed, its extension API. As OP said, if you are writing your own app that interacts directly with a model API, rather than using a generic app that specifically offers AI agent capability with an extension API, then you'll need to use the model's function calling capability directly. MCP is a very thin layer on top specifically for these agent apps.

Re: MCP vs. API Explained

#78

Post by k2so »

risyachka wrote: post #33

So how does MCP differ from a regular library like aisuite or vercel ai sdk? Regular SDK lib: - Integration Effort: just like MCP - Real-Time Communication - Sure - Dynamic Discovery - obviously. just call refresh or whatever - Scalability - infinite, it is a library - Security & Control - just like mcp i trully don't get it

Beyond the developer, the user massively benefits from MCP. Like you said, using any other SDK to build is a very valid approach but then you are tied down to a single client that you have built on that SDK.

If you would like to switch clients, then you have build it yourself. MCP solves this very well since, any MCP supported client can use the same tools/resources that you have built.

Re: MCP vs. API Explained

#79

Post by westoncb »

electroly wrote: post #77
westoncb wrote: post #74

Earlier quoted context omitted.

This is mistaken. It was effectively true until recently but all kinds of people are building things with it now. This article is likely on HN today because there has been a surge of general interest lately. Here's another example: https://github.com/block/goose . MCP servers are a bit heavyweight but most common case is probably using those developed and/or hosted by others. Clients (e.g. Cursor, Claude Desktop) on…

My involvement level here is "I'm deep into the implementation and use of my own MCP server," I very much already knew about Goose. I don't think OP or I made our point clear here if you're seeing Goose as a counterargument. Goose is just another MCP client like Cursor and Claude Desktop and MCP is, indeed, its extension API. As OP said, if you are writing your own app that interacts directly with a model API, rather…

I was correcting this: "MCP is, realistically speaking, the extension API for Claude Desktop and Cursor".

Re: MCP vs. API Explained

#80

Post by imtringued »

saurik wrote: post #50
nsonha wrote: post #48

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=43304457 Also > ...if an LLM is failing to do this task... It CURRENTLY fails to do so, PREDITABLY and securely. What are you gonna do about that? Keep throwing more data into it and hope to start building stuff on top, one day?

I don't understand your response as it feels like it is also my point, and something I would say to you? :( If the LLM cannot do basic tasks such as this, what are you going to do? Keep throwing more "tools" at it and hope to start building stuff on top of it? People are trying to get these things to do complex multi-step reasoning tasks, including making changes to their codebase (?!), automating behaviors as "agent…

How does the model retrieve documentation? Through an MCP server?
Post reply on HN