DEV Community: David Hamilton

Nobody Reads Your llms.txt. Except Claude Code.

David Hamilton — Fri, 24 Jul 2026 10:51:10 +0000

Ask a room of SEOs whether you need an llms.txt file and you will get an argument. Ask what actually fetches the file and the room goes quiet.

There is data now, and it is not kind. Ahrefs pulled server logs from 137,210 domains. 28% of them publish an llms.txt. In May 2026, 97% of those files received zero requests. Around 1,100 domains saw any traffic to the file at all.

That sounds like the end of the story. It is not, because the small slice of requests that did land tells you exactly who this file is for, and it is not who anybody was optimizing for.

What the file actually is

llms.txt is a Markdown file at the root of your domain, at /llms.txt, listing your most important pages with a one-line description of each. Jeremy Howard published the proposal on September 3, 2024.

The reasoning is good. A docs page rendered as HTML is mostly not documentation. It is nav bars, sidebars, cookie banners, and framework wrapper divs. Make a model chew through all of that and it spends most of a fetch on nothing. A Markdown index costs a fraction of the tokens and points straight at the pages that matter.

The format is simple and only the H1 is required. Cloudflare publishes a clean example, trimmed here:

# Cloudflare Developer Documentation

> Each product below links to its own llms.txt, which contains a full index
> of that product's documentation pages.

## Application performance

