Transcription
There's been a lot of discourse on MCPs and skills in particular. Most people think skills are meant to replace MCP or vice versa. And that could be further from the truth. They're actually very complimentary and that's what we're going to talk about in today's video.
So when we think of MCPs and skills, let's first understand what they're supposed to do. So there's you, you're communicating with this model and you're telling this model to send you a report, right? You have connected your external tools using MCP, right? your notion account, your Gmail account, your Cali, and your Stripe. And you've given the model access to these tools, the agent access to these tools via MCP. So, it should be able to generate a report for you.
Now, one thing that we've realized early on in MCP land is that the agents were terrible at this. When you gave an agent access to many tools, it would just hallucinate. It would pick the wrong one. It was not a great experience. And this is where skills come in. Skills handle the expertise, the domain knowledge, the workflow logic and turn raw tool access into reliable outcomes.
What does that mean? Let's say uh you and I go to a hardware store. We go to Home Depot and we are supposed to build out a new patio at my house. We're supposed to build a new backyard, right? We go to Home Depot. We buy all these tools. We come back to my house. So, we have these tools, but no one knows how to use them. We don't know how to use the tools. We don't know what goes first. We don't know how to what type of wood we need. Like we have all these tools, but you and I are just developers. We don't go outside. We don't work with our hands. We work with our minds.
Speaking on working with our brains, one of the smartest decisions I made was adding today's sponsor to my workflow, and that's Gravile. Now, I can tell you Grapile is being used by some of the best companies like Brex, Mintlifi, Substack, Browserbase, Clavio, Post Hog, or what I can show you is how we've been using Grapile in my product studio and my open source repos and my personal side projects.
First, let's look at my open-source project Ralphie, which is a Ralph Wigum implementation. Literally, if you look at all the closed PRs, one thing that they all have in common is the confidence score was either a four out of five or a five out of five. Meaning, every PR that's made is reviewed by Gravile. And if Grapile doesn't give you a minimum of four out of five, it is not getting merged. That's how good Grapile is.
In my product studio, one of the products we're developing for a customer, I told our developer after every PR, you can fire grabile review. I would say aim for a four out of five or a five out of five. Then I can review. And in our latest PR, he tells me finally got a five out of five.
And finally, for my side projects, I'm using Claw Code a lot. And even though Opus is great at shipping go, there are a lot of mistakes. There's a lot of slop that it generates. But with Gravile, I'm able to curb the slop down. I'm able to make sure that the code is functional, clean, and it actually works. For example, in this pull request, the PR that Claude Code made, there was a race condition in it, but Cloud Code said the code was fine. It was perfect. I tested it out. It looked good, but there was a race condition that I did not see. But because I have Gravile reviewing my PRs, not only did it catch the race condition, it offered a suggestion to fix it. And now I have a confident score of a four out of five. And Gravile also gives you the power on how serious you want these reviews to be. I have it on low, meaning I wanted to find even the most minute issue because I want my code to be perfect. That's why I use Reptile everywhere. If you want to check them out, the link will be in the description down below. They have a twoe free trial. Make sure you take it for a spin. Thank you to Reptile for sponsoring this video.
Now, let's get back to it. How am I supposed to take these tools and build a backyard, right? This is where skills come in. Skills give the agent the exact step by step, the exact SOP standard or procedure to take when doing a certain action. So let's say in this case I have a skill that's called send a report skill and this skill tells the model first you go to notion you query uh the last five meeting notes and then you summarize those notes and then you send emails to whoever needs to send emails and then you book a call and then you send an invoice to a client.
So you can think of skills as a way of training your model, training your agent to do the exact step by step that you wanted to do instead of like cuz can you imagine if we had no skills here and we told the agent send a report. What does that even mean? How do I send a report? A report of what? I have all these tools, right? This is why the models were hallucinating back when it was just MCPs. But now that you have skills in the picture, MCPs become a lot more useful, a lot more effective, and a lot more interesting to look at.
Now, to simply summarize, skills capture the knowledge that would otherwise live in your head or that gets reexplained every time someone new joins the team. They work best for multiplestep workflows involving tools, meeting prep that pulls from multiple sources, then create structured documents, processes where consistency matters, domain expertise when you want to capture and share, workflows that should survive when the team members leave.
So again, skills are the instructions, right? They're the instructions on what to do. Step one, step two, step three, step four. But then MCP servers are what give you access to the tools. It gives you access to the data, right? You can think of examples here like real-time data access, actions in external systems, file operations, API integrations.
I'm actually working on this neat little tool. It's open source. The link will be in the description down below. And it's basically an AI builder, like an MCP builder using AI. An example here is I dropped in the Daytona sandbox repo and I asked AI to basically build me an MCP server and it noticed that it required an API key, right? So my Daytona account, my specific API key is passed in to this server. So whenever I call this MCP server, whether it's on cloud code or cloud desktop, whatever it is, it's going to have access to my Daytona account. So I can get stats, I can get information, how many sandboxes are active, all that type of stuff, right? So MCP allows me to get my data to get me access to my tools. Skills allow it so that the model knows exactly how to use the tools and the data I have given it access to. So you see one doesn't replace the other. They actually fit in perfectly together.
Now one big issue we had with MCPS early on it was the context build, right? It took so much context from the model that the models were just not good at calling or using MCP servers. But skills solve this. Here's how. It says here at its simplest, a skill is a directory that contains a skill.md file. This file must start with YAML formatterater that contains some required metadata name and description. And at startup, the agent preloads the name and the description of every installed skill into its system prompt. This metadata is the first level of progressive disclosure. It provides just enough information for Claw to know when each skill should be used without loading all of it into context. The actual body of this file is the second level of detail. If Claw thinks the skill is relevant to the current task, it will load the skill by reading the full skill.md into context.
Now, this is a topic you might have heard progressive disclosure and basically the way skill files works or the skill system works with these agents is that a skill.md file contains a YAML section and then the rest is markdown. Now, when the model loads up, it's only going to load up the YAML format, the name and the description. And the reason why this is important is the model only needs to know the name of the skill and what the skill does. It doesn't need the contents of the skill. It doesn't need the step by step. It just needs to know the name and what it does. That's enough information for when I request specific expertise from the model that it knows the name, it knows the description. Now that it knows I'm calling for that specific skill, it can then load in the rest of the document. And this is what is called progressive disclosures. This is what makes skills awesome.
So when I have a skill.mmd file that tells the model let's say for example I have like again a send a report skill and it that's what it's called and when I tell the model send a report it loads in the entire skill and in the markdown I can say call this MCP server you have access to it get this data query this summarize this parse through this now I'm going to get a much better output and here's what's cool let's say we have a super complex skill what you can do here it says as skills grow in complexity They may contain too much context to fit into a single skill MD file or the context that's relevant only in specific scenarios. In these cases, skills can bundle additional files within the skill directory and reference them by the name from skill.md. These additional linked files are the third level of detail which Claude can choose to navigate and discover only as needed.
So you can see in this example I have my YAML formatter. I have a PDF skill. The description is comprehensive PDF toolkit for extracting text, tables, merging, splitting documents, and filling out forms. Right? So when it figures out that I need this skill, it's going to ingest the markdown. And in the markdown, if you notice, it says for advanced features, JavaScript libraries, and detailed examples, see reference.md. And if you need to fill out a PDF form, read forms.md. And the reason why this is important is let's say once the skill has been ingested, the markdown's been ingested, everything in the markdown is actually not what I requested. What I want is again the need to fill a PDF form as it says right here now. It's going to reference forms.mmd. Right? So all of this isn't being loaded up into the context. I'm not experiencing context blo with skills. What it is, it's a progressive disclosure as I'm getting the information the model needs to do what I've commanded it to do.
Now, some of you might already say, "Don't MCP servers have descriptions describing the tools and stuff like that?" And I asked that same question, and Enthropic addresses it like this. It says, "MC servers may contain instructions in the form of tool usage hints and prompts for common tasks. This keeps tool specific knowledge close to the tool. However, these instructions should be kept generic by design. The rule of thumb, MCP instructions cover how to use the server and its tools correctly. Skills instructions cover how to use them for a given purpose or in a multi-server workflow. For example, a Salesforce MCP server might specify query syntax and API formats. A skill would specify which records to check first, how to cross reference them against Slack conversations for recent context, and how to structure the output for your team's pipeline review."
Now, what if we have conflicting messages, conflicting descriptions? It says here, "When combining MCP servers and skills, watch for conflicting instructions. If your MCP server says to return JSON and your skill says to return as markdown tables, Claude has to guess which one is right. Let MCP handle connectivity. Let skills handle presentation sequencing and workflow logic."
And the reason why this is all fascinating is this is the process of slowly starting to solve the context bloat issue we had when MCP servers first launched. And with all this, there's a new skills marketplace called skills.sh. And there are tons of skills. React best practices, web design guidelines, remotion best practices, right? These are basically meant to steer the model in the right direction. I believe we're entering an era where the models are getting really powerful. Now, what's necessary to make them do what you want them to do is guard rails. And skills are those guardrails. Making sure that your model goes on the right path, follows the right steps. And in order for it to interact with external data, external tools, MCP servers are the way to do it. And this is why, like I said in the beginning of the video, they complement each other. One doesn't replace the other.
And the beautiful thing of all this is the simplicity of it. Skills run in code execution environment where Claude has file system access, bash commands, and code execution capabilities. Literally, skills are files in a file system. They're like literally in a folder in a virtual machine and they get injected right into your system prompt. But remember, not the entire thing, just the name and the description. Just enough information for it to know, okay, this is the thing I need to execute what the user's commanding me to do.
Now, a couple questions you might have is, can one skill use multiple MCP servers? And according to Enthropic, yes, a single skill can coordinate multiple MCP servers at once. A technical competitive analysis skill might search Google Drive for internal research, pull competitor repos from GitHub, and gather market data via web search. Can I build multiple skills for one MCP server? Yes, you can. A skill can enhance the value you get from a single MCP connection. Notion demonstrates this pattern with separate skills for meeting prep, research, knowledge capture, and spec to implementation. So, multiple MCP servers for a single skill, multiple skills for a single MCP server.
And yeah, that's pretty much it. Hopefully after watching this video, you understand what MCP servers do. You understand what skills do. You understand the symbiotic nature between both. They're not perfect. There's still a lot of progress to be made, especially around the MCP front, but progress is indeed being made. It's an exciting time to be alive. I hope you're enjoying the content. Make sure to like, comment, subscribe, hit the notification bell. I'll see you in the next one. Peace.