DEV Community: Artyom Rabzonov

I built a one-command, whole-site AEO/GEO audit that hands your agent a plan.json

Artyom Rabzonov — Wed, 03 Jun 2026 10:53:08 +0000

TL;DR - ai-seo-magic-button is a free, MIT-licensed tool that crawls your whole site, runs ~39 AEO/GEO checks on every page, and outputs a plan.json (plus markdown checklist) your AI agent executes. Installs three ways - Claude skill, Claude Code plugin, or MCP server in any host - no API keys for the core flow. npx -y ai-seo-magic-button mcp

What it is - AI search is decoupling from classic SEO: top-10 Google rank no longer means an LLM cites you. The "will an AI quote this page" list is different (structured data, extractable answer sections, llms.txt, freshness) and has to be consistent sitewide. Most tools monitor where you're cited and stop; the magic button turns a whole-site audit into a ranked, executable plan.

Why - We already ship two MCP engines (one scores a page for AEO/GEO, one tracks what LLMs cite). Running them page by page and triaging into a to-do list was the tedious part. The magic button is the orchestration layer that emits one artifact an agent can run.

How it works (two-step flow)

Run the skill → get a plan. Crawls every page, runs the full audit, ranks fixes by estimated score lift, folds cross-page gaps (no sitemap, missing llms.txt, schema absent sitewide) into single items. Output: plan.json + plan.md.
Run your agent against the plan. Each item carries a baked tool call + acceptance check, so the agent executes sequentially. Analyze-and-propose only - nothing changes until you run apply.

Install (all three surfaces)

# Option A - Claude Code plugin (recommended)
/plugin install https://github.com/AutomateLab-tech/ai-seo-magic-button
# Option B - MCP server in any host (Cursor, Cline, Windsurf, Claude Desktop, ...)
npx -y ai-seo-magic-button mcp
# Option C - Claude skill only: copy skill/ into .claude/skills/ai-seo-magic-button/

{ "mcpServers": { "ai-seo-magic-button": { "command": "npx", "args": ["-y", "ai-seo-magic-button", "mcp"] } } }

Example - Ask your agent: "Run the AI SEO magic button on example.com and show me the top 5 fixes." The generate_seo_plan tool returns the plan as structured content. CLI adds audit, apply (idempotent), verify (before/after score diff), sink (push items to a Notion board).

Links - Product page: https://automatelab.tech/products/skills-and-plugins/ai-seo-magic-button/ · GitHub: https://github.com/AutomateLab-tech/ai-seo-magic-button · npm: https://www.npmjs.com/package/ai-seo-magic-button · Plan format: https://github.com/AutomateLab-tech/ai-seo-magic-button/blob/main/docs/plan-format.md

How we made our site agent-ready with WebMCP (and what it bought us)

Artyom Rabzonov — Tue, 02 Jun 2026 10:10:41 +0000

TL;DR: We wired every tool and search box on automatelab.tech to AI agents using WebMCP - the navigator.modelContext browser API - by reusing the functions our on-page buttons already call. It now shows up in Lighthouse's new Agentic Browsing audit. Here is how, and an honest read on whether it is worth your time in 2026.

What WebMCP is

WebMCP is a browser API (navigator.modelContext) that a page calls to register tools for an in-browser AI agent. Each tool carries a name, a natural-language description, a JSON input schema, and a handler that runs when the agent calls it. It is the browser-side cousin of the Model Context Protocol that server-side integrations already speak. The spec is a W3C draft from the Web Machine Learning group.

The honest part: WebMCP ships only in Chrome 146 behind a feature flag, real-world adoption is near zero, and most agents today still read the raw DOM. This is a plant-the-flag move. Two reasons to do it anyway: it is cheap if your pages already have working actions, and Google just started measuring it.

Registering a tool

There are two paths. The declarative one adds toolname and tooldescription attributes to an existing <form> and the browser builds the input schema for you. The imperative one calls registerTool(). We took the imperative path because every tool already had a compute function:

if (navigator.modelContext) {
  navigator.modelContext.registerTool({
    name: "audit_ai_seo",
    description: "Audit a URL for AEO/GEO readiness; return the score.",
    inputSchema: {
      type: "object",
      properties: { url: { type: "string", description: "Full URL incl. https://" } },
      required: ["url"]
    },
    execute: async ({ url }) => {
      const result = await runAudit(url);   // the function the page already had
      return { content: [{ type: "text", text: result.summary }] };
    }
  });
}

The point: you are not writing new tools, you are exposing the ones you already shipped. The whole integration is a roughly forty-line helper that feature-detects navigator.modelContext and no-ops in every browser without it, so normal visitors are unaffected.

What we exposed

Ten surfaces, each reusing the function behind its on-page button:

Surface	WebMCP tool
AI SEO Checker	`audit_ai_seo`
AI Overview checker	`score_ai_overview_eligibility`
n8n cost calculator	`estimate_n8n_cost`
n8n workflow validator	`validate_n8n_workflow`
GPTBot / robots.txt helper	`get_ai_crawler_robots_rules`
Blog search	`search_blog`
Automation Error Index search	`search_automation_errors`

The Lighthouse angle

Lighthouse 13.3 added an Agentic Browsing category. The WebMCP check is informational only - it lists the tools your page registers and never fails you for having none. The other three checks (llms.txt, accessibility-tree integrity, and layout stability) pay off today regardless of WebMCP adoption: they help screen readers, retrieval crawlers, and real users.

Is it worth it in 2026?

