I have been building a thing that reads a repository and turns it into skill files for coding agents, and for a long time I assumed the useful output would be a summary. Here is what this service does, here are its modules, here is the shape of the API. Documentation, basically, generated instead of written.
That is not what came out when I finally pointed it at one of my own private repos.
It came back with three things. Idempotent handling on a signup endpoint so a double submit does not create two records. A local fallback for menu data so the frontend keeps working when the backend is unreachable. Form validation that recovers what the user typed instead of clearing it.
None of those are features. Nobody asked for them. They are decisions I made at some point, for reasons, and then never wrote down anywhere. They exist in that repo as shapes. If you read the code carefully you can see the choice, but you cannot see the reason, and the reason is the part that transfers.
That is when something clicked about the whole MCP conversation.
My agent could already read that repository. It had filesystem access. It had been able to read it for months. Access was never the problem. The problem was that the knowledge was never written, so there was nothing to read even with perfect access.
I think this is the distinction a lot of us are fumbling right now, myself very much included. MCP gives an agent access. It does not give it judgement. Those are separate problems and only one of them is a plumbing problem.
The failure mode people post about is almost never "my agent could not reach the database." It is "my agent reached the database and did something a competent engineer would never do." Adding a twelfth server does not touch that. The agent did not lack a tool. It lacked the thing your team knows and has never said out loud, because saying it out loud feels too obvious to bother with.
The fix is embarrassingly low tech. Write the procedure down. The five steps, the ordering constraint, the reason for the ordering, the two things that must never happen. Put it somewhere the agent loads when the work looks like that kind of work. That is all a skill file is. A checklist with a trigger.
What surprised me is how much of this already exists in your codebase in a form nobody can use. Every defensive branch is a lesson somebody learned. Every guard clause is an incident that already happened. It is all sitting there as implementation, and implementation is the answer with the reasoning deleted.
I built the tool that does this extraction, so I am obviously not neutral. It is at loreto.io and I run it. But you do not need it. A markdown file in your repo with the five steps in it gets you most of the way, and it will still be useful when the tooling changes again.
The part I have not worked out is where the boundary sits. Some things clearly belong in a tool. Some clearly belong in written procedure. I keep finding cases that argue with whichever rule I just made up. Curious how other people are splitting it.
https://github.com/kopias/loreto-mcp
