Build on ThemeSniffer

What you can call

ThemeSniffer analyzes any public website from the outside and answers four questions: does it run WordPress, what is it built with, what fonts does it use, and what colors. The website, the API, the MCP server, and the WebMCP tools all run the same detection code, so all four give the same answer.

Quickstart

One request, no setup

Ask whether a site runs WordPress. This is the whole integration:

curl "https://themesniffer.com/api/check-wordpress?url=wordpress.org"

The response:

{
  "success": true,
  "isWordPress": true,
  "confidence": "high",
  "signals": {
    "metaGenerator": "WordPress 6.7.1",
    "wpContent": true,
    "wpIncludes": true,
    "wpBlocks": true,
    "restApi": true,
    "xPoweredBy": false,
    "linkHeader": true,
    "xPingback": false
  },
  "signalCount": 6,
  "totalSignals": 8,
  "poweredBy": "PHP/8.2.15",
  "theme": {
    "name": "Twenty Twenty-Four",
    "slug": "twentytwentyfour",
    "nameSource": "style.css",
    "inRepo": true,
    "wpOrgUrl": "https://wordpress.org/themes/twentytwentyfour/",
    "version": "1.3",
    "versionSource": "style.css",
    "latestVersion": "1.6",
    "outdated": true,
    "author": "the WordPress team",
    "activeInstalls": 500000
  },
  "url": "https://wordpress.org/",
  "checkedAt": "2026-09-08T10:15:00.000Z"
}

JavaScript

const res = await fetch(
  'https://themesniffer.com/api/tech-stack?url=' + encodeURIComponent('example.com')
);
const data = await res.json();

if (!data.success) throw new Error(data.error);

console.log(data.theme?.name, data.plugins.map(p => p.name));

CORS is open (Access-Control-Allow-Origin: *) on every endpoint, so this works from a browser as well as from a server.

Python

import requests

r = requests.get(
    "https://themesniffer.com/api/tech-stack",
    params={"url": "example.com"},
    headers={"User-Agent": "my-research-script/1.0 ([email protected])"},
    timeout=60,
)
data = r.json()

if not data.get("success"):
    raise RuntimeError(data["error"])

print(data["theme"], data["hosting"], data["performance"]["score"])

Bulk analysis

Analyzing a list of domains is a loop with a delay. Stay inside the published rate limits, send a descriptive User-Agent so a problem can be traced back to you, and cache results: sites do not change their theme between two requests a second apart.

for domain in $(cat domains.txt); do
  curl -sS --max-time 60 \
    -H "User-Agent: my-bulk-audit/1.0 ([email protected])" \
    "https://themesniffer.com/api/tech-stack?url=$domain" >> results.jsonl
  sleep 8
done

Authentication and rate limits

There is no API key

The analysis endpoints are public and unauthenticated. There is no key to request, no account to create, and no header to send. Access is governed by per-IP rate limits instead of credentials.

Two request properties do decide whether a call is accepted, and both trip up naive clients:

Rate limits

Limits are per IP address, per rolling minute. A limited request returns HTTP 429 with a JSON body; there is no Retry-After header, so wait a minute and retry.

Successful analyses are cacheable for 300 seconds (Cache-Control: public, max-age=300); errors and refusals are never cached. Repeating the same URL inside that window is close to free.

Fair use

Every call makes ThemeSniffer fetch a third-party website on your behalf, so heavy use costs someone else bandwidth as well as us. Cache aggressively, do not re-scan unchanged sites, and if you need volume beyond these limits, get in touch rather than routing around them.

Endpoint reference

Base URL: https://themesniffer.com/api. Every analysis endpoint is a GET that takes one query parameter, url, and responds with JSON.

Sandbox

Run a real request against the live API without leaving the page. Same endpoints, same rate limits, no key. Pick an endpoint, give it a site, and read the raw JSON it returns.

curl "https://themesniffer.com/api/tech-stack?url=wordpress.org"

