Infrastructure as a Fabric: How a Qdrant MCP Server Led Me to Rethink Everything

Sometimes a project starts as one thing and becomes something else entirely. Today I sat down to build an MCP server for Qdrant’s vector database platform. By the end of the session, I had a new design philosophy, a 60-term lexicon borrowed from textile arts, and a completely different way of thinking about how my infrastructure fits together.

This is the story of that journey.

It Started with 28 Tools and a Problem

I’ve been building MCP (Model Context Protocol) servers for a while now — wrappers that let Claude talk to my infrastructure in natural language. I have them for UniFi networking, Proxmox virtualization, GitHub repository management, Starlink terminals, Docker security scanning. The pattern is familiar: find the API, wrap the endpoints, expose them as tools.

So when I sat down to build one for Qdrant — the vector database that backs my semantic memory system — I did what I always do. I started writing tools. Twenty-eight of them covering collections, points, search, indexes, snapshots, aliases, and a handful of cloud management operations.

Then I stopped and looked at what I’d actually built.

Twenty-eight tools. Sounds like a lot. But Qdrant’s Cloud Management API has 11 gRPC services. Their Database REST API has 9 sections with roughly 75 endpoints. I’d covered maybe 37% of the surface area. I’d also made a bunch of assumptions without asking the right questions first — jumped straight to Docker packaging, implemented partial coverage, and didn’t clarify whether I needed the Cloud API, the Database API, or both.

So I did something that felt counterintuitive: I threw it all away and started over.

The Tink

In knitting, there’s a term called “tinking.” It’s “knit” spelled backward. It means carefully undoing your stitches — one at a time, back to where the pattern went wrong — so you can re-knit them correctly. It’s not ripping everything apart (that’s called “frogging,” as in “rip it, rip it”). Tinking is surgical. Respectful of the work you’ve already done. You’re just acknowledging that the last few rows weren’t right.

That’s what I did with the Qdrant MCP server. I tink’d it. Pulled back to the design phase, laid out the full API surface, and started asking the questions I should have asked first:

Scope: One server covering both the Cloud Management API (cluster lifecycle, billing, IAM, monitoring) and the Database REST API (collections, points, vectors, search). Because a Cloud user needs both — you create and manage clusters through one API, then operate on data through the other.

Packaging: uv-first with pip fallback. Clean, modern, fast.

SDK approach: A hybrid — httpx for all HTTP transport (no gRPC dependency chain), but Pydantic models structurally derived from Qdrant’s Protocol Buffer definitions. The generated proto SDK stays in the repo as a reference for type accuracy, but nothing imports it at runtime. Best of both worlds: clean types, zero SDK dependency, and a clear diff path when Qdrant updates their protos.

The goal isn’t just “make it work.” The goal is to build something that Qdrant themselves would look at and say, “that’s the reference implementation.” Full API coverage. Every endpoint. Every service. No gaps.

Then the Fabric Started Showing Its Threads

With the Qdrant MCP server scoped out, I needed to think about how it connects to everything else. Because Qdrant isn’t just another service in my stack — it’s the database that backs AIANA, my semantic memory layer. AIANA records conversations, indexes decisions, and provides recall across sessions. It’s the system that gives my AI tooling memory.

And AIANA connects to n8n, my workflow automation platform. And n8n connects to everything else. And suddenly I wasn’t building an MCP server anymore — I was staring at the whole architecture and asking how it all fits together.

I already had a name for this: the “fabric layer.” It was the loosely-coupled integration between AIANA (semantic memory), git-steer (repository lifecycle management), n8n (workflow automation), and the growing collection of MCP servers that let Claude talk to all of it. But calling it a “fabric” was just a metaphor. A convenient label. I hadn’t really thought about what fabric actually is.

What If We Took the Metaphor Seriously?

Here’s where the conversation took a turn I didn’t expect.

What if infrastructure isn’t something you build? What if it’s something you weave?

The traditional metaphors — building, plumbing, wiring — they all imply rigidity. Once you build a wall, it stays there. Once you lay pipe, it doesn’t move. These metaphors make us think about infrastructure as something permanent and resistant to change.

But fabric is different. Fabric is flexible — it bends and drapes around whatever it covers. It’s composed of simple repeating units — every complex pattern is just variations on the same basic stitches. It’s strong through interlocking, not through mass — no single thread bears the load. It’s repairable — you can undo a section and reweave it without destroying the whole piece. And critically, it’s visible — you can look at fabric and immediately see where the tension is wrong, where a stitch was dropped, where the pattern breaks.

Infrastructure should have all of these properties.

The Loom, the Warp, and the Weft

Once I started mapping textile concepts to infrastructure, the parallels kept getting deeper.

The loom is the platform itself — Proxmox hosts, physical network, k3s clusters. The compute substrate that holds everything under tension and makes weaving possible.

The warp threads are the fixed, long-lived services that run the length of the loom: UniFi gateways, Qdrant clusters, databases, the things that are always there, always under tension, always structural.

The weft threads shuttle laterally across the warp, creating the actual fabric. These are the dynamic operations: MCP tool calls, n8n workflows, Cortex agent tasks, API requests moving between services. The weft is what turns a collection of parallel threads into something useful.