Do the agent-readiness groundwork for the wins you can bank now - ship llms.txt, fix the accessibility tree, kill layout shift - and treat the WebMCP registration as a cheap option on a standard that might matter in a year. One caveat worth taking seriously: the WebMCP security model is still incomplete, so never expose a destructive or account-changing action without a user-confirmation step. Read-only audits, calculators, and search are safe first candidates; "delete my account" is not.

Full write-up with the step-by-step: https://automatelab.tech/blog/al-products/how-we-made-automatelab-tech-agent-ready-webmcp/

Launching the seo-performance MCP

Artyom Rabzonov — Thu, 28 May 2026 12:52:46 +0000

TL;DR: seo-performance-mcp pulls Google Search Console, GA4, Matomo, Clarity, and AI-citation data per URL and emits a verdict per post (refresh, expand, merge, kill, double_down, hold) with explicit reason codes.

We just published @automatelab/seo-performance-mcp on npm. It is a Model Context Protocol server for the part of SEO that starts after the post goes live: triage. Which URLs are decaying, which are quietly winning, which lost an AI citation last week, which sit at position 7 with a low CTR and want a title rewrite. Free, MIT-licensed, no email gate.

What does seo-performance-mcp do?

Most SEO tooling stops at "the post is live." This MCP starts there. For any URL on your site it pulls Search Console (clicks, impressions, CTR, position, top queries), GA4 (pageviews), Matomo (visits, dwell), Microsoft Clarity (scroll depth, rage clicks), and AI-citation counts from a configured citation-intelligence endpoint. Every signal source is optional. Provide the env vars for the platforms you use; the rest are skipped silently.

The data flows through a deterministic verdict engine. It combines the snapshot with a 12-week GSC decay curve and emits one of six calls per post: refresh, expand, merge, kill, double_down, or hold. Each verdict carries explicit reason codes (the rules live in src/verdict/rules.ts and can be inspected) and a 0-1 confidence score. The mapping is rules-based, not LLM-based, so the same inputs always produce the same call.

Reporting only. The server never edits a post, never publishes anything, never touches a third-party platform with anything other than a read. The verdict and the refresh brief are hand-off artefacts for a writer, an editor, or a downstream rewrite tool.

Which tools does it ship?

Eight tools, organised as a dot-notation tree: posts.* for per-URL analysis, cohort.* for cross-post roll-ups, gsc.* for direct Search Console scans.

posts.list: Discover indexable posts via an XML sitemap, a JSON override list, or the Ghost Admin API. Filter by minimum age or published-after date.
posts.snapshot: Pull a 30, 60, or 90-day snapshot across every configured signal source for one URL. Each source is best-effort.
posts.decay_curve: Bucket GSC clicks, impressions, and average position into weekly windows and classify the trend: decay, plateau, or growth. Underpins the verdict engine's decay rules.
posts.verdict: Run the rule-based verdict engine on one URL. Returns verdict, reason codes, and confidence.
posts.refresh_brief: Produce a markdown brief for a human or downstream LLM editor: verdict, reasons, raw numbers, top queries, suggested actions.
posts.cite_loss: Return the list of LLMs that previously cited this URL but no longer do, with the prior query and last-seen date. Optionally identifies the URL that replaced yours.
cohort.report: Run the verdict engine across a cohort filtered by tag and minimum age. Returns a ranked table sorted by verdict priority then confidence. Answers "which three posts should I refresh this week?"
gsc.quick_wins: Scan GSC for (page, query) pairs at positions 5 to 15 with non-trivial impressions and a CTR below the position-expected curve. The fastest title-rewrite wins. Platform-agnostic pure GSC pull.

Three discoverable prompts ship alongside: audit_cohort, find_quick_wins, citation_loss_sweep. No skill loader required; any MCP-capable client picks them up.

Install

Requires Node 20+. Add the server to your MCP host config (~/.cursor/mcp.json for Cursor, claude_desktop_config.json for Claude Desktop, .mcp.json for Claude Code), then restart the host.


json
{
  "mcpServers": {
    "seo-performance": {
      "command": "npx",
      "args": ["-y", "@automatelab/seo-performance-mcp"],
      "env": {
        "GSC_SERVICE_ACCOUNT_JSON": "/abs/path/to/gsc-service-account.json",
        "GSC_SITE_URL": "sc-domain:example.com",
        "MATOMO_BASE_URL": "https://example.com/analytics",
        "MATOMO_TOKEN": "...",
        "MATOMO_SITE_ID": "1",
        "GA4_PROPERTY_ID": "123456789",
        "CLARITY_PROJECT_ID": "...",
        "GHOST_ADMIN_KEY": "id:secret"
      }
    }
  }
}

Free AI SEO Checker: 39 AEO and GEO Checks Explained

Artyom Rabzonov — Tue, 26 May 2026 13:49:15 +0000

We just shipped a free, no-signup AI SEO checker that scores any URL across 39 checks for answer-engine optimization (AEO) and generative-engine optimization (GEO). Here's what it actually tests and why we built it.

The problem with existing SEO tools for AI search

Most SEO auditors check title length, keyword density, and Core Web Vitals. That's fine for Google's traditional ranking pipeline. But AI search engines (ChatGPT, Perplexity, Claude, Gemini) extract answers differently. They care about:

Whether your robots.txt blocks their crawlers
Whether your opening paragraph resolves the query in under 60 words
Whether your JSON-LD schema type matches what the page actually says
Whether your content renders in raw HTML (not behind JavaScript)

None of that shows up in Screaming Frog or Ahrefs.

What the 39 checks cover

The checker runs five categories, each weighted by signal strength:

Crawlability (6 checks, weights 3-5)