Send a request to see the response.

Errors

Errors are JSON, never HTML, and always carry a message written for a person to read. The shape is stable:

{ "success": false, "error": "Cannot analyze private, local, or reserved addresses." }

Check success rather than the status code alone — a slow or hostile target can produce a body with success: false.

When the target blocks us

A site that refuses our request is a different thing from a site with nothing to report, and the API never conflates them. When the page cannot be read, the response is still 200 with success: true, but the verdict fields are null rather than false and the refusal is stated:

{
  "success": true,
  "isWordPress": null,
  "confidence": "unknown",
  "blocked": true,
  "blockedBy": "Cloudflare",
  "status": 403,
  "reason": "bot-protection",
  "note": "Cloudflare, which fronts this site, blocked our request (HTTP 403), so we could not check it for WordPress. That is a bot-protection rule, not an outage - the site itself is up and serves normal browsers.",
  "signalCount": 0,
  "url": "https://example.com/",
  "checkedAt": "2026-09-08T10:15:00.000Z"
}

So: branch on blocked (or isWordPress === null) before reading a verdict. A bot challenge served with a 200 is detected too, so an interstitial never gets analyzed as if it were the site.

Blocked addresses

Requests to private, loopback, link-local, CGNAT and cloud metadata addresses are refused, and so are the alternate encodings that usually smuggle them past a check: integer and hexadecimal IPs, octal-style octets, and IPv4-mapped IPv6. Redirects are re-validated on every hop, so a public URL cannot bounce a request onto an internal network.

MCP server

ThemeSniffer runs a remote Model Context Protocol server, so an AI assistant can analyze websites as a first-class tool instead of being told to browse. It speaks Streamable HTTP at a single endpoint:

https://themesniffer.com/api/mcp

Connect a client

For a client that supports remote MCP servers over HTTP, add:

{
  "mcpServers": {
    "themesniffer": {
      "type": "http",
      "url": "https://themesniffer.com/api/mcp"
    }
  }
}

For a client that only speaks stdio, bridge it:

{
  "mcpServers": {
    "themesniffer": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://themesniffer.com/api/mcp"]
    }
  }
}

No authentication is configured, so there is no token to paste. The server is stateless: it issues no Mcp-Session-Id, and it opens no SSE stream, so a GET to the endpoint returns 405 by design. Send JSON-RPC with POST.

Tools

Each tool answers twice: prose in content for the model to read, and the complete API response in structuredContent for anything that parses.

MCP Apps: interactive views

Every tool declares a UI template through the MCP Apps extension, so a host that supports it renders a real interface in the conversation — a swatch grid for the palette, a signal chip row for the WordPress verdict — instead of printing JSON. Tools carry the pointer in _meta:

{
  "name": "extract_color_palette",
  "inputSchema": { "type": "object", "properties": { "url": { "type": "string" } } },
  "_meta": {
    "ui": {
      "resourceUri": "ui://themesniffer/extract_color_palette",
      "visibility": ["app"]
    }
  }
}

Reading that resource returns the view as text/html;profile=mcp-app. The server advertises the capability during initialize:

{
  "capabilities": {
    "tools": { "listChanged": false },
    "resources": { "listChanged": false, "subscribe": false },
    "extensions": {
      "io.modelcontextprotocol/ui": {
        "mimeTypes": ["text/html;profile=mcp-app"]
      }
    }
  }
}

Inside the frame the view does the standard bridge handshake over postMessage — ui/initialize, then it waits for ui/notifications/tool-result and draws the payload. It reads the host theme, and its one action, opening the full report on this site, goes through ui/open-link rather than a raw anchor. A host that ignores the extension still gets the text summary, so nothing is lost.

Try it with curl

curl -sS https://themesniffer.com/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

curl -sS https://themesniffer.com/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"check_if_wordpress","arguments":{"url":"wordpress.org"}}}'

