An MCP endpoint for rafeblandford.com

Connect it

That address is all any client needs. No sign-in, no token, no account.

Claude

The button opens Claude's custom-connector dialogue with the name and address already filled in. Claude's connectors also surface the four prompts below.

ChatGPT

ChatGPT needs the address pasted once — there is no deep link that fills it in. Steps correct as at 7 August 2026; its navigation changes, so if these no longer match, OpenAI's quickstart is the current version.

1. In ChatGPT, open Settings → Security and login and turn on Developer mode.
2. Open Personal plugins, select +, and paste the address above.
3. Name it Rafe Blandford, choose no authentication, and scan the server. Four read-only tools should be found.
4. Install it, start a new Work conversation, and select it with @.

If the server changes, rescan the plugin before relying on the new behaviour. Developer mode depends on your ChatGPT plan or workspace policy — if you cannot find it, the quickstart above is the place to look rather than anything I could tell you.

On the command line

Three clients, one command each. Run it once, then restart the client — a server added mid-session is not picked up until it starts again.

Claude Code

claude mcp add --transport http rafe https://machines.rafeblandford.com/mcp

Codex CLI

codex mcp add rafe --url https://machines.rafeblandford.com/mcp

Gemini CLI

gemini mcp add --transport http rafe https://machines.rafeblandford.com/mcp

Four prompts to try