Checks whether GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot, and Amazonbot can reach your pages. A robots.txt that blocks Googlebot is usually fine; one that accidentally blocks GPTBot via a wildcard disallow is invisible to ChatGPT's index.

Also checks robots.txt accessibility (returns 200, not 401/500), sitemap presence, and canonical URL consistency.

Structured Data (7 checks, weights 2-4)

Validates JSON-LD presence, schema type alignment (does @type: Article match what you actually published?), required properties per schema type, OpenGraph and Twitter cards, and author attribution with Wikidata or LinkedIn links.

The author attribution check matters: several citation studies show AI systems favor content where the author has a verifiable external identity.

On-Page Content (11 checks, weights 1-4)

The most nuanced category. Key checks:

Check	What triggers it
Question-style heading ratio	Less than 30% of H2-H4s are question-form
Reading level	Flesch-Kincaid grade above 12
Answer density	Opening paragraph doesn't resolve the query
Internal link depth	Thin internal link structure
Image alt text	Images missing alt attributes

The question-heading threshold comes from a study showing 72% of ChatGPT-cited pages use question-style headings. The tool flags pages below the 30% ratio.

AI Readability (8 checks, weights 2-5)

Checks answer density in the opening paragraph (first paragraph should contain the core answer in under 60 words), render mode (page must have 200+ visible words in raw HTML to be parseable by non-executing crawlers), llms.txt presence, entity recognition, authorship signals, and outbound links to authoritative sources.

The render detection is important: a page that loads its content via React client-side rendering is effectively invisible to AI crawlers that don't execute JavaScript.

Technical Health (7 checks, weights 1-3)

HTTPS, mixed content, mobile viewport meta tag, payload compression, image dimension attributes, HSTS headers, and basic security headers. These are table-stakes checks that most sites pass, but the tool catches edge cases.

Scoring

Each check has a weight (1-5). The tool calculates category scores and an overall weighted letter grade:

A: 90+
B: 75-89
C: 60-74
D: 40-59
F: below 40

How it works technically

User pastes a URL
A server-side proxy fetches the HTML, robots.txt, sitemap, and llms.txt in a single request (bypasses CORS restrictions; nothing is stored)
All 39 checks run client-side in the browser
Results render immediately with evidence strings and remediation guidance per check

No login. No data stored. One URL per run.

Why free and no-signup

We want this to be the first tool developers and content teams reach for when they're wondering why their content isn't appearing in AI answers. The friction of a signup form is the wrong trade-off here. The @automatelab/ai-seo-mcp package is the commercial path for teams that need bulk audits inside Claude Code or Cursor workflows.

Try it

https://automatelab.tech/blog/al-products/free-ai-seo-checker-aeo-geo/

The tool is at the link above. If you find a check that's giving a false positive or a signal that should be weighted differently, open an issue or drop a comment.

Part of the AutomateLab AI automation stack. Also see @automatelab/ai-seo-mcp for Claude Code batch audits.

We were about to pay $400/month for an AI citation dashboard, so we built one

Artyom Rabzonov — Mon, 25 May 2026 13:52:55 +0000

Hosted AI citation dashboards (Profound, AthenaHQ, Otterly, Ahrefs Brand Radar) start at $295 to $499 per month. They tell you which URLs ChatGPT, Claude, Perplexity, Gemini, Google AI Overviews, and Bing cite for any query.

That data is mostly available through each vendor's own API. The dashboard is the product; the data is commodity. So we built Citation Intelligence MCP - a free, self-hosted MCP server that does the same job, with 12 tools, no backend, and per-query costs measured in cents.

What it does

12 tools across three jobs:

Job	Tools
Track citations	`check_citations`, `am_i_cited`, `ai_overview`, `cited_for`
Predict citations	`predict_citation`, `compare_domains`, `wikipedia_mentions`
Find leaks	`gsc_citation_gap`, `audit_sitemap`, `citation_trend`, `run_panel`, `track_queries`

Three of the tools (predict_citation, cited_for, wikipedia_mentions) run on a local cache and cost zero. The rest use your own keys.

Install

npx -y @automatelab/citation-intelligence

Wire into Claude Code by adding to .mcp.json:

{
  "mcpServers": {
    "citation-intelligence": {
      "command": "npx",
      "args": ["-y", "@automatelab/citation-intelligence"]
    }
  }
}

Bring your own keys for the paid tools:

export ANTHROPIC_API_KEY=...
export OPENAI_API_KEY=...
export GEMINI_API_KEY=...
export SERPAPI_API_KEY=...   # for Google AI Overviews

Cost is roughly $0.01 to $0.03 per query at premium engines, so a daily 50-query panel runs you about $20/month vs $400 for the hosted equivalent.

The report that made us actually ship this

The one that got us is gsc_citation_gap. It joins Google Search Console data with AI citation status and returns pages where you rank in Google but get zero AI mentions. The gap is the editorial budget.

> gsc_citation_gap site:automatelab.tech --threshold-impressions 1000

URL                                          GSC impressions   Cited by
/glossary/claude-code/                                 4,238   0 engines
/glossary/llms-txt/                                    3,102   1 engine (Perplexity)
/glossary/json-ld/                                     2,847   0 engines

Anything cited by zero engines and ranking on Google is a page that needs FAQ markup, query-shaped H2s, or a direct rewrite.

Why MCP-first

We did not want a dashboard. We wanted citation data inside the same agent loop that writes the post. An MCP server lives next to your editorial flow - the agent that drafts your next article can call predict_citation before writing the H2, then am_i_cited a week after publish.

The full launch write-up: https://automatelab.tech/launching-the-citation-intelligence-mcp/

Repo: https://github.com/automatelab/citation-intelligence

