Choosing the Right Tooling Layer for Your Agent

Selecting the right abstraction layer is not a new problem in software. It's common to have some experimental restructuring to find the right balance between being abstract enough to consolidate all the duplication that belongs together and going too far, making users jump through hoops to use your overly abstracted MiddlewareManagerAbstractFactoryProvider. There are entire books and undergraduate courses on exactly this problem: what level of abstraction is enough?

We now have a similar analog in the space of how we help our AI agents perform tasks. Do we need an MCP for that capability? A skill? Will a simple CLI tool work? The answer depends on a few questions.

Note: For more context, check out Nikita Kothari's AIE World's Fair talk from Thursday, "MCPs, CLIs, and Skills: Choosing the Right Tooling Layer for Agentic Development."

All the MCPs: The Super-Agent Approach

One option would be to load every possible MCP you might ever need access to at startup. This has the benefit of discoverability. If you're not sure what the agent might need to do and you want it to be as unattended as possible, giving access to all of those tool descriptions allows it to be flexible and combine sources and tools as needed. It also allows it to branch out and parallelize, gathering data from multiple sources at the same time.

There's a sneaky trap here, though: MCP server schemas may gobble up your context window. Nikita references example numbers where the MCP schemas for 55 tools from five MCP servers could take up about 16,500 tokens that live in your context constantly.

Skills and CLIs: The Developer's Approach

This is the full opposite end of the spectrum from the previous approach: make your agent aware of any skills that it needs and use those to instruct it on which CLI tools to use and how. Context- and speed-wise, CLI tools have a huge advantage over MCP tools. There's no extra network call to the MCP server, they eat next to no context, and the output of a CLI tool is reasonably predictable. Additionally, if the agent is running locally, you get the benefit of being familiar with its environment and being able to step in and help it along if things get stuck.

The drawback here is security. CLI tools are one of the highest-risk tools for an agent to use because, by definition, if it can access a CLI tool, it can access the shell itself. It's not an unmanageable risk; with careful sandboxing and attention to permissions, the risk can be managed. You also have to be cognizant of what sort of credential issues you may be signing on for. You need to be aware of what credential files the agent has access to, and whether the roles for those credentials are appropriate for its actions.

Why Not Both: The Hybrid Approach

If you have enough MCP servers and tools that it's eating enough of your context to be problematic, you can combine both of the above: bundle your MCP tool usage into skills to avoid the token bloat. Modern clients don't necessarily bundle the entire schema into the context if it's large enough. They do a mixture of caching and compaction/indexing so that they inject just the bare minimum and then load the actual tool schema as needed. If you wrap your process in a skill that describes exactly what tools it needs and how to use them, your client can unpack just the schemas for those tools more fully, saving you context and a bit of load time. This is often the best choice if it warrants the little bit of extra configuration work.

It Depends

So which one should you stick to as the right choice? We started with a storied computer science question, and we're ending with a storied computer science answer: it depends. It depends on what the environment is, what kind of tasks you're trying to accomplish, whether there are CLI tools for the functionality you need, and what your organizational auth/governance requirements are. MCPs are definitely more secure and more governable. CLIs are definitely faster and more reliable. The answer probably lies somewhere in the middle for your use case. The main takeaway here may actually be that the ability to write and maintain really good Skills is a huge advantage.

If you want to do more research into this topic, the Firecrawl blog has a much more comprehensive deep dive into the differences, benefits, and drawbacks of each approach.