Hacker News Reader

Comment by campbel | Hacker News Reader

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 bother with unless you are building an application that needs extension or you are trying to extend an application (like those I listed above). Under the hood the MCP is just an interface into the tools API.

View on HN

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.

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.

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.

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

Reply on news.ycombinator.com