As a developer, my introduction to programming with LLMs was GitHub Copilot in Visual Studio. Soon after, I took Claude Code for a spin. It was amazing how the chat agents could read all the files in a project and find what they needed. I noticed that Copilot, Claude, and products like Spec Kit placed special markdown files in the project that acted as instructions to the agents. Two of them were in all caps: SKILL.md and AGENTS.md.

A skill seemed simple enough. It is a set of instructions that tells the agent how to do something, like draw up a spec for a new feature. I could write a bunch of these and call one in chat by typing a forward slash and its name, like /new-spec.

That little trick goes a long way. Many coding agents follow the same standard from agentskills.io. Visual Studio now discovers skills on its own. AGENTS.md works in a similar fashion, but instead of skills it holds project context, conventions, and role definitions.

But what about tools? Copilot's UI shows the tools it includes, but there is no TOOLS.md file. What gives? Huh, well, so what. Skills could do so much, so I just made everything a skill.

And I'm not the only one. Amongst my bloated skill library is one I downloaded from the community. It transcribes audio locally with Whisper. Underneath, it is a 3,000-line Python script. On top sits a 1,100-line SKILL.md explaining how to call it. It's so slow, my fix was to add a paragraph at the top saying to try captions first.

Understood.

Tools are like API endpoints. A tool is handed to the model as a schema that declares its name, the arguments it accepts, and what it returns. To use it, the agent only has to call it. For a programmer used to writing functions, tools are the natural analogue.

Skills, on the other hand, are far less structured. They can tell the agent to run a script, as in the Whisper example, but they are intended for higher level strategy, ambiguity, and the unanticipated. That flexibility has a cost. When a skill fires, the whole SKILL.md is loaded into the conversation, and within a single chat turn the agent loops round trips to the model to carry it out. Every one carries the context of those before it, including every intermediate result. Caching keeps that from exploding the token bill, but turns get slower, and the clutter hurts the quality of the answer. A tool does its work outside the model and hands back only the result.

So here is the rule I work by now. If it is a known, deterministic process with a clear output, make it a tool. If the problem is not so clear, reach for a skill and describe how to solve it in plain language.

But how do you add a tool? It requires an MCP server. Does that mean calling GoDaddy about hosting? Fortunately, no. Sahil Malik(https://codemag.com/Article/268021/MCP-Server-Tutorial-Expose-Tools-and-Resources-to-AI) and Wei-Meng Lee (https://codemag.com/Article/266031/Hands-on-MCP-Building-Servers-and-Clients-with-Python) have both walked through building one in these pages. What surprised me was how small it can be: a handful of lines of Python on the same machine as your agent, or about thirty lines of C# from the .NET template.

There is no TOOLS.md because it's not prose. It's code.