The shuttle carries the weft back and forth. In my architecture, that’s n8n and the Cortex agents — the carriers of operational logic between fixed services.

The selvedge is the clean, finished edge where the fabric meets the outside world. In infrastructure terms, it’s the API boundary. The well-defined interface where one system meets another. If your selvedge is messy, the whole fabric frays.

And Claude — the AI that talks to all of this — is the weaver. Hands on the shuttle. Eyes on the pattern. Making decisions about which weft thread to pass through which shed, moment by moment.

Stitches as Operations

The mapping goes deeper than structure. Individual operations map to knitting stitches:

A garter stitch is the simplest pattern — all knit, all the time. In infrastructure, that’s a basic health check. A simple list operation. Flat, reliable, boring in the best way.

A rib stitch is elastic. It stretches and contracts. That’s event-driven automation — webhooks and triggers that expand under load and relax when things are quiet.

A cable stitch crosses threads over each other, creating raised patterns and structural complexity. That’s semantic memory — AIANA weaving context from one conversation into another, threads crossing in ways that create meaning.

A brioche stitch is double-layered, reversible, and uses twice the yarn. That’s multi-agent orchestration — each agent is a layer, and the pattern works from either direction.

A yarn over creates a deliberate hole in the fabric. In lace knitting, the holes are the point — they create beauty through negative space. In infrastructure, a yarn over is an intentional gap in automation. A point where human review is required. Where you choose not to automate because judgment matters more than speed.

The Errors Have Names Too

Knots are tight coupling — tangled connections between services that can’t be undone without damaging their neighbors. The anti-pattern of IaaF.

Dropped stitches are missed events, failed health checks, gaps in monitoring. They’re not catastrophic on their own, but if you don’t catch them, they become ladders — cascading failures that run vertically through multiple rows of the fabric.

Pilling is technical debt. Surface-level degradation from repeated use without maintenance. It doesn’t destroy the fabric, but it makes it look and feel worse over time.

And felting — the permanent bonding of fibers through heat and friction — is what happens to legacy integrations that have been running so long they can’t be separated anymore. Sometimes felting is intentional and useful. Sometimes it’s just what happens when you leave wool in a hot washing machine.

The Yarn Bomb

The last piece fell into place when I realized what the whole project actually is.

A yarn bomb is guerrilla textile art. People knit colorful covers and wrap them around lampposts, fire hydrants, bike racks — existing public structures. The structures don’t change. They still hold up streetlights and dispense water and park bicycles. But suddenly they’re visible in a new way. Approachable. Inviting.

That’s what MCP servers are doing to my infrastructure. The Proxmox hosts are still there. The UniFi switches still switch. The k3s clusters still orchestrate containers. But now they’re wrapped in a conversational layer that lets me — and Claude — interact with them through natural language. The infrastructure is the same. The experience is completely different.

And yarn bombs aren’t permanent. They’re not precious. They’re meant to be seen, appreciated, maybe remixed, and eventually replaced. That maps perfectly to MCP servers — composable, disposable wrappers around APIs that will outlive them.

Where This Leaves Things

The Qdrant MCP server is in active development. Full API coverage — both Cloud Management and Database REST — with a clean, well-typed httpx + Pydantic implementation.

AIANA is running in production, recording conversations, but needs work on its vector indexing pipeline before the semantic search layer is fully operational. That’s the immediate priority — you can’t weave with unspun yarn.

n8n is deployed but not yet threaded into the fabric. Its exact role — always-on infrastructure backbone or task-specific automation invoked on demand — will reveal itself through usage patterns. I’m deliberately not forcing that decision. The yarn will tell me what it wants to be.

And the whole thing has a name now: Infrastructure as a Fabric. IaaF. A design philosophy built on loose coupling, clean selvedges, intentional yarn overs, and the courage to tink when the pattern isn’t right.

I wrote up a full foundry document — 473 lines covering the philosophy, the lexicon, the threading plan, and ten design principles I’m calling “The Weaver’s Rules.” The first rule: No Knots. Every connection must be loose enough to tink. If removing one service would unravel its neighbors, the coupling is too tight.

The tenth rule: The Weaver Sees the Whole Cloth. Claude maintains awareness of the entire fabric — all warp threads, all weft passes, all patterns in progress. Not micromanagement. Just the perspective that prevents dropped stitches and ensures the pattern emerges correctly.

What’s Next

Phase 0: Fix AIANA’s spinning wheel — get those 229+ messages vectorized.

Phase 1: Wire AIANA’s MCP server into Claude’s config so the weaver can actually reach the memory.

Phase 2: Complete the Qdrant MCP server rebuild with full API coverage.

Phase 3: Thread n8n into the fabric — give Claude the ability to invoke workflows.

Phase 4: Watch the patterns emerge and let them tell me what n8n needs to become.

The loom is warped. The yarn is ready. Time to weave.

---

This is part of an ongoing series about building AI-integrated infrastructure management tools. The IaaF Foundry Prompt, full lexicon, and project documentation are available on GitHub.