Comment by nostrebored

7 days ago

Why are they not calling APIs directly with strictly defined inputs and outputs like every other internal application?

The story for MCP just makes no sense, especially in an enterprise.

MCP is an API with strictly defined inputs and outputs.

  • This is obviously not what it is. If I give you APIGW would you be able to implement an MCP server with full functionality without a large amount of middleware?

    • I’ve implemented an MCP tool calling client for my application, alongside OAuth for it. It was hard but no harder than anything else similar. I implemented a client for interference with the OpenAI API spec for general inference providers, and it was similarly as hard. MCP. SDKs help make it easy; MCP servers are dead simple. Clients are the hard part, IMO.

      MCP is basically just an RPC API that uses HTTP and JSON, with some other features useful for AI agents today.

    • If I gave you that could you implement Graphql from scratch without a large amount of middleware? Or are we now saying graphql api:s are not api:s?

  • Does MCP support authentication, SSO?

    • Yes it’s literally just standard OAuth that’s defined in the MCP spec. I spent this week implementing an auth layer for my app’s MCP client gateway.

MCP really only makes sense for chatbots that don’t want to have per session runtime environments. In that context, MCP makes perfect sense. It’s just an adapter between an LLM and an API. If you have access to an execution engine, then yes CLI + skills is superior.

  • Only is doing a lot of work here. There are tons of use cases aside from local coding assistants, e.g., non-code related domain specific agentic systems; these don’t even necessarily have to be chatbots.

    • OP's point is about per session sandboxes, not them necessarily being "chatbots". But if you don't burry the agent into a fresh sandbox for every session you have bigger problems to worry about than MCP vs CLI anyway