Why my website has an MCP server

This site now has a door for machines. Point Claude, ChatGPT, Cursor or an agent of your own at one address and it can read every article here, search the passages, pull the question sets of the four free assessments and have them scored by the same rules the website uses. It costs nothing, needs no account, and writes nothing down. This piece is about why I built it and what the building taught me, because the small decisions in a thing this size are the same decisions a company faces when it gives an AI access to anything that matters.

What MCP is, in one paragraph

The Model Context Protocol is an open standard, published by Anthropic in late 2024 and since adopted across the industry, for letting an AI assistant use tools and read sources outside itself. A server says what it offers, in a form the assistant can read: here are my tools, here are their inputs, here is what comes back. The assistant then calls them as the conversation needs. Before MCP every integration was bespoke; after it, one server serves every assistant that speaks the protocol. For a company it is the plumbing through which an assistant reaches the CRM, the ticket queue or the product database. For this site it is the plumbing through which an assistant reaches my writing.

Why bother

Two reasons, one modest and one less so.

The modest one: people increasingly ask their assistant rather than a search engine, and an assistant that can read the actual article and cite it is more useful, and more accurate about me, than one working from a months-old crawl. The Ask feature already answers questions from my writing for visitors; the server gives the same sources to whatever assistant a reader already uses, and lets that assistant do the answering.

The less modest one: I advise companies on what to do with AI, and specifically on how much autonomy to give it. It seemed right to have built and secured the plumbing myself, at small scale, before telling anyone else how to do it at large scale. The server took an evening to build and another to review. The design questions took longer, and they are the interesting part.

The decisions

It calls no model. The obvious design was a server with an "ask" tool that answers questions itself. I left it out. A tool that spends money on every call is a tool that someone will find a way to make spend money, and a public one with no login is the easiest target there is. The assistant on the other end already has a model; what it lacks is the sources. So the server hands over text and citations and lets the caller do the thinking. The result is a service that cannot run up a bill, which changes how much I need to worry about it.

It writes nothing. No leads, no emails, no stored answers. The website's tools can email you a result and generate a briefing; the server cannot, and that is deliberate. Every capability you give an agent is a capability someone else's agent has too. Read-only is a smaller thing to defend, and it is what an assistant actually needs from a body of writing.

The scoring is deterministic. When an assistant scores an assessment, it sends the answers and gets back the headline, the module scores, the flags and the plan from a rules engine that is published and tested. No model sits in that path. I have argued before that the decision and the explanation should be separated, with the model explaining and the rules deciding, and this is that argument in about four hundred lines of code. Ask the same questions twice and you get the same answer, which is more than can be said for asking a model twice.

It is limited and it remembers nothing about you. A hundred and twenty tool calls an hour per address, counted against a one-way hash of the address rather than the address itself, and the count is discarded after two days. That is the whole of what it records. A security review the same week found the rate limit counted a batch of eight calls as one, which is the kind of thing reviews are for and the reason I do not ship anything I have not tried to break.

What it taught me

The lesson is not technical. Building the thing forced a list of questions that a company adopting agents should be asking and mostly is not. What can this reach? What can it change? What can it spend? Who else can call it, and how often? What does it keep? And, for every capability, what is the smallest version that does the job? My answers were: the articles and the rules; nothing; nothing; anyone, a hundred and twenty times an hour; a hashed count for two days; and read-only. A company's answers will be larger on every line, and that is fine, so long as they are answers rather than defaults. An agent with keys is a different proposition from an assistant that answers questions, and the difference is exactly this list.

The other thing it taught me is how little there is to it once the questions are answered. The protocol is simple, the server is a few hundred lines, and the hard work was deciding what to leave out. That is usually the case with the difference between a hobby system and a professional one: not more features, but fewer, chosen on purpose and defended.

Three things worth taking seriously

If you are a reader with an assistant: add the server and try it. "Search Catherine Ives-Yim's writing for what a lender's technology review looks at" or "take me through the CRA Readiness Check and score it" are good first asks. It is the same material as the site, reached your way.

If you are giving an agent access to your own systems: write down the six answers above before you write any code. If you cannot answer "what can it spend" and "who else can call it", you are not ready to switch it on.

If you are a board or an investor: ask the same six questions of any company that tells you it has deployed agents. The quality of the answers tells you whether they have deployed agents or plugged in a demo.

Which of your systems could an AI reach today, and who decided that?

The server and how to connect it are on the MCP page. If you are working out how much access to give your own agents, that is a conversation I have often.