Expertise made
queryable.

AI conversations start cold. Your chosen model knows nothing about who you are, what you believe, or how you make decisions. For most people that's fine — tasks are discrete and context is implicit. For me it became a persistent friction: the same base context re-entered over and over, profile additions ignored or stale, every new conversation starting from zero.

I write and think about design stuff a lot. My newsletter has 70+ posts covering topics which span all of the work of design leadership. They have named frameworks, stated positions, views on taste and ethics, and are all written in a particular voice. Every time I started a new conversation to draft something, pressure-test an idea, or get a second opinion, I was spending the first part of the conversation re-establishing who I was. The model was always meeting me for the first time.

When an AI reasons about design stuff, it synthesises conference talks, blog posts, Medium essays of variable quality, generic management stuff, things it thinks are about design, but are actually about topiary, etc. The output is averaged and flattened. What I wanted was a tool that reasons from my corpus. Owned input, not inherited noise. I want AI tools to treat my content like a knowledge base rather than a prompt — structured, queryable domains that a model retrieves selectively depending on what it's actually doing.

This is an experiment without a conclusion. I'm not sure it works in the ways I hope, and I haven't fully tested the limits. But that's the point. My view on AI tools comes from use, and this use is novel (to me). Building this has taught me lots about what an MCP server is and isn't, what context actually means in practice, and where the interesting problems are.

The knowledge base is a flat JSON file with thirteen tools. Each one is a named domain of expertise. The model calls the tool, gets the string, uses it as context. The tools split into three broad categories: content, action, and instruction.

The two DLM content tools are the largest, and they exist as a pair for a specific reason. get_dlm_links gives the model a compressed view of what I've written about; get_dlm_writing gives it the actual text — around 70,000 characters of published posts. I kept both because they serve different retrieval needs. Synthesis tasks want the summary. Voice and position tasks want the source. The unedited writing is the most direct signal of how my thinking has actually developed, rather than how I would characterise it if asked.

There are also content tools which are highly specific caches of content which describe more philosophical positions — my views on taste, my 'design worldview', etc. These provide bounds for models to reason within — because without them, it might fall back on what Mark Zuckerburg thinks about design, and no one needs to internalise that, not even a robot.

Instruction tools tell the model how to behave — they cover my writing style, or at least what I think my writing style is, the anti-patterns which tell the model what not to write, those telltale AI constructions which make everyone wince.

critique_design_decision is the only tool that actually creates something — the other twelve return stored text and let the model work with it; this one calls a language model. You give it a description of a design decision or rationale, and it returns a structured critique: which of my frameworks apply, where the reasoning holds, and where I'd push back.

The frameworks invocation is what makes it useful. The verdict rarely surprises me — I usually have a sense of where I'd land. What I don't always have is the vocabulary for which mental model applies, surfaced immediately. Naming "the late presentation problem" before the deliberation starts is different from naming it after. The frame is in the room before the argument begins; it shapes what gets said and what doesn't. A thinking accelerant, not an oracle.

The implementation is simple by design. The critique prompt embeds my worldview, philosophy, frameworks, positions, and taste in full. The three-section structure is enforced in the prompt — instructed, not parsed. A smaller, faster model handles this reliably: the prompt is explicit enough that instruction-following matters more than raw capability. If this is being called frequently by an agent working through a stack of decisions, the cost difference adds up.

There's a public version at /ask — a chatbot interface that queries the same server directly. The intended use is agents and tools, not conversation; but it is a quick way of validating that the MCP server works, and is offering at least superficially useful output.