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.