MIT licensed. No backend, no telemetry, no account.

I built an open dataset of 1,119 SaaS webhook events. Here's what surprised me.

Artyom Rabzonov — Wed, 20 May 2026 09:34:19 +0000

If you have ever tried to wire up webhooks from more than three SaaS apps, you already know the punchline: every vendor invented their own conventions, and none of them are wrong, but none of them agree either.

I was building agent tooling that had to understand many of them. Halfway through, I stopped trying to keep it in my head and started writing it down. Then I kept writing it down. The result is now an open dataset.

1,119 webhook events. 30 platforms. One schema. Free, CC-BY-4.0.

HuggingFace: automatelab/saas-webhooks
Browsable index: automatelab.tech/products/datasets/saas-webhooks/

What it is

A normalized catalog covering Stripe, GitHub, Slack, Notion, Linear, Jira, HubSpot, Salesforce, Zendesk, Intercom, Discord, Twilio, Calendly, Mailchimp, Zoom, Microsoft Teams, PagerDuty, Pipedrive, Asana, ClickUp, Front, Help Scout, Loom, Greenhouse, Ashby, BambooHR, Gusto, Attio, Close, and Freshdesk.

For every event, you get:

event_name and trigger_description
payload_schema as JSON Schema (draft 2020-12)
auth_method, signature_header, and the exact signing algorithm
delivery_guarantees and retry_policy
idempotency_key_header (if the vendor provides one)
docs_url back to the canonical vendor docs
Format: JSONL per vendor, plus Parquet for the full set

A sample row

Here is what a single Stripe event looks like, trimmed:

