agree!

> The part where you are providing 100 tools instead of a few really flexible tools

I'm not sure how that solves the issue. The shape of each individual tool will be different enough that you will need different schema - something you will be passing each time in MCP and something you can avoid in CLI. Also, CLI's can also be flexible.

> The part where you think your agent is going to know how to use 100 CLI tools that are not already in its training dataset without using extra turns walking the help content to dump out command names and schemas

By CLI's we mean SKILLS.md so it won't require this hop.

> The part where, without a schema defining the inputs, the LLM wastes iterations trying to correct the input format.

What do we lose by one iteration? We lose a lot by passing all the tool shapes on each turn.

> The part where, not having the full picture of the tools, your odds of it picking the same tools or the right tools is completely gambling that it outputs the right keywords to trigger the tool to be used.

we will use skills

> The part where you forgot to mention that for your agent to know that your 100 CLI tools exist, you had to either provide it in context directly, provide it in context in a README.md, or have it output the directory listing and send that off to the LLM to evaluate before picking the tool and then possibly expanding the man pages for several tools and sub commands using several turns.

skills

I would want to know what point I missed. I can have 100 CLI's but not 100 MCP tools.

100 MCP tools will bloat the context whereas 100 CLI's won't. Which part do you disagree with?

>Or...just don't slam 100 tools into your agent in the first place.

But I can do them with CLI so that's a negative for MCP?

but you need to _install_ a CLI. with MCP, you just configure!