# MCPs, CLIs, and Skills: Choosing the Right Tooling Layer for Agentic Development — Nikita Kothari — session 2026-07-02T18:10:00.000Z → 2026-07-02T18:30:00.000Z

_68 transcript lines · 0 slides · source: full recording_

## Transcript

Welcome, everyone. I'm Nikita Kothari. I'm a senior member of technical staff at Salesforce, where I'm building AI driven enterprise solutions. If you might have heard of Agent Force, AgentForce was set up, headless three sixty. I worked on all, and it's like Amazing features. I also worked at Amazon and LinkedIn previously. In last six months or a year, we completely changed the way we used to work. We are building new systems. We are evolving, and there are some critical, aspect of using MCP, CLI, and skill. So today, we are, going to deep dive into a critical yet often overlooked aspect of building AI agents. It's plumbing. As a developer, we of we talk a lot about Model size sizes, reasoning capability, and the prompt engineering. But with when it comes to a building production ready AI agents, the way an agent interacts with the environment, it's tooling layer. It's what actually makes or breaks the application. We will look into three distinct approaches, which is MCP, LCLR, and the structured skill and map a clear rubric for what to use when. At the end of this talk, you will have a clear mental model for choosing between These three tooling layers. Here's something every team discovers the hard way. Building demo agent takes, like, a afternoon, but when you actually want to ship the same thing into the production, it could take a quarter because we are looking to build the reliable, secure, and fast agents. Nobody wants to leak their customers' data into the production. So testing, reliability is still a major issues with this AI agents. So, I want to talk about these three problems. The problem one is the context explosion. Consider a scenario where you load a 50 tool schemas into a agent's context window, and suddenly 60% of your thinking space is burned before even this task even starts. Your agent forgot the diff because, tool definition for monitoring databases and the deployments filed the window. It literally doesn't have a room to think. The second yet critical problem Is invisible failures. The agent made a like, consider example where agent made a seven tool calls to draft a PR. Something went wrong. The PR was created on the different race branch. So first, you lost, like, lot of time to redo the work, and the second thing is somehow you lost the confidence on your agent to perform a particular task. And the problem three is the security. Consider your example at 2AM, you got a customer. Issue, you are investigate getting a customer a's error. But wait. LLM has a broad access to the query and the tenant data, and it accidentally started looking into customer b's data. So that is a multitenant platform issue, and it's not just a bug. It's a huge compliance nightmare. So let's talk about how we can use this three, two, three layers to build the reliable, fast, and the secure, agent agents. So we have the CLI. CLI is like handling someone a screwdriver. Here is a tool. Just run it. Direct execution, the agents run a command, gets output, and moves on. Then we have a layer two, which is MCP. MCP stands for model context protocol. This is just like giving someone a USB c hub. Here is a universal adapter that works with any services. Just use this and work on it. And third, we have the skill. The skill is giving someone a runbook. Here is a step by step execution of this task. Just go and perform it. So it's structured, and it could work with any of the platform or any of the system. So CLI knows how to do the execute command directly. MCP knows what is available, and skill knows how to do it. So now let's dive deeper into one of each. CLI, they are readable. Any engineer can look at the command and see what's exactly happened. They are reproducible. If something fails at 2AM, you can copy paste the some same command, run it on Your machine, and you can reproduce the same error. And they're composable. You can pipe multiple commands into one, and you can run. The heuristic is simple. If I want to want you to remember this, if a engineer on your team can open a terminal to do this, the agent should probably able to do the same thing. We have the structural input and structured output, and it's it's highly, highly, usable. I think we have been using the CLI for more than fifty years now. So it's it's not Glamorous, but they are proven, and it works. Then we have the MCP. MCP is consider it as a universal c adapter, like, every device has its own charger, but the universal you know, USB c is standardized where you can connect any device to your, connector. So on one side, you can see you have the cloud, ChargePD, and the coding tool. And the other side, you can connect the different services like work item tracker. Code search, error tracking, monitoring. Maybe real life examples could be, Git, Slack, and Google and everything. So, at the bottom, you see, what the what this looks in practice. The agent calls the code search dot search with the query, and it gets a structural result back. So it does the it handles indexing across the millions of files and enforces the tenant. Isolation at the server level. This is how you solve the security problem too because every time you will connect the external services via MCP protocol, there is a art, and you will give, permission to access those services. Third thing is the skill. This is one of my favorite, tool, and I think I have automated all of my work that I'm doing right now at my workplace with the skill because it's highly reliable, it's fast, and you can tweak it it in a Lot of diff different way. Skill is a structural playbook that wraps around your tools. It defines the rigid orchestration. When a condition is meet, ensure the this prerequisite is exist, and then execute step one, step two, or step three sequentially using the CLIs, MCP, and explicitly handle, handle those age cases. It prevents the guesswork. It saves the memory, and it's standardizable. Like, you you only choose, like I own only want, like, two MCPs to connect to this skill, so you don't have to go and look into all of the MCPs to perform a particular task. Now, let's talk about the problem that we discussed earlier. I have a 50, MCP, tools connected to my system. So before running any task, my 15,000 to 20,000 tokens are already burned, and I lot, I lost, like, lot of context before even starting my agent. So you can see on the one side, you have, like, a whole lot of, tokens and how you could replace the same thing by using the skills. So keeping the 55 tools from the five different MCP servers active at all times that caused us it caused latency issue, platform issues. You can just simply define the number of MCP servers that that will need it to execute that particular task. So here are, like, some of the Like fixing a test failure. So you don't need to go into all of your MCP tool to just to fix one, test failure. You can only look into the logs. You can look into the release log on and a GitHub to fix your test test failure. And for the draft PR and the investigation escalation, let me dive little bit deeper into it. So consider this slide, where we are, drafting a pool request. So what do you need? You need, like, the First, agent records the draft PR skills. Step one requires the understanding of the local changes. Instead of heavy API, it hits the fast scope CLI commands, and then you you need a git command to create a, git pull request on the correct branch. So you can literally write down the steps. You can create a skill, and you can keep modifying it to achieve the best results. Then, again, another thing is the investigation of bug. If midnight to get any customer bug, I mean, the first thing you're going to do is, like, looking into the logs, searching for the error pattern, looking into the, recent releases if there is a bug in the code or things like that. So you already know that, like, what you are going to do. So you can automate everything with limited number of MCP tools and the CLI to make a world class skill to debug your customer's issue. And now let's talk about the security, a golden rule of The agentic development is enforced isolation in your infrastructure, never in your prompts. So prompt can be injected, but the infrastructure cannot. For CLIs, the blast radius is full shell excess. So you mitigate mitigation must include the sandboxing and the strict content containerization. For MCPs, the blast radius is limited to the explicitly exposing the tools and the tenant tenant isolation and that guarantees at the server level. And we have some of the principles that we can always think about while building any agent that, like, we shouldn't be sharing any credentials with our agent. The tenant isolation is the infrastructure enforced. We can always use the permission get, gets to, operate at the security level, and, we can provide the least privilege while performing any task to the agent. Now when when you are deciding which layer to use, like, every time you cannot Not create a skill or every time you cannot just explore to use all of the MCP tools. So you need to ask these three question in order to get the best results. The first one is, like, who else needs this? If it just this agent, just then use a CLI. If the multiple agents are going to use this service, then use MCP. If multiple workflow shares the same procedure, then use a skill. The second question you can ask yourself is, like, what is the failure mode that matters the most? If it's a transparent See, and the reproducibility, go for the CLI. Like, we have seen, like, how we can, like, reproduce the issues using the CLIs. While it is very difficult if you go for, the agents because you don't know what they are doing in the background, If you no need a validation in the tenant isolation, then go for the MCPs. And if you need the sequencing guardrails, then go for scale. And here are the three, third question that like, whether your your context is tight. If it's generous, then you can Go CLA. You can explore all the MCP tools and get your results. If it's very, very tight, then absolutely you need a skill layer, and on demand orchestration of the MCP tools, to save the money as well as you can improve the latency. And to wrap these things up, I want to leave you with the three foundational architecture take takeaway. Keep your context clean. Give only don't use, like, all of them. Tools available to perform any task. Give them the convert your, most of your workflows into the skills to get the best results. Portability has a cost. MCP servers are incredible, but they introduce network latency, protocol abstraction, and infrastructure complexity. So we need to pay that, cost deliberately for shared services indexing and the isolation. So choose your MCPs very wisely and Never be embarrassed by the CLIs. It's been fifty years we are using the CLIs. They are highly composable, debuggable, and battle tested. So embrace your agent framework and, convert all of your workflows into the skill. And so one one of the takeaways is, like, you know, keep your skill as a code. So whenever we are making any changes to your skill, make sure that, like, it's reviewed by the peer, peer and keep, updating it over the time, and you'll get the best. So that was for today. Thank you so much, for attending this talk. If you have any question or anything, feel free to reach out to me on LinkedIn. Thank you. Hi. I'm Amol, CEO of Nori Achentik. We deploy an AI employee that understands your company, your code, docs, Slack, and other kinds of data. We spend a lot of time thinking about how coding agents really work. Most people think coding agents only write code. But if you ask me, that's just bad marketing. Forget the name for a second. Coding agents can do almost anything. There's just one trick. You have to be able to think like an agent to get it to do what you want it to do. Today, we're gonna talk about how we use coding agents to do something most people think agents are terrible at. Make visual artifacts. Like slides, docs, and yeah even video. Every day, the world pours something like thirty four thousand human years into making slide decks. Most of that time isn't the thinking, it's the fiddling. A deck that takes ten hours should really take about twenty five minutes once you remove all the formatting and the branding and the moving things around. Say you need to make a slide. What do you do? You open a tool. Powerpoint, slides, Figma, Canva. And then you start manipulating a can. Every one of these tools is built for human hands and human eyes. Click, drag, drop, resize, snap to grid. All motions and patterns that make sense for our geospatial view of the world. There is a data structure underneath, but it's in a format that only the application can read. What happens when you hand these tools to an agent? Well, the output comes out all wrong. Things overlap in weird ways. You can't see the text. There's no alignment. It's just garbage. AI skeptics say that it's not just the tools. Agents fundamentally can't reason about space. And there are whole benchmarks like arc AGI that are built exactly around that premise. There's a famous little test for this from developer Simon Willison. He asks every new model the same thing. Can you draw a pelican riding a bicycle? But there's a trick. The agent is only allowed to use SVG. It's a quick gut check for whether a model can reason about space at all. Here's some examples of what the models actually give you on this test. And, yeah. These are pretty bad. Like, genuinely, deeply, really bad. So does that mean it's hopeless? Agents are just doomed to be bad at graphics? No, I don't think so. If you ask me, it's not the model, it's the medium. If I asked you, someone who is presumably human, to hand write an SVG of a pelican, you wouldn't be able to do that either. SVG's are just a wall of numbers. You can't go from a wall of numbers to a pelican. You just can't see that way. That's just not how people think. We think graphically. So we build tools that let us draw on a canvas. Figma MCPs, PowerPoint CLIs, screenshot and replace loops. What do all of these agent tools have in common? They all approach the problem like a human. But an AI is not a human. Asking an AI to use a canvas is like asking a Human to write SVG by hand. It doesn't really make sense. You need to give the AI tools based on how it thinks. Not in pixels, in language. Words, tokens, structure, that is its native medium. Imagine a language that's incredible at describing layout. That models have seen and trained on billions of examples of. That they understand intuitively, that renders to pixels, and can run everywhere. Right. HTML lets a model think in structure. HTML tags have meanings built into the language, a heading, a chart, a grid, and the browser turns it all into pixels. So the model never actually places a coordinate, and you can get all sorts of visual effects, charts and layouts, fonts, and motion, all of it for free. Remember that pelican from earlier? Now ask it to do the same exact task, but in HTML. Same bird, but now it's in a structure. That the model can reason about. And you can read and theme and edit every single line of it. I spent my whole life building slide decks with PowerPoint, so I always thought that those two things, slide decks and PowerPoint, were synonyms. But that's just not really true, is it? PowerPoint is a tool that you use to make slide decks. The deck itself, that's just the presentation mode. As it turns out, no one in your audience is gonna care how you got to the presentation mode. The editing format is totally arbitrary. So you can just pick the editing format that the agents are already good at, HTML, and if you need to, render to a different format like PDF later on. We use this HTML trick to build all of our slide decks, our board decks, and our sales decks. These are real things that we actually present and send out constantly. We use it for our docs too. It gives our docs color and vibrancy, all while following our brand. And of course We also use it to make videos like this one. What you're watching is just HTML and CSS. It's literally just divs all the way down. Almost everything is better with a little structure and a little bit of color. Plain text is a choice, generally a choice of convenience, but it's usually the wrong one if you're actually trying to create something of use. Now I do want to take a quick beat here and point out that a beautiful deck on its own Is generally not worth anything. You still have to go and get all of that content, all of the things that actually populate that deck. Right? Well, again, we can think like the model. If you just give the model access to your data, say your call transcripts or your emails, you can have the model build the deck end to end.

## Slides