I’ve written before about building agents and calling tools directly, but up till now I’ve largely avoided MCPs. Now, I’ve started a new job, and I needed to better understand MCP servers. I’ve read the spec, but I felt like there was a disconnect between what has actually become popular.
So, as I often approach these types of problems, I decided to build my own MCP server. Then I can point various off-the-shelf agents with MCP support at my server, and observe the interactions. Then by learning from those observations, I can better utilize the capabilities in my own agents.
Even though I’m building this as a learning tool, I wanted it to be genuinely useful. I’ve used the i3 window manager for some time now, and I’ve always known that it’s easily programmable, and that it has a first-class Go library. So my initial concept was to create an MCP server, which exposes the functionality of my running i3 window manager, through natural language.
Back to Claude Code?
I started where I usually start — with local models. I threw qwen3:30b at the problem with various larger context configurations, but the results were only rough sketches that wouldn’t compile. I did some minimal manual work to get it compiling and then on-boarded it to Claude Code. I’m back on the Claude Pro plan. I have a lot I need to get done, and right now it’s the best no bullshit toolset with affiliated models.
👤 User Please familiarize yourself with this project, I’d like to discuss a new feature. 🤖 Claude I’ll explore this project to understand its structure and purpose. 🤖 Claude This is ithreemcp, an MCP (Model Context Protocol) server that bridges AI/LLM clients with the i3 tiling window manager. Current functionality: GetTree - Returns the complete i3 window layout hierarchy
- Returns the complete i3 window layout hierarchy GetWorkspaces - Returns details about all workspaces Tech stack: Go 1.25.3, using the MCP Go SDK and go-i3 bindings Architecture: Simple bridge pattern - MCP clients communicate via stdin/stdout, and the server translates requests to i3 IPC calls. The codebase is compact (~112 lines in main.go ) and follows standard Go conventions. What new feature would you like to discuss? 👤 User I’d like an end-user, with an agent configured to use this MCP server to be able to say something like, “move the firefox window to workspace 7”. Can you propose the tools you think we should add to this MCP server to best allow an agent to accomplish the task? 🤖 Claude Great use case! Let me think through what an agent would need to accomplish “move the firefox window to workspace 7”.
And away we go…
Twenty-five commits later, split over two evenings, a github repo was born. ithreemcp
Using our MCP Server
... continue reading