Comment by krackers

>MCP exposes capabilities and Skills may shape how capabilities are used.

This is my understanding as well. What most people seem to ultimately be debating is "dedicated tool calls" (which is what MCP boils down to) versus a stateful environment that admits a single uber-tool (bash) that can compose things via scripting.

I guess this is what riles people up, like emacs vs vim. Some people see perfectly good CLI tools lying around and don't see why they need to basically reimplement a client against API. Others closer to the API provider side imagine it cleaner to expose a tailored slim-down surface. Devs that just use claude code on a laptop think anything other than CLI orchestration is overcomplicating it, while others on the enterprise side need a more fine-grain permission model and don't want to spin up an entire sandbox env just to run bash.

It's also not either or. You can can "compose" regular tool calls as well, even without something as heavy weight as an entire linux env. For instance you could have all tools exposed as FFI in QuickJS or something. The agent can invoke and compose tools by writing and executing JS programs. How well this works depends on the post-training of the model though, if agents are RL'd to emit individual tool calls via

    <tool>{"myTool": {"arg1": 1}}</tool>
    <tool>{"myTool": {"arg1": 2}}</tool>

tokens, then they're probably not going to be as successful shoving entire JS scripts in there like

   <tool>
      const resp1 = myTool(1);
      const resp2 = myTool(2);
      console.log(resp1, resp2);
   </tool>