Clients that support MCP prompts (Claude's connectors do) offer these already. ChatGPT works from tools, so here they are as text — copy one in and replace anything in brackets.

They cover most of what people ask. The last one, Interrogate the evidence, is deliberately adversarial: it asks what this site does not substantiate, which is usually the more interesting question.

Use only the Rafe Blandford plugin for the evidence. Retrieve the profile, career and case studies, then give me a briefing of about 300 words covering: what he does, the scale he has operated at, three concrete examples of work, and what he is looking for next. Cite the URLs returned by the tools. Do not add figures or claims the tools did not return. Distinguish claims drawn from a published page from Rafe's own self-attested outcome claims.

Assess how Rafe Blandford's published record fits the role below. First retrieve his profile and career. Identify no more than eight significant role requirements and check the published evidence for each. When you use the experience check, pass a short subject of two to four words — "operating model", not the whole requirement — because a long phrase matches nothing and returns not_found as though the site evidenced none of it. Use writing search and fetch a full post only where it would substantiate a point.

Report: clear published evidence; partial or adjacent evidence; and requirements for which nothing published on this site provides evidence. Do not turn absence from this corpus into a claim that he lacks the experience. Cite the URLs returned by the tools and give a short, honest overall assessment.

ROLE:
[Paste a job description or short role summary here]

Find Rafe Blandford's published position on [TOPIC]. Search his writing first, then fetch only the posts that materially answer the question. Summarise the argument he actually makes, cite each source URL, and note the authorship label where it affects how the source should be weighed. If his writing does not cover the topic, say so rather than assembling an argument he has not made.

Probe the limits of what this site substantiates about Rafe Blandford. Retrieve his career, case studies and provenance information. Identify which important claims have a source that can be followed, which are Rafe's own account, where an outcome lacks an attributable mechanism, and which areas of a senior technology and product remit are thinly covered or absent. Use the experience check to test likely gaps.

Finish with the sharpest questions a sceptical hiring manager should ask him directly. Be genuinely critical, while keeping clear that a gap in this corpus is not necessarily a gap in his experience.

The four tools

These are the tools an MCP client sees when it connects. You do not call them yourself — you ask a question, and the agent decides which of these to use and tells you what came back. They are listed so you can see exactly what it has access to, and what it does not.

The same data is available as resources for clients that support them — rafe://profile, rafe://career, rafe://case-studies, rafe://provenance and rafe://writing/{slug}. Tools are the primary interface; the resources are canonical projections of the same files, so the two cannot drift.

What it deliberately will not do

• It is read-only. There is no tool here that changes anything, sends anything or contacts anyone. That is the boundary, and the absence of a mutating tool states it more clearly than a permission dialogue would.
• It is generated, not hand-maintained. It comes from the same file as the career page, under the same editorial gate, so the two cannot drift. Case-study entries carry the summary and lead outcome the published post states, plus Rafe's own fuller account of the work — which sometimes goes further than the post, and sometimes measures things differently.
• It has no route to Rafe. Contacting him stays a human decision made by a human. The address is in the profile; the agent does not get to use it for you.

What gets logged

Calls to this endpoint are logged, in the interest of full disclosure. Each one records the method or tool used, how long it took, how many results came back, which pages were cited, and the client identity and protocol version the caller asserts. No authentication and no cookies. Some links carry a short label in the URL, so calls arriving by the same route can be counted together — that is the only thing that links requests to each other.

There are two kinds of label and they are reported separately, because they mean opposite things. A listing label is printed in something published — the registry entry, the launch article — and means you found this yourself; the label only records which route. An invitation label is one Rafe sent to a named person. Counting a listing pickup as an invitation would file the strongest evidence that this works as the weakest, so the published figures never merge them. The listing labels are named in /instrument; the invitation ones are not, because they are people's names.

Connecting is logged too, and it is kept separate. When a client connects and asks what tools are here, that handshake is recorded in its own file. It is not counted as use and never goes towards the measurement below — the reason for recording it is that a client can connect, read the whole tool list and call nothing, which would otherwise leave no trace at all. Without it, a result of zero could not tell "nobody came" from "people came, looked, and found nothing worth calling". It counts handshakes rather than people: reconnect five times and that is five lines.

This page — the one you are reading — carries Umami, which is cookieless and self-hosted, on its own separate site ID. It counts page views here and nothing else: it is not on the endpoint, and page views never count towards the measurement below.

Query text from search_writing and check_experience is kept for a year and never published without consent. Before it is written, contact details are stripped — email addresses, phone numbers, URLs, long digit strings and @handles. That is pattern matching, not anonymisation: it will not remove a name or a company typed in plain, so please do not paste anything into a query that you would not want kept.

Separately, the normalised terms of each query are kept indefinitely — that is the list of things people looked for and did not find. For a one-word query that is the word you typed, so treat it as retained rather than discarded. Only queries from real callers go into that list: Rafe's own tests, uptime monitors and crawlers are excluded from it, so the permanent record is what an audience actually asked for and nothing else. The long-lived call log holds counts, timings, cited pages and a hash, never the words. Full detail: /instrument.

Where this is listed

This server is published in the MCP Registry as com.rafeblandford/career, authenticated by a DNSSEC-signed record on the apex domain rather than by a claim in a form. The registry has no browsable interface of its own — it is a data source — so listings that appear elsewhere, on Glama or PolicyLayer, are aggregators reading from it rather than places anything was separately submitted.

The address in that entry carries ?via=registry, and the skill above carries ?via=skill. Both are channel markers, not credentials: they let a call be attributed to how it was found, and they are asserted rather than verified — anyone can append one. The measurement reports them as claims, which is the honest way to count a public listing.

WebMCP

Separately from this endpoint, the pages on rafeblandford.com declare WebMCP tools of their own — get_page_facts, check_experience, list_case_studies and search_writing — for an agent that is already driving the browser, so it can ask the page rather than scrape it.

That API (document.modelContext) is experimental. It is off in stable browsers and needs a Chrome flag or the WebMCP extension, so it is there ahead of general support rather than as a route to use today. Nothing on this endpoint depends on it, and the tools are read-only in the same way these are.

Skills

An Agent Skill is a folder with a SKILL.md in it — plain Markdown telling an agent how to do something specific. There is one for this site, and it answers the question this page cannot: given three interfaces, which should I use, and how do I read what comes back without misrepresenting somebody?

It carries the two distinctions that matter here — that the corpus is a selection, so not_found is a fact about the site rather than about Rafe, and that case-study outcomes are self-attested where summary is drawn from the published post. Both are easy for a summarising agent to flatten.

Any agent

npx skills add rafeblandford/skills

Claude Code

/plugin marketplace add rafeblandford/skills

Gemini CLI

gemini skills install https://github.com/rafeblandford/skills.git

Codex reads skills from $HOME/.agents/skills — copy the folder in. The source is at github.com/rafeblandford/skills under Apache 2.0, and rafeblandford.com/resources is the human version of this section.

Machines can skip all of that: the skills are indexed at /.well-known/agent-skills/index.json, each with a SHA-256 digest of the file it points at, so you can check that what you fetched is what was published.