End of Line: Replacing MCP with Standard Filesystem Tools | Structure and Interpretation of Computer Programmers
Skip to content
Structure and Interpretation of Computer Programmers
From programmer to software engineer.
Home<br>Blog
Contact
Post Archives
Privacy Statement
Software Portfolio
Unified Documentation: Clear Explanations of Complex Systems
← Using WebObjects at web-scale with Kubernetes and Firebase
End of Line: Replacing MCP with Standard Filesystem Tools
Posted on 2026-07-16 by Graham
Over on YouTube I shared a video where I demonstrate a more context-efficient approach for integrating existing systems into agentic tools than MCP, one that comes with built in access control mechanisms and that LLMs are already trained to understand: userspace filesystems.
Properly designed, a filesystem is a hierarchical organisation of resources that allows for enumeration and filtering of those resources, and random access to their contents. In other words, pretty much anything that you can represent as a database with a collection of CRUD (Create, Retrieve, Update, and Delete) operations, you can represent as a filesystem.
The hierarchical design might not always be the best fit for the data model, but plenty of systems already use a hierarchical representation of their data with CRUD operations: think of web services where a particular user’s photo album is accessed at https://hostname.example/users/501/photos, a particular photo in their album is at https://hostname.example/users/501/photos/176DC73A, and the operations available are the usual HTTP verbs; get, put, post, and delete. The mapping from URI paths to filesystem paths is trivial (indeed you can use file URIs if you like); the file-operation verbs aren’t quite a 1:1 mapping but you can make them happen.
Where in an HTTP service you might need to look up whether an authenticated user has the right to perform an action and return a 40X code if they can’t, a filesystem takes care of that for you. The operating system already has a permissions model, or an access control model, or both, built in, and a collection of error codes that indicate to a client that an entity doesn’t exist, or that they don’t have permission to access it in the way they tried, or that another problem occurred.
Thing is, once you expose your service as a filesystem, your LLM and your agentic tools can already work with it. They’ve already been trained on finding, reading, writing, creating, and deleting files, because that’s what they need to do to write code, to generate term papers, and all the things they’re already used for. You don’t need special tools to tell the model how your new filesystem works, because it works the same way as everyone else’s. So no need to clutter up context with a load of descriptions of an MCP server and the tools it exposes. No need to write an agent skill telling the model how to use a script that access the system; it already knows how to read and write files.
I think this is a useful approach for representing stateful information, particularly for representing dynamic state like the internal setup of a system for debugging. The model can interpret the current state by reading the filesystem, and make changes to the state by applying patches or recreating files. A particularly powerful pattern is “declarative intent, imperative report”: the model writes a description of what should happen to a file, then reads the system state from other files to find out what actually did happen.
That’s the equivalent of using a programming language to describe how a program should work, and a debugger to understand how the program does work. I’m just saying that if the debugger is a collection of files and folders, your LLM can use it much more effectively than if you dedicate time to wrapping it in an MCP server.
About Graham
I make it faster and easier for you to create high-quality code.
View all posts by Graham →
This entry was posted in whatevs. Bookmark the permalink.
← Using WebObjects at web-scale with Kubernetes and Firebase
Leave a Reply<br>Your email address will not be published. Required fields are marked *<br>Comment *<br>Name *
Email *
Website
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Chiron Codex: helping software engineers become centaurs.
OOP the Easy Way<br>Object-Oriented Programming the Easy Way: a manifesto for reclaiming OOP from three decades of confusion and needless complexity.
APPropriate Behaviour<br>The book about all the things software writers do that aren't writing software.
APPosite Concerns<br>A collection of essays on being a programmer, on doing programming, and on thinking about programmers.
Support This Site<br>If you like what I do please support me on Ko-fi
FSF
Structure and Interpretation of Computer Programmers
Proudly powered by WordPress.