Supported methods: initialize, ping, tools/list, tools/call, resources/list, resources/templates/list, resources/read, prompts/list. Protocol versions 2025-06-18, 2025-03-26 and 2024-11-05 are negotiated during initialize.

Failures come back as a tool result with isError: true and a readable message, not as a JSON-RPC protocol error — an unreachable website is an answer the model can act on, not a broken call.

WebMCP: tools inside the page

A browser agent that lands on a ThemeSniffer page does not have to work out which input is the URL field and which div holds the result. Every page that can run an analysis registers the same four tools through WebMCP, so the agent calls a function and gets structured data back.

document.modelContext.registerTool({
  name: 'check_if_wordpress',
  description: 'Check whether a website is built with WordPress…',
  inputSchema: {
    type: 'object',
    properties: { url: { type: 'string' } },
    required: ['url'],
  },
  async execute({ url }) {
    // …calls /api/check-wordpress and returns
    // { content: [{ type: 'text', text }], structuredContent }
  },
});

Registration falls back through navigator.modelContext.registerTool() and then navigator.modelContext.provideContext() for agents on earlier drafts of the proposal. Where no surface exists the script is inert and the forms behave exactly as they always did. The implementation is one file, /webmcp.js, and the tool names and schemas match the MCP server exactly, so an agent that has used one already knows the other.

No WebMCP host? Call them anyway

Most agents driving a browser today have no modelContext to register into, so window.ThemeSnifferWebMCP.supported reads false and surface is null. That is the expected state, and it does not mean the tools are unavailable - it only means nothing native picked them up. Any agent that can run JavaScript in the page calls them directly, with the same arguments and the same result shape:

await window.ThemeSnifferWebMCP.callTool('check_if_wordpress', { url: 'example.com' });
// { content: [{ type: 'text', text }], structuredContent: { … } }

window.ThemeSnifferWebMCP.tools.map(t => t.name);
// ['check_if_wordpress', 'get_wordpress_tech_stack', 'detect_website_fonts', 'extract_color_palette']

A call that could not read the target site comes back with isError: true and a text summary that says who blocked it, rather than an empty report that reads like a finding.

The tool forms also carry declarative toolname and tooldescription attributes, which give an agent server-rendered evidence of what the page can do before any script has run. That part of the proposal is still a preview, so it supplements the registered tools rather than replacing them.

When an agent calls a tool on a page that has the matching form, the page renders the result too, so a human watching the screen sees the same answer the agent got.

Machine-readable discovery

Everything an agent needs to find and read this site without guessing:

What detection cannot see

Worth knowing before you build a product on top of these numbers, because no external scanner can do better:

• Plugins with no front-end footprint are invisible. Detection reads the CSS and JS a page loads. A backup plugin, an SMTP plugin or a security plugin that ships no asset leaves no trace to find.
• Bundled and minified assets hide their origin. A site that concatenates all plugin CSS into one file has erased the paths detection relies on, so it will look emptier than it is.
• Speed numbers are a lab snapshot. They are measured from our edge to the site once. They are useful for comparing sites in the same run, not as a substitute for field Core Web Vitals.
• Hosting and CDN come from header signatures. A null result means no signature matched, not that a site has no host. A CDN in front of the origin usually masks the origin host entirely.
• Bot filters win. A site behind an aggressive WAF refuses us the same way it would any automated client. The endpoint says so rather than guessing - blocked: true, the blocker named where its headers identify it, and no verdict - but it cannot see past the wall.
• The CSS budget is finite. The font and color endpoints fetch stylesheets up to a byte and time cap. Check stylesheets.fetched against stylesheets.found to see whether you got the whole picture.

Support and changes

The API is versionless. New fields get added to responses; existing fields are not renamed or removed without a note here. Treat unknown fields as additive and do not depend on key order.

Questions, a bug in a detection result, or a volume need beyond the published limits: the contact page or @ruslan_dev_ai. A report that names the URL you analyzed and what you expected is worth ten that do not.

Changelog