[ondrsh]

It seems like you're describing a scenario where you know at design-time which tools will be included. In that case the benefit of using MCP is less clear.

While you usually get tools that work out of the box with MCP (and thus avoid the hassle of prompting + testing to get working tool code), integrating external APIs manually often results in higher accuracy and performance, as you're not limited by the abstractions imposed by MCP.

[peab]

any API can be modeled as JSON in, JSON out, which you can pass to the system prompt at design time or at runtime, no?

[ondrsh]

I'm not sure I fully understand your scenario. Who will be doing the actual network requests?

MCP is basically a trifecta of:

  1) MCP-aware LLM applications
  2) MCP clients
  3) MCP servers

The LLM application is key here. It is doing all the "plumbing", like spawning MCP clients to connect to MCP servers — similar to how your web browser is spawning HTTP clients to connect to HTTP servers. The LLM application thus initiates and receives the actual requests between MCP client and MCP server, manages MCP client/server pairs, injects tool results into the LLM context et cetera. This means the LLM application must be MCP-aware at design-time. But because all of this plumbing can then happen at runtime under the hood, the user (who adds MCP tools while the application is running) does not need to be a developer.

As a developer, MCP allows you to write:

  1) MCP-aware LLM applications
  2) MCP servers

MCP-aware LLM applications (like Claude Desktop or Cursor) let their users add arbitrary functionality (i.e. other MCP servers) at runtime.

MCP servers can be added by users of MCP-aware LLM applications at runtime.

Both evolve around the concept of giving non-developers a way to add functionality at runtime. Most developers are confused about MCP because they don't need to do neither 1) nor 2), instead they themselves add tools to the applications they write (at design-time) and then ship it.