{
  "vendor": "stripe",
  "category": "payments",
  "event_name": "account.application.authorized",
  "trigger_description": "Fires when a user authorizes a Stripe application.",
  "auth_method": "hmac-sha256",
  "signature_header": "Stripe-Signature",
  "signature_algorithm_detail": "HMAC-SHA256 with versioned scheme; header contains timestamp and v1 hash. Verify timestamp to prevent replay attacks.",
  "delivery_guarantees": "at-least-once",
  "retry_policy": {
    "max_attempts": null,
    "backoff": "Exponential backoff over multiple hours.",
    "total_retry_window": "PT72H"
  },
  "payload_schema": { "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "properties": { "...": "..." } },
  "docs_url": "https://docs.stripe.com/api/events/types"
}

Same shape across all 30 vendors. That is the entire point.

The surprising stuff

A few things jumped out once everything was in one schema:

Signing is not standardized in any way. A small sampler:

Vendor	Auth	Header	Detail
Stripe	HMAC-SHA256	`Stripe-Signature`	Timestamp + v1 hash, replay-window enforced
GitHub	HMAC-SHA256	`X-Hub-Signature-256`	Plus legacy SHA1 on `X-Hub-Signature`
Slack	HMAC-SHA256	`X-Slack-Signature`	5-minute timestamp window
Shopify	HMAC-SHA256	`X-Shopify-Hmac-Sha256`	Base64 of HMAC of raw body
Linear	HMAC-SHA256	`Linear-Signature`	Hex digest only

Same algorithm, five different envelopes. Anyone writing one verifier and trying to reuse it has a bad afternoon ahead.

Retry policies are wildly different. Stripe retries for 72 hours with exponential backoff. GitHub does not retry by default at all (it depends on app type). Slack retries 3 times. Some vendors do not publish a retry policy in their docs, which means you should not rely on one.

Idempotency support is hit-or-miss. GitHub gives you X-GitHub-Delivery. Stripe gives you the event id. Several vendors give you nothing, which means you either dedupe by payload hash or accept duplicates.

Max payload sizes are mostly undocumented. GitHub publishes 25 MB. Most vendors do not say.

These are not opinions. They are facts I would rather not have had to learn the hard way.

Why this exists

I am building agents that integrate with many SaaS products. Two things have to be true for an agent to call any webhook tool correctly:

The agent needs the payload schema to know what fields it can rely on.
The agent needs the auth contract to know how to validate inbound deliveries.

If that information is scattered across 30 different docs sites in 30 different shapes, the agent cannot use it. Once it is in a single schema, the agent can.

Same logic applies to anything that has to interop with many vendors at once: an integration platform, a security scanner that audits webhook configurations, a docs site that needs to render comparison tables, a research notebook.

Use it however

from datasets import load_dataset

ds = load_dataset("automatelab/saas-webhooks")

stripe_events = ds["train"].filter(lambda r: r["vendor"] == "stripe")
print(stripe_events[0]["payload_schema"])

The dataset is CC-BY-4.0. No email gate, no sign-up. Attribution is appreciated when you ship something interesting on top of it.

It updates monthly from source. If you find a missing event or a vendor that should be there, the GitHub issue tracker is the right place to drop it.

Launching content-distribution-mcp: one finished post, eight channels

Artyom Rabzonov — Tue, 19 May 2026 20:00:34 +0000

We just shipped content-distribution-mcp: an MCP server that takes one finished post and routes it to eight developer-facing channels.

It makes zero LLM calls. Adapter I/O only. Whatever model your MCP host runs is the model that writes the per-channel copy — Claude, GPT-4, Gemini, a local Llama, or none at all if you bring your own text.

pip install content-distribution-mcp

Why we built this

Posting one blog article to DEV.to, Hashnode, GitHub Discussions, Bluesky, Reddit, LinkedIn, Twitter, and Medium is roughly 90 minutes of paste-and-fiddle per release. We were doing that by hand. So we wrote an MCP that handles the I/O: auth, idempotency, scheduling, retries, the Reddit anti-spam gate, and the manual-channel browser pre-fill.

What's in the box

Eight MCP tools — and that is the full surface:

Tool	Purpose
`publish`	Immediate publish; idempotent on `(content.id, variant.channel)`
`schedule`	Queue variants for a future `schedule_at`
`drain`	Fire any due scheduled posts
`status`	Per-variant state for a content piece
`unpublish`	Best-effort delete (DEV.to / GitHub Discussions only)
`hints`	Static per-channel metadata (char limits, tags, canonical-URL support)
`list_profiles`	Configured Distribution Profiles
`list_subreddits`	Curated Subreddit Catalog entries

Eight channels, three tiers

Channel	Tier	Notes
DEV.to	Auto	Forem API, native `canonical_url`
Hashnode	Auto	GraphQL, native `originalArticleURL`
GitHub Discussions	Auto	Per-repo GraphQL, footer for canonical
Bluesky	Auto	atproto SDK, canonical appended to post text
Reddit	Auto-gated	Per-subreddit cooldown, 5/day global cap, self-promo ratio
Medium	Manual	Playwright pre-fill + mark-live CLI
LinkedIn	Manual	Personal + company-admin compose, plain-text draft
Twitter / X	Manual	Free-tier API unusable; compose URL + plain-text draft

The three manual channels exist because their APIs are either gone (Twitter free tier), paid-tier (LinkedIn Marketing API), or never existed (Medium). The MCP opens a pre-filled compose tab and the operator clicks Submit. Less elegant, still beats the manual copy/paste workflow.

The Reddit gate

Reddit punishes anyone who treats it like a content pipe. The adapter enforces four rules before posting:

Per-subreddit cooldown — the last live post-log entry for that sub
5-per-day global cap — over the operator's full Reddit history with this MCP
Self-promo ratio — over the last 30 posts in that subreddit, your own-domain links must stay under the curated max_self_link_pct
Account age + karma — against minimums in the curated Subreddit Catalog

If any rule fails, publish returns state=failed with the specific reason. No bypass flag. If you want to post anyway, write a new entry in the Subreddit Catalog.

YAML or Notion: pick one

Two backends implement the same StateBackend Protocol:

YamlBackend — four YAML files under ~/.distribution-mcp/. Zero config; right for solo/local use.
NotionBackend — three Notion databases (Distribution Profiles, Subreddit Catalog, Post Log). Right for team/agency use; operators can audit the queue in Notion's UI.

You swap them with a single constructor argument. No caller code changes.

Works with any MCP host

The server speaks standard MCP (stdio or SSE) and has zero Anthropic-specific code:

grep -ri "anthropic" src/  # returns nothing

Tested with Claude Code, Cursor, n8n's MCP Client node, and the plain mcp Python client. If your host can talk MCP, it can talk to this.

Install

pip install content-distribution-mcp

# optional extras
pip install "content-distribution-mcp[browser]"
pip install "content-distribution-mcp[bluesky]"
playwright install chromium  # only if you use the browser channels

Then wire into your MCP host config:

// .claude/mcp.json
{
  "mcpServers": {
    "content-distribution": {
      "command": "content-distribution-mcp",
      "args": ["serve"]
    }
  }
}

How we use it ourselves

This very post is the dogfood. The Ghost blog post is the canonical: https://automatelab.tech/content-distribution-mcp/. The DEV.to article you're reading came out of the same publish tool with a devto:main variant. Bluesky was the second auto-channel. The browser-tier channels (LinkedIn / Twitter / Reddit) got their compose tabs pre-filled by the same MCP run.

What I learned introspecting 922 npm MCP servers

Artyom Rabzonov — Tue, 19 May 2026 14:20:28 +0000

TL;DR: We ran npx -y <package> against 922 npm-published MCP servers, sent them the JSON-RPC initialize and tools/list calls, and captured what they did. 359 responded. 563 failed in 15 distinct ways that say more about npm packaging than about MCP itself.

The stderr signature that broke 261 servers

[stderr] connecting to upstream...
[stderr] (no further output)
[timeout after 120s]

That is the single most common failure mode in the npm MCP ecosystem right now. The process spawns, the package loads, the constructor runs, and then the server tries to phone home to its upstream API before answering the protocol. The introspection runner waits 120 seconds and gives up. Two hundred sixty-one servers - 28% of everything published - never made it past their own startup.

If you maintain an MCP server and you connect to anything external during initialize, you are in this bucket. The fix is to defer the upstream connection until the first tool call.

What we actually ran

The protocol gives you a discovery method: tools/list. Send it after initialize and the server returns the full JSON Schema for every tool it exposes. No README scraping, no LLM interpretation, no guessing. It is the exact same thing your MCP client does when it connects.

The runner does this per package:

1. spawn:  npx -y <package> (over stdio)
2. write:  {"jsonrpc":"2.0","id":1,"method":"initialize",
            "params":{"protocolVersion":"2024-11-05",
                      "capabilities":{},
                      "clientInfo":{"name":"introspector","version":"1.0"}}}
3. read:   initialize response
4. write:  {"jsonrpc":"2.0","method":"notifications/initialized"}
5. write:  {"jsonrpc":"2.0","id":2,"method":"tools/list"}
6. read:   tool list
7. kill:   close stdin, SIGTERM

Concurrency was 8 in parallel, 120-second timeout per server, total wall time around 25 minutes for 922 packages. The output is one JSONL row per server with status, tool count, and (where available) the full input schema for every tool.

The 15 failure buckets

Every server that didn't return a clean tool array was classified by inspecting the exit code, stderr, and the JSON-RPC error if there was one. The breakdown:

Status	Count	Meaning
`ok`	359	clean `tools/list` response
`init_timeout`	261	spawned, never answered `initialize`
`npm_install_generic`	172	`npx -y` itself failed
`needs_cli_args`	54	exited with usage error
`needs_env_var`	42	generic missing env var
`broken_install`	11	malformed package, bad `main` or `bin`
`error`	8	unclassified crash with non-zero exit
`needs_setup_step`	3	required a CLI setup wizard run first
`needs_slack_token`	2	refused without `SLACK_BOT_TOKEN`
`needs_azure_creds`	2	refused without Azure auth
`tools_list_timeout`	2	answered `initialize`, hung on `tools/list`
`needs_google_creds`	2	refused without Google auth
`needs_stripe_key`	1	refused without `STRIPE_API_KEY`
`needs_config_file`	1	refused without a config path
`needs_external_runtime`	1	shelled out to a binary that was not installed
`needs_openai_key`	1	refused without `OPENAI_API_KEY`

The credential-wall buckets (everything needs_*) add up to 109 servers, almost 12% of the published set. If you are populating an agent's tool list by parsing READMEs, those servers register as 0-tool servers in your index. They are not 0-tool servers. They are 5-tool, 12-tool, 40-tool servers waiting for a key you didn't supply.

Windows-specific gotchas

The runner is on Windows. Two things bite hard.

Spawning npx. npx on Windows resolves to npx.cmd, a batch script. Node's child_process.spawn without a shell will not invoke a .cmd. The result is a flat ENOENT even though where npx shows it on PATH. The fix:

const child = spawn("cmd", ["/c", "npx", "-y", pkg], {
  stdio: ["pipe", "pipe", "pipe"],
});

You see this same pattern in every claude_desktop_config.json on Windows. If you are writing your own MCP client, you need it too.

UTF-8 stdio. The default code page on Windows is not UTF-8. If an MCP server writes a tool description that contains a non-ASCII character (German umlaut, em-dash, curly quote, anything), and you read its stdio without forcing UTF-8 decoding, you get a JSON parse error halfway through tools/list. Force it:

proc = subprocess.Popen(
    cmd,
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE,
    encoding="utf-8",
    errors="replace",
)

Three servers in our run had tool descriptions with non-ASCII characters. Without the encoding flag, all three would have been miscounted as error.

What this says to MCP server authors

A few patterns from the data, addressed to anyone shipping a server:

Don't connect upstream during initialize. If your server contacts an API on startup, it will fail introspection and it will fail any client that wants to enumerate tools without first burning a credential. Lazy-connect on the first tool call.
Don't require CLI args to print your tool list. 54 servers exit with a usage error before they will even tell you what they expose. If you need a config path, take it from an env var or accept tools/list without it.
Document the env vars in the README. The classifier successfully named the credential for the servers that wrote a clear "missing X" line to stderr. The ones that didn't ended up in the generic needs_env_var bucket. That bucket is your bug report queue.
Ship a real bin entry. 11 servers in broken_install had package.json that pointed at a file that doesn't exist, or a main field that crashed on require. None of them needed credentials. They needed a publish-time smoke test.

The full dataset

The 9,922 tool schemas and the 922 server status rows are on HuggingFace as automatelab/mcp-servers-tool-catalog under CC-BY-4.0. Pipeline source is at AutomateLab-tech/mcp-tool-catalog, and it re-runs on the 1st of every month via GitHub Actions.
Product page: https://automatelab.tech/products/datasets/mcp-tool-catalog/

from datasets import load_dataset

servers = load_dataset(
    "automatelab/mcp-servers-tool-catalog", "servers", split="train"
)

# Just the unreachable ones, grouped by failure mode
from collections import Counter
print(Counter(r["status"] for r in servers if r["status"] != "ok"))

If your server is in a failure bucket and shouldn't be, open a PR on the pipeline repo. The next monthly run picks it up.

Here is how I use Agency-OS to interact with my agents on the next level

Artyom Rabzonov — Tue, 19 May 2026 10:25:40 +0000

One thing I realized after working deeply with AI agents:

Execution is not the bottleneck anymore. Structure is.

You start with a simple task like:

“Create a product for AI SEO.”

Then your agent starts suggesting things like:

MCP integration
repo indexing
semantic search
auto-generated landing pages
etc.

Every feature creates another layer of:

research
planning
implementation
edge cases
dependencies

Very quickly you end up with a huge tree of subtasks that becomes impossible to hold in your head.

This is exactly where I started using Agency-OS differently.

Instead of treating agents like chatbots, I treat them like autonomous operators inside a structured operating system.

Example workflow

Main agent defines the product direction.

Separate agents branch into:

competitor research
distribution
architecture
onboarding UX
monetization
SEO
repo structure

Every branch becomes its own structured workspace with:

goals
outcomes
decisions
context
dependencies
next actions

Now I can actually see:

what agents are doing
why they suggest something
which tasks are blocked
where complexity explodes
which ideas are worth pursuing

The important part is not “more AI”.

It’s visibility and orchestration.
Without structure, agents generate chaos faster than humans.
With structure, they become leverage.

More details and examples cases: https://automatelab.tech/agency-os-launch/
Repo: https://github.com/AutomateLab-tech/agency-os

The image below shows how my real production Agency-OS board looks internally

I turned every n8n node into a machine-readable dataset (524 nodes, free) so agents can build workflows

Artyom Rabzonov — Mon, 18 May 2026 12:53:00 +0000

I have been writing agents that build n8n workflows. The hard part is not "call the n8n API and post a workflow JSON." The hard part is "pick the right node, with the right operation, with the right parameters, without hallucinating fields that do not exist."

The n8n GUI is the source of truth. The TypeScript source files are the second source of truth. Neither is a thing you can hand to an LLM at inference time.

So I extracted everything into one structured catalog and put it on HuggingFace.

524 nodes. Every operation. Every credential type. Properties schema. Free. CC-BY-4.0.

HuggingFace: automatelab/n8n-nodes-catalog
Browsable index: automatelab.tech/products/datasets/n8n-nodes-catalog/

Why a catalog and not "just scrape n8n.io"

Three real problems with leaving this implicit:

Hallucination cost is high. An LLM that invents a slack.sendDM operation will produce a workflow that imports fine and fails at runtime. Hard to detect, expensive to debug.
Context window pressure. Dropping the entire n8n source tree into a prompt is not realistic. You want a compact index the agent can search.
Coverage is non-obvious. There are two source packages (nodes-base and @n8n/nodes-langchain), and the split between them is not visible in the UI.

The catalog flattens all of that into one row per node.

What is in each row

Field	What it is
`node_name`	Internal id (e.g. `slack`, `airtable`, `lmChatOpenAi`)
`display_name`	UI label
`categories`	Top-level categories (Communication, AI, Data and Storage)
`subcategories`	Leaf taxonomy values
`group`	`input`, `output`, or `transform`
`version`	Default version for multi-version nodes
`description`	One-liner
`credentials_required`	Credential type names (e.g. `slackApi`, `openAiApi`)
`operations_supported`	Operation values for the node
`properties_schema`	JSON describing top-level property descriptors
`source_package`	`nodes-base` or `@n8n`
`source_file_path`	Repo-relative path to the `.node.ts`
`github_permalink`	Pinned GitHub link to the source

Format: JSON and Parquet (Snappy). License: CC-BY-4.0. Updates monthly.

A sample row

Here is the Slack node, trimmed:

{
  "node_name": "slack",
  "display_name": "Slack",
  "categories": ["Communication"],
  "group": ["transform"],
  "version": "2.3",
  "description": "Send and read messages, manage channels",
  "credentials_required": ["slackApi"],
  "operations_supported": ["message", "channel", "user", "reaction"],
  "properties_schema": "[{\"name\":\"resource\",\"type\":\"options\"},{\"name\":\"operation\",\"type\":\"options\"}]",
  "source_package": "nodes-base",
  "github_permalink": "https://github.com/n8n-io/n8n/blob/stable/packages/nodes-base/nodes/Slack/Slack.node.ts"
}

And an AI node, to show the cross-package coverage:

{
  "node_name": "lmChatOpenAi",
  "display_name": "OpenAI Chat Model",
  "categories": ["AI"],
  "subcategories": ["Language Models", "Chat Models (Recommended)"],
  "group": ["transform"],
  "version": "1.3",
  "credentials_required": ["openAiApi"],
  "source_package": "@n8n",
  "source_file_path": "packages/@n8n/nodes-langchain/nodes/llms/LMChatOpenAi/LmChatOpenAi.node.ts"
}

Numbers I did not expect

A few things that fell out of the catalog once it existed:

431 nodes from nodes-base, 93 from @n8n/nodes-langchain. The langchain side is a real and growing chunk.
The single most common credential type, by a wide margin, is httpBasicAuth (because the generic HTTP Request node is everywhere). After that the long tail starts immediately.
A non-trivial number of nodes have an empty operations_supported list. Those are usually root nodes (LLMs, vector stores, output parsers) where the "operation" abstraction does not apply.

Useful to know if you are writing a planner that filters by operation.

How agents actually use it

from datasets import load_dataset

ds = load_dataset("automatelab/n8n-nodes-catalog")["train"]

# Filter to nodes that can post messages somewhere
messaging = ds.filter(
    lambda r: "message" in (r["operations_supported"] or [])
)
for row in messaging:
    print(row["node_name"], row["credentials_required"])

Typical pipeline:

Embed every row (description, operations, credentials) into a vector store.
At plan time, retrieve the top N nodes for a user request.
Hand the agent only those rows. Compact context, no hallucinated operations.
The agent emits an n8n workflow JSON. Validation against properties_schema catches malformed configs before deploy.

This is the same shape as RAG over a tool catalog, which is becoming a pattern in its own right.

Caveats

The properties schema is a top-level summary, not the full recursive parameter tree. For deep parameter shapes the github_permalink is your friend.
Multi-version nodes only report the default version. If you need every version of a node, the source link covers it.
License is CC-BY-4.0 on the catalog additions; the n8n source itself is governed by n8n's own license, which you should respect when you ship.

Links

Dataset: automatelab/n8n-nodes-catalog
Browsable index: automatelab.tech/products/datasets/n8n-nodes-catalog/
All open datasets: automatelab.tech/products/datasets/

If you build agent tooling on top of this, the thing I would most like to see is an open eval set: prompts in, expected n8n workflow JSON out. That is the next obvious missing piece, and I do not think anyone has shipped one yet.

Building an MCP server for AI-SEO

Artyom Rabzonov — Sat, 16 May 2026 11:20:56 +0000

TL;DR

@automatelab/ai-seo-mcp is a 13-tool MCP server that runs AI-SEO analysis, citation scoring, and structured-data audits directly inside Claude or any MCP-compatible client.

What this is

AI search engines (Perplexity, ChatGPT, Google AI Overviews) pull answers from a small set of sources. Standard SEO tools tell you about backlinks and keyword density - they do not tell you whether a page is structured for AI citation. This MCP server fills that gap: it exposes audit, scoring, rewriting, and crawlability tools that work within your existing Claude context, no browser extension or SaaS dashboard required.

Why we built it

The tooling for AI-SEO was fragmented. You would need one tool to check robots.txt, another to generate llms.txt, another to score citation worthiness - and none of them integrated with the agent you are already using for content work. Claude has no native way to check whether a page will get cited. Wiring it up via MCP was the obvious fix.

Tool surface

Audit

audit_page - full on-page AI-SEO audit: headings, FAQ blocks, entity density, structured data
audit_schema - Schema.org validation and deprecation check
audit_canonical - canonical tag audit and redirect chain inspection

Technical

check_robots - robots.txt parse and AI-crawler directive check (GPTBot, ClaudeBot, PerplexityBot)
check_sitemap - sitemap structure, freshness, and coverage check
check_technical - Core Web Vitals summary and crawlability flags

Scoring

score_ai_overview_eligibility - predicts likelihood of inclusion in Google AI Overviews
score_citation_worthiness - composite score for LLM citation probability

Content

generate_llms_txt - generates a draft llms.txt for a site
validate_llms_txt - validates an existing llms.txt against the spec
extract_entities - pulls named entities and semantic clusters from page content
rewrite_for_aeo - rewrites a passage for Answer Engine Optimization
rewrite_for_geo - rewrites content for Generative Engine Optimization

Install

Add to your claude_desktop_config.json (or equivalent for Cursor / Cline):

{
  "mcpServers": {
    "ai-seo": {
      "command": "npx",
      "args": ["-y", "@automatelab/ai-seo-mcp"]
    }
  }
}

Or run it once to test:

npx -y @automatelab/ai-seo-mcp

Example

After adding the server and asking Claude to audit a page, it runs audit_page and returns something like:

AI-SEO audit: automatelab.tech/n8n-mcp-server/

Citation worthiness: 72/100

FAQ block present: yes (4 questions)

Structured data: HowTo schema detected, no deprecation issues

Entity density: moderate - consider adding more named tools/versions

H2 headings: 6 match common query phrasing

AI-crawler access: GPTBot allowed, PerplexityBot allowed, ClaudeBot allowed

Top recommendation: Add a direct-answer paragraph in the first 150 words. AI Overviews pull from the top of the page first.

That output comes back inside your Claude conversation - no tab-switching, no dashboard login. You can then ask Claude to rewrite_for_aeo the intro block and re-audit in the same session.

What is next

The next version will add per-tool caching so repeated audits on the same URL skip re-fetching, and a batch_audit tool for running a full site check against a sitemap. Feedback welcome - open an issue on the repo or reply here.

Repo: https://github.com/AutomateLab-tech/ai-seo
Landing: https://automatelab.tech/products/mcp/ai-seo/

Claude Code MCP Server Setup on Windows

Artyom Rabzonov — Thu, 14 May 2026 10:59:46 +0000

How to Set Up an MCP Server in Claude Code on Windows

Add HTTP, SSE, and stdio MCP servers to Claude Code on Windows. The cmd /c npx wrapper, the three scopes, and the errors you hit if you skip the wrapper.

TL;DR: Use claude mcp add for remote HTTP servers without modification. Wrap any stdio server running through npx with cmd /c. Without the wrapper, npx fails to spawn and the server appears in claude mcp list but never connects.

Prerequisites

Claude Code installed. Run claude --version.
Node.js 18 or newer on PATH if you plan to run stdio servers via npx.
A working terminal. Windows PowerShell, Windows Terminal, or Git Bash. WSL is not required.

Pick a Scope Before You Add a Server

Scope	Loads in	Shared with team	Stored in
local (default)	Current project only	No	~/.claude.json
project	Current project only	Yes, via Git	.mcp.json in project root
user	All your projects	No	~/.claude.json

Option 1: Add a Remote HTTP Server (No Windows-Specific Quirks)

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

For servers that authenticate with a token:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer YOUR_GITHUB_PAT"

Option 2: Add a Local Stdio Server (Where Windows Differs)

On Windows, npx resolves to npx.cmd, a batch script the Node child-process spawn inside Claude Code does not invoke directly. The fix is to wrap the call with cmd /c.

Method A: Through the CLI

claude mcp add --transport stdio filesystem -- cmd /c npx -y @modelcontextprotocol/server-filesystem C:/Users/you/projects

All flags come before the server name. The double-dash -- separates the name from the command.

Method B: Edit .mcp.json Directly

{
  "mcpServers": {
    "filesystem": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-filesystem", "C:/Users/you/projects"]
    }
  }
}

Use forward slashes in path arguments. Restart Claude Code after editing.

Verify the Server Is Connected

Run claude mcp list - the server should appear.
Inside Claude Code, type /mcp - servers show as connected, pending, or failed.
Use a tool to confirm the connection works end-to-end.

Common Errors

spawn npx ENOENT - add the cmd /c wrapper, or confirm Node is on PATH.
Server failed to start after OAuth - set MCP_TIMEOUT=10000 before launching Claude Code.
This project MCP servers must be approved - approve at the prompt, or run claude mcp reset-project-choices.
Server shows in list but never appears under /mcp - flag ordering is wrong; re-run with all options before the name.

FAQ

Why does npx fail on Windows? On Windows it resolves to npx.cmd, a batch script the Node child-process spawn does not invoke as an executable. Wrapping with cmd /c hands the script to the shell.

Where is the MCP config file stored on Windows? Local and user-scoped servers live in %USERPROFILE%\.claude.json. Project-scoped servers live in .mcp.json at the project root.

Do I need WSL? No. The native Windows install of Claude Code runs MCP servers directly.

Originally published at automatelab.tech