- [Argo Smart Routing](https://developers.cloudflare.com/argo-smart-routing/llms.txt): Route web traffic across the fastest, most reliable network paths
- [Cache / CDN](https://developers.cloudflare.com/cache/llms.txt): Make websites faster by caching content across our global network

Two things worth stealing from that. Cloudflare nests the format, so every product gets its own llms.txt and the root file becomes a directory of directories. And every link carries a description, which is the part most people skip and the part that does the actual work. A bare list of URLs tells a model nothing about which one to open.

There is a sibling file, llms-full.txt, which is the whole docs set flattened into one large Markdown file so an agent can load everything in a single request. It is not in the original proposal. It grew out of documentation platforms, Mintlify in particular, and it spread because it is what an agent actually wants when you point it at a docs site.

The SEO question is settled, and the answer is no

Google's AI features documentation says you do not need to create new machine readable files or AI text files to appear in AI Overviews or AI Mode. John Mueller has separately called llms.txt speculative, compared it to the keywords meta tag, and pointed out the awkward fact that no AI system uses it.

robots.txt works because crawlers agreed to obey it. sitemap.xml works because search engines agreed to consume it. llms.txt is a good idea that shipped without a counterparty. If you added one hoping to appear in more AI answers, you did not get what you paid for.

Now the interesting half

Ahrefs did not just count the zeros. They named the requests that landed.

Fetcher	Share of requests	What it is doing
SEO audit tools	21.7%	Checking whether the file exists, for a report
General web crawlers	13.1%	Indiscriminate crawling
GPTBot	4.51%	OpenAI's crawler
Claude-Code indexer	3.52%	A developer's coding agent reading docs
ClaudeBot	0.8%	Anthropic's web crawler
OAI-SearchBot	0.74%	OpenAI's search-facing bot

Read that table twice.

The single largest consumer of llms.txt is SEO tooling checking whether you have an llms.txt. A snake eating its own tail.

And the second largest named AI fetcher is Claude Code. That is not a search engine discovering your brand. That is a developer sitting in a terminal who already knows your product exists, pointing an agent at your documentation and telling it to go read the auth flow.

Every IDE agent has converged on the same behavior. Point Cursor, Windsurf, Claude Code, or Copilot at a docs site and the first thing it reaches for is /llms.txt and /llms-full.txt, because that is the cheapest possible way to load a doc set.

llms.txt is a documentation delivery format that got marketed as an SEO tactic. That mismatch is why every study of it reads like a failure.

Writing one, in about ten minutes

1. List the pages you would send a new hire: Not every page. The ones that say what the thing is, how to install it, and how to do the three most common jobs. Fifteen to fifty links is a normal range. A file with 400 links is a sitemap with extra steps.

2. Write the H1 and the blockquote: The H1 is your project name. The blockquote is one or two sentences that let a model understand what you are before it reads anything else. Be concrete. "MCP-native tools that connect Claude and Cursor to the data they are missing" beats "a platform for modern teams".

3. Group the links under H2 headings: By product, by job, or by section of your docs. The heading is context, so name it something a model can reason about. "Getting started" and "API reference" are useful. "Resources" is not.

4. Give every link a description: The format is [Page title](https://example.com/page/): what this page covers. If your pages already have meta descriptions, reuse them. This is the highest-value part of the file and the part most published examples get lazy about.

5. Generate it, do not hand-maintain it: A hand-written llms.txt goes stale in a month. Generate it from your docs navigation and each page's frontmatter at build time and it cannot drift from the real doc set. On a static site that is twenty lines of build code.

Serve it as text/plain at https://yourdomain.com/llms.txt and use absolute URLs. Relative links are the most common mistake and they break the file for any agent that fetched it from somewhere else.

So should you ship one

Ship it if you have documentation: If developers point AI tools at your docs, this is the difference between an agent reading a clean index and an agent scraping four rendered HTML pages to find your auth flow. That is a real improvement for the exact person most likely to become a customer, and it costs a build script.

Skip it if you run a marketing site and want AI visibility: A ten-page site about your agency does not need a machine-readable index of ten pages. Nothing will fetch it, and the hour costs you an hour of the work that does move citations.

Never treat it as a substitute for the fundamentals: It cannot make thin content citable, it cannot fix a page that renders as an empty shell without JavaScript, and it grants no crawl permission you did not already give in robots.txt.

The uncomfortable version, since somebody should say it. A lot of llms.txt advice exists because "add this file" is an easy thing to sell and an easy thing to check off. It has the shape of a deliverable, it takes minutes, and nobody can prove it did nothing. That combination is exactly how the keywords meta tag survived for a decade after it stopped mattering. Ship the file for the coding agents. Do not put it in a strategy deck.

How to tell whether yours is doing anything

Grep your access logs for llms.txt and look at the user agents. That is the only measurement that answers the real question. Coding-agent traffic means the file is doing its job. Three months of nothing but audit tools tells you exactly what it is worth to you.

If your goal was AI visibility, measure the outcome instead of the tactic. Ask your target questions in ChatGPT, Claude, and Perplexity and record whether you get named at all.

Full disclosure, I build tooling in this space. ContextBolt SEO is a hosted SEO MCP server. You paste one URL into Claude Code, Cursor, or Codex, then ask in plain language whether AI tools are mentioning you and how your share of voice is moving against named competitors, plus the keyword, rank, and backlink work you would otherwise open a $129 tool for. It is $35 a month, month to month.

The longer version of this, with the full spec table and a copyable example, is my guide on how to write an llms.txt file.

llms.txt is a good file with a bad reputation, earned by the people who oversold it. It is not a ranking signal and it never was. It is how you hand a coding agent your documentation without making it read your nav bar. Judged as that, it works.

Your Site Audit Found 400 Issues. You'll Fix Four.

David Hamilton — Wed, 22 Jul 2026 10:34:38 +0000

Ask Claude to audit a page and it does a genuinely good job. Ask it to audit your site and something quietly goes wrong. It reads your homepage, tells you the title is a bit long, and calls that a site audit.

You have not audited a site. You have audited one page and rounded up.

The problems that cost you traffic are never on one page

They live in the pattern. Forty posts sharing one meta description because the template forgot to fill it in. Every product page rendering three H1s. A sitemap full of URLs that redirect.

None of that is visible from inside one page, because the bug is the relationship between pages, not the page itself.

Four kinds of problem only show up when you look at many pages together.

Duplicates across pages: Two pages with the same title compete with each other. You cannot see that from either page.
Template bugs: If your blog layout drops the H1, every post is missing an H1. A page audit reports one missing H1 and you fix one page. A site audit reports "no H1 on 38 pages" and you fix the layout file. Same effort, forty times the result.
Broken plumbing: Sitemap entries that 404, canonicals pointing at pages that no longer exist, redirect chains three hops deep.
Scale, so you can prioritize: "Your title is long" is a shrug. "Your title is long on 61 pages, and 9 have no H1 at all" is a work order.

Why "audit my site" only audits one page

Hand Claude a URL and it fetches that page. That is the whole behavior. No crawler, no sitemap parser, no memory of the last forty pages it read. So when you say "audit my site," it does the only thing it can.

This is the same limitation behind every other SEO job. Claude is excellent at judgment and blind to live data. MCP is how you close that gap. An SEO MCP server gives Claude a tool that takes a domain, reads its sitemap, fetches a batch of pages, and returns structured data instead of a wall of HTML.

Once that tool exists, "audit my site" becomes a real instruction.

Nobody fixes 400 issues

Here is the uncomfortable part, and it applies to nearly every audit product on the market, mine included until I built the thing that fixes it.

Run a classic site audit and you get a number. 400 issues found. It feels thorough. It is also the most useless output in SEO, because nobody has ever fixed 400 issues. You skim it, fix the four that look easy, promise to come back, and never do.

The scary first-run number is a marketing asset. It sells the subscription. It does not improve the site.

The run that improves the site is the second one. You fix a template, you re-audit, and you find out whether the number moved. That loop is where the work happens, and it is the part almost nothing is designed for. Most tools return you to a static report from last Tuesday, or worse, silently crawl a fresh set of pages so the comparison is meaningless.

An audit you run once is a to-do list. An audit you run twice is a system.

If your audit cannot answer "did my fix work," it is a report, not a tool.

The five-move workflow

Point it at the domain: "Audit mysite.com." It discovers the sitemap, ranks pages by structural importance, and audits the top batch.
Read the fix list from the top: Order by severity times pages affected. The top item is almost always a template bug, which is one edit with a large blast radius.
Fix the top item in the same session: This is the advantage of auditing inside an agent instead of a browser tab. Claude already has your repo open. Say "fix the missing H1s" and it edits the layout file rather than describing the edit. Review the diff like any other change.
Re-audit and read the delta: Same pages, not a fresh crawl. Health 74 to 89. Missing H1 fixed on 38 pages. One new issue introduced. That line is the whole point.
Then go page by page: Now that nothing is systematically broken, per-page work is worth doing.

Audit 25 pages, not 5,000

The instinct is to crawl everything. Resist it.

Almost every site is a handful of templates wearing different content. Audit 25 pages chosen across those templates and you find nearly every repeating problem the site has. Auditing 5,000 finds the same ten problems five hundred times each and buries the two genuinely unique ones.

Google puts the crawl-budget threshold at roughly a million pages changing weekly. If that is you, a dedicated crawler earns its place. For everyone else, the twenty-sixth page rarely tells you anything the first twenty-five did not.

There is a second reason. A fix list you can finish is worth more than a complete one you will not start.

What this will not do

It is not an unlimited scheduled crawler: If you need a nightly crawl of every URL you own with historical graphs, a dedicated crawler is the right tool and I would say so.
It grades mechanics, not quality: An automated check catches a missing H1 or a 404. It cannot tell you your post is boring or off-intent.
Speed is a separate pass: Core Web Vitals need field data from real visitors. Reading your HTML is not measuring what your users experience.
It cannot tell you what to care about: The audit sorts by severity and reach. It does not know that one of those 38 pages earns 80% of your traffic. Bring your own Search Console data and the priorities change.

How I run it

Full disclosure, I build one of these. ContextBolt SEO is a hosted SEO MCP server. You get one URL, you paste it into Claude Code, Claude Desktop, Cursor, or Codex, and your agent can run both audits. page_audit covers one URL, site_audit covers the site.

It reads the sitemap, picks the structurally important pages, checks titles over 60 characters, descriptions outside 120 to 155, missing or multiple H1s, thin content, broken pages, redirecting sitemap entries, canonicals pointing nowhere, and missing alt text, then hands back a score out of 100 with a fix list sorted worst first. Cross-page duplicates come free, because it holds every page at once. The default run is 25 pages. It costs $35 a month.

The part I care about is the second run. Ask again and it re-checks the pages already in your report, least recently checked first, and leads with the delta rather than a fresh report. It never quietly audits new pages and bills you for it.

Every run writes to one living report per site at ./seo-findings/audits/ as plain markdown, growing in place rather than spawning a new file each time. The audit trail sits in the repo next to the code it is grading.

If you would rather not pay for anything, you still get most of the way there. Search Console flags indexing problems across your whole site for free and it is your own data, which makes it the most trustworthy source you have. A free desktop crawler covers a few hundred URLs. The method works either way.

The longer walkthrough, with the full check list and the page-level companion, is in my site audit with Claude guide.

The version of a site audit worth running is not the one that finds the most problems. It is the one you run twice.

AI Answers Name a Few Brands. Is Yours One?

David Hamilton — Fri, 17 Jul 2026 13:13:25 +0000

More people start their research by asking an AI than by typing into a search box. And the AI does not hand back ten blue links. It answers in a paragraph, names two or three tools, and moves on.

If your brand is one of the names, you win the buyer before they ever reach a search result. If it is not, you are invisible, and the worst part is you cannot see it happening. Nothing shows up in your analytics. There is no impression count for "times an AI recommended someone else."

That gap is what AI search visibility measures. Not "do I rank on Google," but "when a buyer asks an AI in my category, does it say my name."

Why one prompt tells you nothing

The instinct is to open ChatGPT, ask "what are the best tools for X," and see if you show up. Do not trust that answer. It is one roll of the dice.

Two things make a single check meaningless.

The engines barely agree. One 2026 study found only about 11 percent of the domains ChatGPT cites overlap with the ones Perplexity cites. Showing up in one says almost nothing about the others.
The engines behave differently. An analysis of 2.4 million answers found Claude names brands in about 97 percent of its responses, while Perplexity does so in under half. Same question, completely different odds of any brand getting named at all.

So real visibility is not a lucky reply. It is a measurement across many prompts and several engines, counted.

The three questions a real check answers

Do I appear at all? For the prompts a buyer would actually type, does your brand surface anywhere.
How do I compare? Out of all the brands named in your category, what share of the mentions are yours. This is your AI share of voice.
Where am I missing? The specific prompts and engines where a rival gets named and you do not. That list is your content and PR to-do.

Answer those three and you have gone from a vague worry to a scoreboard.

The free way to do it

You can run this by hand today, no tools.

Write 5 to 10 prompts a real buyer would ask. Not "is [your brand] good," that one is cheating. Ask the neutral category questions, like "what is the best affordable SEO tool for a solo founder." Run each one across ChatGPT, Claude, and Perplexity in fresh sessions. Tally who gets named.

That gives you an honest baseline. The catch is it is slow, and it does not repeat cleanly. Do it again next month and the wording drift and session randomness make the two runs hard to compare. Which is a problem, because the whole point is the trend.

Doing it inside the agent

This is the job I moved into my AI agent so it repeats without the manual grind.

I use ContextBolt SEO. Two tools cover it. ai_visibility checks whether a brand surfaces for a set of prompts. ai_share_of_voice measures your mention percentage against named competitors. I ask in plain language, the agent runs the checks, and because it lives in the same chat, I go straight from the numbers into "so which prompts am I losing, and what would I write to fix it." It is $35 a month flat, and it keeps the history, so month two is actually comparable to month one.

The honest framing I hold it to. AI visibility is a sample, not a census. It is estimates from a batch of prompts, not a reading of every answer every engine gives. The same tool can wobble week to week because the engines are not deterministic. So I watch the trend over months, never a single snapshot. Trend beats the snapshot every single time.

The takeaway

Search used to end with a ranked list you could go read. More and more it ends with a sentence that names a few brands and stops. Whether you are in that sentence is now a real metric, and right now only around 14 percent of marketers track it, even though a lot more say AI search is a 2026 priority.

The ones checking will know which prompts they are losing and go fix them. Everyone else will keep guessing why the pipeline is quiet. Pick a handful of buyer prompts, run them across a few engines, and count. Whether you use a tool or a spreadsheet, start counting before your competitors do.

If you want the longer version with the full workflow and the honest limits, I wrote up AI search visibility here.

n8n MCP Means Three Things. Here's Each One (2026)

David Hamilton — Mon, 13 Jul 2026 14:06:28 +0000

You built an n8n workflow that does something genuinely useful. It watches a form, enriches a lead, posts to Slack, whatever. Then you sit down in Claude or Cursor to work, and your agent has no idea that workflow exists. You are back to copy-pasting between two tools that should be talking to each other.

That gap is what MCP closes. But if you search "n8n mcp" you land on three different setups wearing the same name, and people wire up the wrong one all the time. Here is each one, in plain English.

n8n MCP means three things

1. n8n as an MCP server. You expose one or more of your workflows as tools an outside AI agent can call. You add the MCP Server Trigger node, give it a clear name and description, attach the workflow tools you want to expose, activate it, and copy the URL plus bearer token. Now Claude or Cursor can call your automation as if it were a native tool. In 2026 n8n also shipped a native instance-level MCP server (public preview) that exposes selected workflows without you building the trigger by hand.

2. n8n as an MCP client. The other direction. Inside an n8n AI Agent workflow you drop the MCP Client Tool node, point it at some external MCP server, and now your workflow can reach that server's tools mid-run. This is how you give an n8n automation live data or actions it did not have before.

3. The community server that builds workflows for you. Separate from both. The czlonkowski/n8n-mcp server teaches your coding agent n8n's roughly 2,000 nodes, so you can describe an automation in a sentence and the agent drafts a validated workflow you import. Treat the output as a first draft you review, not a finished build.

Most "n8n mcp" tutorials pick one of these and never tell you the other two exist. When your setup does not behave the way a guide promised, it is usually because you followed instructions for a different one of the three.

Which one do you actually want

You want your AI agent to run your existing automations -> n8n as a server (role 1).
You want an n8n workflow to reach outside tools -> n8n as a client (role 2).
You want the agent to build the workflow for you -> the community server (role 3).

They compose. A single AI Agent workflow can be a client of three servers and be exposed as a server itself. That is the whole point of the protocol, but it is also why the terminology trips people up.

A few things that break setups

Wrong node. The MCP Server Trigger and the MCP Client Tool are not interchangeable. Server exposes, client consumes.
Skipping auth. An exposed n8n instance is an attack surface. Lock every endpoint. The instance-level server is a broad grant, so scope it deliberately.
The 5-minute timeout. n8n caps MCP-triggered executions at five minutes even if the workflow itself is set higher. Long jobs need a different pattern.
Weak tool descriptions. The agent picks tools by their descriptions. Vague names in, wrong tool called out.

Your instance is only half your context

Here is the part worth sitting with. Once your workflows are callable from your agent, the agent is smarter about your systems. It still knows nothing about your research. The gotcha you saved on X last week, the Reddit thread that solved this exact auth error, the LinkedIn post with the pattern you meant to steal. That context lives in three apps with no export button and no way for an agent to read it.

I build ContextBolt Bookmarks to close that side. It captures automatically from X, Reddit, and LinkedIn, AI-tags every save so you find things by meaning, and on Pro ($6/month) gives your library a personal MCP endpoint. So you wire two connectors into your n8n agent, not one. Your workflows on one side, the research you already saved on the other. The free tier holds 150 bookmarks with the same tagging and search, so you can test the shape before paying anything.

If you want the full setup walkthrough for all three roles, with the config blocks per client, I keep a running n8n MCP server reference here.

The one opinion worth holding

Keep n8n boring and reliable, and use MCP to connect it. Three deliberate connections beat one AI agent holding the keys to your entire instance. Wire the specific workflows you trust, name them well, and let the agent call them. That is the version of this that survives contact with a real workflow you depend on.

Local-first bookmark managers are back. Two ideals most of them quietly skip.

David Hamilton — Fri, 10 Jul 2026 16:12:38 +0000

Two of the most loved read-later apps on the internet shut down inside eight months of each other. Omnivore went first, acquihired by ElevenLabs and switched off on November 15, 2024. Then Pocket, after Mozilla let it wither for years, shut on July 8, 2025 and took roughly 35 million libraries with it.

Neither died because the technology failed. They died because the business around them stopped making sense to somebody in a meeting.

So a whole category of bookmark tools came back with a single promise. Run it yourself. Self-hosted, Docker-composed, SQLite on a disk you can hold. Nobody can take this away from you.

I build a bookmark tool, so I have skin in this. And I think the people building the self-hosted wave are right about the problem and slightly wrong about the fix. Local-first won the argument. It has not yet won the job.

What local-first actually means

The phrase is not marketing. It comes from a 2019 essay by Ink & Switch, and it is specific enough to argue with. Local-first software keeps the primary copy of your data on your own device. The network is an enhancement, not a dependency.

The manifesto lays out seven ideals a local-first app should hit:

Fast, because reads and writes never wait on a server
Multi-device, so your stuff follows you
Offline, meaning full function with the wifi off
Collaboration, so other people can still work with you
Longevity, meaning the software outlives the company
Privacy, because the data never has to leave your machine
User control, the right to take your data and go

Seven. Read that list again, because almost every conversation about local-first bookmarks only ever discusses three of them.

Grade a self-hosted bookmark app honestly

Take a typical self-hosted bookmark manager (Karakeep, Linkwarden, both genuinely excellent) and grade it against the seven ideals it is implicitly claiming.

Ideal	Typical self-hosted app	Honest grade
Fast	Local database, no round trip	Excellent
Offline	Works with the network unplugged	Excellent
Privacy	Data never leaves your box	Excellent
User control	Your disk, your file	Excellent
Multi-device	Needs a server, a domain, a VPN, or all three	Depends on your patience
Collaboration	Rarely a goal, often absent	Weak
Longevity	Survives the vendor. Does not survive you.	The quiet failure

Four straight wins. Those are real, and they are why the category deserves its comeback. The bottom row is where it gets uncomfortable.

The longevity everyone cites and nobody tests

"The software works in ten years even if the vendor is gone." Fine. Does it work in ten years if you are gone? Not dead. Just busy.

A self-hosted bookmark manager you stopped patching, whose Docker image is three majors behind, whose backup cron job silently broke in March, is not safer than Pocket was. It is a shutdown with extra steps. Pocket at least emailed you. Your unmaintained container will not.

Self-hosting does not delete the risk of losing your library. It moves the risk from a company with a status page and a paid ops team to a person who has a day job. For the folks who already run a NAS and have actually restored from a backup, not just configured one, that trade is clearly correct, and they know who they are. For everybody else, "I own the data" quietly means "I am now the single point of failure."

The saves a local-first app cannot reach

There is a second gap, and it is bigger than the first.

Open your phone and think about where you actually save things now. You are not copying URLs into a self-hosted web app. You are tapping the bookmark icon on a post in X, hitting save on a Reddit thread, tapping save on a LinkedIn article. That is where saving happens now, inside the platform, one tap, twenty times a week.

Local-first bookmark managers cannot see any of it. There is no export button on your X bookmarks. Reddit shows you roughly your last thousand saves and no more. And these saves are pointers, not copies, so when the original post is deleted your bookmark quietly rots.

So the sovereign, private, offline library you built contains the twelve links you were motivated enough to file by hand. The four hundred things you actually saved are still trapped in three apps that do not care about them.

Escapable and machine-readable beat local and cloud

I think local-versus-cloud is the wrong axis to organize your choice around. Two other properties predict whether a library survives and stays useful, and they cut across both camps.

Escapable. Can you get everything out today, in a format another tool will read, without asking permission? Not "is there an export feature buried in settings." Have you run it? A cloud app with a one-click complete export is more escapable than a self-hosted app whose data sits in a schema only it understands. Pocket's failure was not that it was cloud. It was that 35 million people had never tested the exit.

Machine-readable. Can something other than the app's own search box read your library? For the last twenty years this did not matter much. It matters enormously now, because the thing you most want to do with a decade of saved links is ask an AI about them. A library your agent cannot reach is an archive, not a tool. This is what MCP exists to solve, a standard way for an AI agent to read a data source directly.

A private SQLite file nothing can read is sovereignty with nothing to show for it. You own it completely and it does nothing for you.

Where I land

I build ContextBolt Bookmarks, so let me be straight rather than clever. It is not local-first. Pro syncs your saves to encrypted cloud storage. If you want the seven ideals in full, run Karakeep. I mean that. It is a good piece of software and the people building it are serious.

It optimizes for the two gaps above instead. It captures automatically from X, Reddit, and LinkedIn, which is where saving actually happens and which no local-first tool reaches. It AI-tags every save with a topic so you find things by meaning rather than remembering a keyword. And Pro ($6/month) gives your library a personal MCP endpoint, so Claude, Cursor, and Windsurf can query your saves mid-conversation. The free Basic tier holds 150 bookmarks with the same tagging and semantic search.

That is a trade, and I would rather name it than pretend it away. If vendor independence is the thing you care about most in the world, this is the wrong tool and you should not buy it.

What I would push back on is the idea that self-hosting settles the question. It answers one risk loudly and leaves the other two untouched. The library still has to be findable, and it still has to be readable by the machine you now ask everything.

Local-first got the diagnosis right. The prescription is still being written.

If you want the longer version, with the full seven-ideal scorecard and the self-hosted graveyard nobody talks about, I wrote it up here: local-first bookmark managers.

What Competitor Monitoring Looks Like When It Judges the Change for You

David Hamilton — Mon, 06 Jul 2026 14:29:38 +0000

Most competitor monitoring tools have the same flaw. They tell you something changed, then hand the thinking back to you.

You get a red-highlighted diff in your inbox. A rival's pricing page moved. Great. Was it a real price change, or did they swap a testimonial and bump the copyright year? You open the tab, squint at the two versions, work out that it was nothing, and close it again. Do that for five competitors across pricing, homepage, changelog, and sitemap, and the tool that was supposed to save you time is now a second inbox you dread.

The data was never the hard part. Judging it was. And judging it is exactly the part a raw diff refuses to do.

Here is the workflow I moved to instead, and why it stuck.

The idea in one line

Move the monitoring into the AI agent you already work in, and let the agent do the judging.

That is what competitor monitoring with AI actually means once you strip the hype off it. Not "a dashboard with a chatbot bolted on." An assistant that watches the competition, decides what is signal and what is noise, and tells you in plain language what a change means.

What changes when the tool judges

A change detector can only point. It says "this pixel is different." An AI monitor reads the change and calls it. Cosmetic churn dies silently. A real move arrives with four things:

what changed
what it means
a link to the page
a suggested response

That last one is the part a dashboard structurally cannot reach. A dashboard does not have your files, your voice, or your product. An agent does. So it does not stop at "Acme raised their Pro tier from $29 to $39." It can go on to "here is the pricing-page tweak that presses that gap, want it in review." The alert becomes a first draft.

I have started calling that last step the counter-move, because "alert" undersells it. The whole reason to watch a competitor is to do something about what you see. Every other tool stops one step short of the only step that matters.

What is actually worth watching

Not everything. Five surfaces carry almost all the real signal for a software competitor:

Pricing pages. The highest-signal page there is, and the worst one to point a dumb detector at (currency toggles, A/B tests, and rotating promo banners all trip a raw diff).
Homepage. Positioning shifts. A headline moving from "for solo founders" to "built for teams" is a strategy telegraph.
Changelog / releases. What they are shipping, and how fast.
Sitemap. Unannounced pages show up here before they show up anywhere else. This is how you see a launch coming.
Search footprint. The terms they are starting to rank for tell you where they are aiming next.

The judging is what makes watching five surfaces across five competitors survivable. Without it, you drown.

Why inside the agent, specifically

Because the monitoring and the reaction stop being two separate jobs. The thing that spots the move is the thing that drafts the response, in the same conversation. No exporting a diff, no pasting it into a doc, no writing the counter-move from scratch an hour later when the urgency has drained out of it.

It does not replace an enterprise competitive-intelligence platform if you have a sales team and an analyst to run a battlecard program. It replaces the gap most founders actually live in, which is "I know I should watch my competitors and I never do, because every tool I tried became noise."

How I set it up

I use ContextBolt Radar. You name up to five competitor domains once. It checks their pricing, homepage, changelog, sitemap, and search footprint every night, judges each change, and emails one briefing every Monday. There is no dashboard. When nothing meaningful happened, it stays quiet, which turns out to be most weeks and is the point. Any time you are curious you just ask your agent "what did my competitors do this week." It runs inside Claude, Codex, or Cursor, and it is $39 a month.

The takeaway

Competitor monitoring was never a detection problem. Detection is easy and mostly free. The expensive part is judgment, and the only useful part is the response. Put both of those where you already do your thinking, and watching the competition stops being a chore you skip.

If you want the longer version, with the two-kinds-of-monitoring map and the honest limits, I wrote it up here: competitor monitoring with AI.

What Is an SEO MCP Server? (And Why I Stopped Opening a Dashboard)

David Hamilton — Tue, 30 Jun 2026 15:18:15 +0000

For two years my SEO workflow was the same loop: think of a question, open a browser tab, log into a dashboard, click around, export a CSV, paste it somewhere my AI assistant could read it, then ask the actual question. The dashboard was the bottleneck, not the data.

So I moved the data to where I already work. These days I ask Claude a keyword question and it answers from live SEO data directly, no tab, no export. The thing that made that possible is an SEO MCP server.

Here is what that actually means.

MCP in one paragraph

MCP (the Model Context Protocol) is an open standard that lets an AI assistant call external tools in a structured way. If you have used a "connector" in Claude or Cursor, that is MCP underneath. An MCP server exposes a set of tools, the model decides when to call them, and the result comes back as context the model can reason over. It is the difference between pasting a spreadsheet into a chat and letting the assistant fetch the numbers itself.

So what is an SEO MCP server?

It is an MCP server whose tools are SEO operations instead of, say, file reads or calendar events. A good one gives the model things like:

keyword research and difficulty scoring
SERP results and ranking data for a query
domain and competitor overviews
backlink data (referring domains, gap analysis)
Google Search Console data for your own site
AI visibility, how often your brand shows up in ChatGPT and Google's AI answers

The model calls those tools mid-conversation. You stay in one window and ask follow-ups in plain language: "compare the difficulty of these five terms," "which of my pages is closest to page one," "what does the top result for this query have that I don't." The assistant runs the lookups and reasons over the results together, which is the part a dashboard cannot do because a dashboard does not know what you asked last.

Why this beats the dashboard for day-to-day work

Three reasons it stuck for me:

No context switching. The question and the answer happen in the same place I was already thinking.
Composability. Because the model can chain tool calls, "find my striking-distance pages, then pull the SERP for each, then tell me which is most winnable" is one request, not forty clicks.
It writes as it analyzes. The assistant that just pulled the data is the one drafting the brief, the meta description, or the internal-link plan off the back of it.

It does not replace a full audit suite for enterprise teams. For a solo founder or a small team that lives inside an AI assistant anyway, it removes the most annoying step in the loop.

How I set it up

I use ContextBolt SEO. It is a hosted SEO MCP server: you add one connector to Claude, Cursor, or Codex, and the SEO tools show up. The data is DataForSEO under the hood (the same provider behind a lot of SEO products), so it is real keyword, SERP, and backlink data, not a model guessing. Search Console connects read-only, and it keeps a small memory layer so your past lookups are still there next session. It is $35 a month, which is what pushed me off the bigger suites for this particular workflow.

If you want to try the concept without paying, you can wire up the public DataForSEO MCP yourself and point your assistant at it, that is the DIY version of the same idea. I went with the hosted one because I did not want to babysit credits and config.

The takeaway

An SEO MCP server is not a new kind of SEO tool. It is the same data, delivered to the place where you already ask questions. Once the analyst lives inside the assistant, "open the dashboard" stops being step one, and that turns out to be most of the value.

If you want the longer version with the exact tools and prompts, I wrote it up here: SEO MCP server.

The MCP Servers I Actually Use With Claude in 2026

David Hamilton — Sat, 30 May 2026 20:28:20 +0000

The MCP ecosystem went from a handful of servers to thousands in under a year. Most of them are demos you connect once and forget. A few have quietly become part of how I work every day.

This is the short list that earned a permanent spot in my Claude setup as a solo founder, grouped by what I am actually trying to get done. No affiliate links, no rankings for the sake of it. Just the ones I would reconnect first on a new machine.

The two every setup needs

Filesystem (the official server) lets Claude read and write local files. Boring, essential, and the first thing I connect anywhere.

GitHub brings issues, PRs, and code search into the chat. If you write code, it is the highest-leverage connection after filesystem.

Marketing and growth

This is where MCP stopped being a novelty for me and started saving real hours.

The Google Search Console MCP pulls my live query and impression data into Claude, so I can ask "which pages slipped this week" and get an answer without opening the GSC dashboard.

The Google Analytics MCP server does the same for GA4: sessions, events, and conversions, all queryable in plain English.

If you run sales, the HubSpot MCP server lets Claude read and update contacts, deals, and companies. That turns "draft a follow-up for everyone in the pipeline who went quiet" into a single prompt.

Connecting all three means one question can span search data, analytics, and CRM, and Claude stitches it together. That is the part that still feels like magic.

Automation glue

The n8n MCP server is the one I reach for when a workflow needs to run on a schedule instead of whenever I happen to be in a chat. Weekly digests, smart routing, alerts. n8n already connects to almost everything, and MCP lets Claude drive it.

Knowledge and memory

Claude forgets everything between chats. These servers fix that.

Obsidian and Notion servers expose your notes so Claude can search them and write back.

ContextBolt (full disclosure: I built this one) gives Claude semantic recall over the things I save from X, Reddit, and LinkedIn. I save a thread, and three weeks later I can ask "what was that take on pricing I saved" and get it back with the source. It exists because I kept saving things and never finding them again.

How to pick

Two rules that have served me well:

Connect for a job, not for a demo. A server you use once is clutter.
Read the setup notes before you wire up auth. Half of these put a token in a config file or a URL, and the gotchas vary by server.

That second rule is why I keep a running directory of the best MCP servers with per-server setup steps, auth notes, and the gotchas I hit, sorted by category. It started as my own notes. Now it is a public MCP server directory you can browse by job instead of scrolling one giant list.

If you are just getting started, connect filesystem, then add one server for the job in front of you. Build from there.

I deleted the chat feature from my own AI product. Here's what I built instead.

David Hamilton — Wed, 06 May 2026 22:09:56 +0000

I deleted the chat feature from my AI product.
The irony writes itself. A small Chrome extension whose entire purpose is bringing AI to your saved content. The first thing I cut was the AI-shaped feature.
It was the easiest call I've made on this build.
Three reasons. Each one obvious in hindsight.
API costs. A back-and-forth chat conversation eats £1-2 a month in tokens per active user. My Pro tier is £4 a month. The maths doesn't work the day you launch. It only gets worse with scale.
Product bloat. A chat box is the kind of thing you build because every other AI product has one. It looks like the AI feature. It isn't.
V2. If users actually want to chat with their bookmarks, they'll tell me. I'd rather build it then than guess now.
The product is called ContextBolt. It captures your bookmarks from X, Reddit, and LinkedIn. It auto-tags each one with Claude. And then it does something most products in 2026 still don't.
It exposes itself to Claude.
Pro users get a personal MCP endpoint. They paste one URL into Claude Desktop. From that moment on, Claude can search their entire bookmark library mid-conversation. You ask Claude something. Claude reads your saved content. The answer arrives with the context already in it.
The dashboard I built first turned out to be the legacy interface. The MCP endpoint is the actual product.
That's the irony resolved. The chat box was never the AI part. The integration was the AI part. I just couldn't see it until I deleted what I thought it was.
Here's the part I find harder to explain.
I'm one person. I have a day job. I get about ten hours a week on this thing, mostly evenings and weekends. The amount of code in this product is not the amount of code one person could write in ten hours a week.
I didn't write most of it.
Claude did.
I use Claude Code. I describe what I want in plain English. Claude writes the service worker. Claude writes the Cloudflare Worker. Claude writes the React dashboard. Claude writes the SQL migrations. I read what comes back, push back where the taste is off, and ship it.
Two days ago Google approved the extension on the Chrome Web Store. I downloaded my own production build. Within an hour I'd found four bugs in real-world testing. The LinkedIn dashboard didn't refresh on save. The X popup showed a scraped count instead of a deduplicated one. The auto-scroll stalled at twenty bookmarks. The licence-key save flow failed silently.
I described each symptom out loud. Claude found the wrong file (a content script that was dead code, while the loaded one had no listener). Claude wrote each patch. We shipped five extension versions and two worker deploys that evening. I never opened a debugger.
That is what working with Claude actually looks like in 2026. It is not autocomplete. It is a colleague who reads the whole codebase faster than you can blink, fixes the thing, and writes the commit message while it's at it.
The infrastructure is the other surprise.
The whole product runs on Cloudflare. Pages for the website. Workers for the API. D1 for the database. KV for the rate limits. Vectorize for the semantic search. There is no AWS bill. There is no Vercel bill. There is no managed database bill.
Including Claude API spend, the entire stack costs me under £5 a month at current usage. I keep waiting for that to be a lie. So far it isn't.
The marketing flywheel is the same recursive shape.
Thirty-three blog posts on the site. Sixty-six programmatic SEO pages. Every post drafted with Claude. Every meta description checked by Claude. Every internal link suggested by Claude. The site's scheduled tasks run with Claude reading my Search Console and writing the next thing to fix.
I review. I edit. I ship.
The asymmetric stack is the only reason a one-person, ten-hour-a-week build can keep up with funded teams. Claude does the parts that scale linearly with effort. Writing. Debugging. Testing. Drafting. I do the parts that don't. Taste. Decisions. Picking what to ship. Picking what to delete.
I keep coming back to that last one.
The chat box was never the AI part. It was the legacy UI we used while we figured out what the AI part actually was. The AI part is the integration. The AI part is your existing tools getting access to context they didn't have before.
Most AI products in two years will look like ContextBolt. A small piece of software that does one thing well and exposes itself to whatever model the user already pays for. The product team doesn't have to ship the chat box. The user already has one.
That's why deleting the chat was easy. Once you see it, you can't unsee it.
ContextBolt is live on the Chrome Web Store today. The site is at contextbolt.com. If you save more than you read, you'll feel it the first time Claude finds something for you that you'd already given up on.
I'd love to know what you'd connect it to.