Detects whether a website's forms run on Drupal, helping assess form automation and outreach feasibility.
Identifies HubSpot as a website's form platform, providing insight into how forms handle automated submissions.
Parses Bing's public RSS search output to find business websites and search presence for lead-leak audits.
Detects Squarespace as a website's form platform, indicating whether forms can be automated for outreach.
Identifies Typeform as a website's form platform, helping determine outreach channel viability.
Detects Wix as a website's form platform, noting that Wix forms fire no network traffic on automated submits, so prospects require email or social outreach instead.
Detects WordPress sites and their form plugins (e.g., WPForms, Contact Form 7, Gravity Forms) to assess form automation capabilities.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@web-presence-audit Run a full presence audit on Driver Plumbing & Heating in Leicester"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that turns a proven, £0 lead-leak audit methodology for UK local service businesses into six tools your AI agent can call. No API keys, no accounts, no paid services — every data source is free to read.
This is the audit methodology behind real paid audits (built for B2B prospect research): it finds the fixable issues that measurably cost local businesses leads — untappable phone numbers, un-findable websites, mismatched phone numbers across directories, and forms on platforms where automated outreach simply cannot work.
Audience: agencies and web-audit sellers, local-SEO freelancers, lead-gen sellers, any agent doing prospect or client website research.
Cost: £0. Bing's public RSS search output + free UK directories (thomsonlocal, TrustATrader, 3BestRated) + the target site itself. No API keys, no signups, no cards.
Config-free: no environment variables, no accounts. Install and add to your MCP client — done.
Tool | What it answers |
| Which platform a site's forms run on (WPForms, Contact Form 7, Wix, Squarespace, Jotform, Gravity Forms, HubSpot, Typeform, Drupal, or |
| Is the phone number a clickable |
| Is the phone number identical on the business's own site and the free directories (thomsonlocal, TrustATrader)? Mismatched numbers confuse Google and customers. Verdict: |
| Quick hygiene checks: reachable?, HTTPS?, mobile viewport tag?, page weight, load time, title + meta description. |
| Find a business's own website via Bing's public RSS search — only a result with a distinguishing word counts (trade words like "plumbing" prove nothing). |
| Everything at once: search presence, website hygiene, form platform, tap-to-call, NAP, plus the 3BestRated top-3 competitors. Returns a prioritized leak list. |
Matching honesty (kept from the live-proven methodology): a directory listing or search result only counts as the business when it contains a distinguishing word (e.g. "driver" in "Driver Plumbing") plus 2+ name words — trade words and city names alone never count. Masked directory numbers (+447****5682) are excluded from NAP comparison.
Related MCP server: geo-audit-mcp
Requirements: Python 3.10+ and either uv or pip. Nothing else — no Node, no database, no API keys.
1. Install.
# with uv (fastest):
uv venv && uv pip install -e .
# or with plain pip:
python3 -m venv .venv && .venv/bin/pip install -e .2. Test the install (30 seconds).
.venv/bin/python -m pytest tests/ -qYou'll see 63 passed — all tests are fully offline (canned pages + a localhost site; no live internet needed).
3. Wire it into your MCP client.
Example for Claude Desktop / Cursor / any MCP client with JSON config:
{
"mcpServers": {
"web-presence-audit": {
"command": "/ABSOLUTE/PATH/TO/web-presence-audit/.venv/bin/python",
"args": ["-m", "web_presence_audit"]
}
}
}No env block needed — the server requires nothing but a working network at call time.
4. Try it. Ask your agent:
What form platform does example.co.uk run, and can I tap its phone number to call?
or
Run a full presence audit on "Driver Plumbing & Heating" in Leicester.
These are real outputs from this server's test suite (canned fixture pages; see tests/fake_pages.py — the shapes are exactly what the live tools return against real sites).
check_form_platform("https://example.co.uk") →
{
"url": "https://example.co.uk",
"platform": "wpforms",
"outreach_note": "WordPress site with the WPForms plugin. Contact forms accept standard fill-and-submit automation cleanly; leave the honeypot field empty.",
"evidence": "wpforms-container",
"visible_form_fields": 3,
"http_status": 200
}check_tap_to_call("https://example.co.uk") → (a plain-text number)
{
"verdict": "leak",
"tel_links": [],
"plain_phones": ["0116 264 5115"],
"note": "LEAK — phone number 0116 264 5115 appears as plain text with no tel: link. Mobile visitors cannot tap to call; most will not retype it.",
"url": "https://example.co.uk"
}check_nap_consistency("Driver Plumbing & Heating", "Leicester") → (site and directory agree)
{
"business": "Driver Plumbing & Heating",
"city": "Leicester",
"trade": "plumber",
"website": "https://www.driverplumbing.co.uk/",
"website_phone": "0116 264 5115",
"directory_phones": [
{ "source": "thomsonlocal", "phone": "0116 264 5115" }
],
"verdict": "consistent",
"note": "Phone number identical across all sources found."
}run_full_audit(...) returns all of the above plus search_presence, website hygiene, top3_competitors, a leaks list, and a score_note summarizing what to fix first.
63 tests in three layers — all offline (no live internet required to pass):
Engine tests (tests/test_audit.py) — platform detection per signature, honeypot exclusion from field counts, tap-to-call verdicts, phone normalisation (+44 → 0), the matching-honesty rules, Bing RSS parsing, NAP consistency logic, hygiene checks, and the full pipeline end-to-end against canned pages.
Tool layer tests (tests/test_server_tools.py) — each tool's output shape, URL scheme upgrading, error results (never crashes), all six tools registered with docstrings.
Protocol tests (tests/test_protocol.py) — launch the real server as a subprocess, speak MCP JSON-RPC over stdio (initialize → tools/list → tools/call), and verify responses against a localhost fake site. The production fetch path runs for real; only the target is pretend.
Run them yourself:
.venv/bin/python -m pytest tests/ -vA note on live sources: Bing RSS, thomsonlocal, TrustATrader and 3BestRated were all reachable and parseable from our build environment. Checkatrade is deliberately not queried — it returns HTTP 403 to datacenter IPs, so the methodology reports honestly rather than scraping it. (Checkatrade support confirmed no public API for non-customers.) Live directory pages can change markup; the parser tests protect the logic, and any site that blocks or changes is reported as an honest error, never fabricated data.
The official Python SDK renamed its main class between versions: 1.x exposes mcp.server.fastmcp.FastMCP, 2.x renamed it to mcp.server.mcpserver.MCPServer. This server imports whichever is installed, so pip install mcp gives you either and it still runs. (Protocol-tested against 1.14.0 and 2.2.0.)
Agencies and web-audit sellers — run structured findings-first audits on any UK local business in minutes, with zero tooling cost.
Local-SEO freelancers — NAP consistency and presence checks without paid tools.
Lead-gen sellers — the form-platform check tells you which outreach channel can even work before you spend time on a prospect.
Any MCP client user doing UK B2B prospect research (pairs with our uk-company-check server for registry facts).
MIT (see LICENSE).
Run the quick website hygiene checks: reachable?, HTTPS?, mobile viewport tag?, page weight, load time, title and meta description. Each missing item is a concrete fixable finding for an audit report.
Args: url: The website to check, e.g. "https://example.co.uk".
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden. It discloses the check list and that missing items become fixable findings (a useful output trait), but says nothing about network failure behavior, timeouts, redirects, or whether the URL must be publicly reachable — meaningful gaps for a fetch-and-inspect tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the check list in the first sentence and keeps the Args block to a single line with a useful example. The 'Args:' formatting is slightly redundant against the schema but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers what is inspected. However, for a no-annotation network tool it omits failure modes and positional context relative to siblings like run_full_audit and find_website, leaving the agent to guess which tool to pick.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter at 0% schema description coverage, so the description must compensate. It does name the parameter's meaning and give a concrete format example ('https://example.co.uk'), but adds nothing about scheme requirements, trailing paths, or redirect handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource (audit_website) and enumerates the exact checks performed (reachable, HTTPS, mobile viewport, page weight, load time, title/meta description), so the scope is concretely defined. It does not explicitly differentiate itself from run_full_audit or find_website, though 'quick' hints at a lighter scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Run the quick website hygiene checks' implies this is the lightweight variant, but no explicit when-to-use/when-not or alternative is named despite obvious siblings (run_full_audit, find_website). Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect which form/website platform a site runs (WPForms, Contact Form 7, Wix, Squarespace, Jotform, Gravity Forms, HubSpot, Typeform, Drupal, or 'unknown'). The platform PREDICTS whether automated form outreach can work: WordPress/WPForms and CF7 accept standard fill-and-submit; Wix forms fire no network traffic on automated submits (verified in live campaigns) — use email or social there instead. Returns the platform, a plain-English outreach note, and the count of visible form fields (hidden honeypot fields excluded).
Args: url: The page to check, e.g. "https://example.co.uk" or "https://example.co.uk/contact".
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the return contents (platform, plain-English outreach note, visible field count), the honeypot-exclusion behavior, and the empirical caveat that Wix forms produce no traffic on automated submits. It omits anything about auth, rate limits, or behavior when a site is unreachable beyond listing 'unknown'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, and the Wix/outreach material is genuinely decision-relevant rather than filler. The platform enumeration and the multi-clause Wix explanation make it slightly longer than needed, and the trailing quoted Args block is a formatting artifact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, yet the description redundantly but harmlessly restates them. For a single-input detection tool with no annotations, the remaining gap is error/edge behavior (unreachable or non-form sites) beyond the 'unknown' fallback.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: it defines url as the page to check and gives two concrete formats (bare domain and domain with /contact path). It doesn't specify scheme requirements, redirect handling, or whether non-HTML resources are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource ('Detect which form/website platform a site runs') and enumerates the detectable platforms, leaving no ambiguity about what the tool does. It does not, however, explicitly position itself against siblings like audit_website or run_full_audit, so sibling differentiation remains implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear decision context: the detected platform predicts whether automated form outreach will work, with a concrete rule ('Wix forms fire no network traffic — use email or social there instead'). It stops short of naming an alternative sibling tool or stating when a call is unnecessary, so it falls just short of explicit when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the phone number (NAP: Name/Address/Phone consistency) between the business's own website and the free UK directories (thomsonlocal, TrustATrader), via Bing's public RSS search. A mismatched number confuses both Google and dialling customers. Returns the phone found on each source and a verdict: 'consistent', 'inconsistent', or 'insufficient data'.
Args: business: Business name, e.g. "Driver Plumbing & Heating". city: UK city, e.g. "Leicester". trade: Trade keyword (plumber, electrician...) — guessed from the business name if omitted. website_url: The business's website if you know it — skips the search step and makes the NAP comparison stronger.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| trade | No | ||
| business | Yes | ||
| website_url | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does well: it discloses the mechanism (Bing public RSS search), the sources queried, and the possible verdict values ('consistent', 'inconsistent', 'insufficient data'). It omits failure modes, rate limits, and staleness of the public RSS data, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence and the Args block is terse and example-driven. The aside about mismatched numbers confusing Google and dialling customers is motivational filler that does not change how the tool is called.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup with an output schema and no annotations, the definition covers inputs, sources, and verdict semantics well enough to invoke correctly. It leaves minor gaps around public-RSS availability and what happens when no directory match is found (beyond the 'insufficient data' verdict), which the output schema may cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: every parameter is explained with an example, plus behavioral semantics the schema lacks (trade is inferred from the business name when omitted; website_url skips the search and strengthens the comparison). The defaults in the schema are also clarified in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check the phone number... NAP consistency') and names the two sides being compared (the business's own website vs thomsonlocal/TrustATrader). The mention that supplying website_url 'skips the search step' implicitly distinguishes it from the find_website sibling, so an agent can tell what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful per-argument context (website_url skips the search, trade is guessed if omitted) but never states when to pick this tool over siblings like check_tap_to_call, check_form_platform, or run_full_audit. Usage is implied by the name rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the phone number on a page is a clickable tel: link (tap-to-call). On mobile, a plain-text number cannot be tapped — visitors must retype it, and most won't. Returns every tel: link found, any plain-text UK numbers, and a verdict ('ok', 'leak', or 'no_phone_found').
Args: url: The page to check, e.g. "https://example.co.uk".
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: 'check' makes the read-only nature apparent, the verdict vocabulary is disclosed, and the scope limit ('plain-text UK numbers') is stated. It omits live-fetch behavior, timeouts, and how non-UK numbers are treated, so it falls short of complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and return vocabulary are front-loaded and the description is compact. The one persuasive sentence about mobile visitors retyping numbers is rationale rather than instruction, and the Args block duplicates the schema, but given 0% schema coverage that repetition is compensation rather than waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out (though they are), and one parameter plus a read-only check is a simple surface. The remaining gap is the absence of any link to the broader audit siblings or notes on fetch/failure handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'url' parameter, so the description must compensate; it does so by clarifying the expected value and giving a concrete example ('https://example.co.uk'). It stops short of stating constraints such as absolute-URL requirement or reachability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a precise verb+resource ('check whether the phone number on a page is a clickable tel: link') plus the exact failure mode it detects, which no sibling (check_form_platform, check_nap_consistency, audit_website) could be confused with. It also enumerates the verdict vocabulary ('ok', 'leak', 'no_phone_found'), pinning the tool's scope tightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The mobile rationale implies when the check matters, but there is no explicit when-to-use statement and no routing against the audit siblings (audit_website, run_full_audit) that likely subsume this check. Usage must be inferred rather than read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a business's own website via Bing's public RSS search. Only a result that genuinely matches the business name (with a distinguishing word — not just trade words) and is not a directory or social site is returned. Returns the URL, or an honest 'not found' with the search URL so a human can double-check.
Args: business: Business name, e.g. "Driver Plumbing & Heating". city: UK city, e.g. "Leicester".
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| business | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It usefully discloses the search source (Bing public RSS), the matching/filtering criteria (genuine name match with distinguishing word, no directories/social sites), and the failure mode (honest 'not found' with a search URL). It does not cover rate limits, auth, or pagination, but for this discovery tool the key behaviors are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then adds selection criteria and return behavior, followed by an Args list with examples. Every section earns its place and there is no filler, though the Args list is a necessary duplication given the empty schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, but the description still summarises them. With no annotations, it covers behavior, parameters, and sibling differentiation reasonably well. It lacks edge-case handling (e.g., multiple candidates, rate limits), but is largely complete for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It documents both parameters with examples: 'business' as a name like 'Driver Plumbing & Heating' and 'city' as a UK city like 'Leicester'. This adds valuable format and locale context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Find') and resource ('a business's own website'), and names the method (Bing public RSS search). It distinguishes itself from audit-oriented siblings by focusing on discovery of a URL rather than auditing a known site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a business's website needs to be discovered, but it does not explicitly say when to choose it over siblings like audit_website or run_full_audit, nor does it list exclusions or prerequisites. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the COMPLETE lead-leak audit on a UK local service business: search presence, website hygiene, form platform, tap-to-call, NAP consistency across free directories, and the 3BestRated top-3 competitors. Returns every finding plus a prioritized leak list. This is the full methodology used in real paid audits. Runs 6-10 free web requests; expect about 10-30 seconds.
Args: business: Business name, e.g. "Driver Plumbing & Heating". city: UK city, e.g. "Leicester". trade: Trade keyword — guessed from the name if omitted. website_url: Known website URL — skips discovery if provided.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| trade | No | ||
| business | Yes | ||
| website_url | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningful traits: 6-10 free web requests, ~10-30 second runtime, and that it returns every finding plus a prioritized leak list. It does not mention failure/partial-result behavior or rate limits, but the cost, latency, and external-request profile are exactly the context an agent needs before invoking an expensive orchestrator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose, scope, and cost are front-loaded in the first paragraph, and the Args block adds semantics rather than restating the schema. It is a touch long and the Args formatting is slightly verbose, but nearly every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, yet the description still summarizes the return ('every finding plus a prioritized leak list'). Scope, cost, and all four parameters are covered; only error/partial-failure handling and explicit sibling routing are absent, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it documents all four parameters with real semantics: business and city include concrete examples, trade explains it is guessed from the name when omitted, and website_url explains that providing it skips discovery. This adds genuine meaning beyond the bare string types and empty-string defaults in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb ('Run') and resource (the complete lead-leak audit) and enumerates the exact dimensions covered: search presence, website hygiene, form platform, tap-to-call, NAP consistency, and top-3 competitors. The word 'COMPLETE' plus 'full methodology used in real paid audits' cleanly separates it from the granular siblings like check_form_platform and audit_website.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the agent infers this is the comprehensive option versus the piecemeal sibling checks, and website_url is noted as skipping discovery. However there is no explicit when-not-to-use guidance (e.g. 'use check_nap_consistency for a single check') and no note on whether it is safe to run repeatedly. Context is present but routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0audit_websitecheck_form_platformcheck_nap_consistencycheck_tap_to_callfind_websiterun_full_auditScored across 6 tools
Each tool targets a distinct check: form platform, tap-to-call, NAP consistency, website hygiene, and website discovery are all clearly separated by purpose. The only overlap is run_full_audit, which intentionally composes the others; its description clearly frames it as the complete composite, so an agent can still choose correctly.
All names are snake_case following a verb_noun pattern (check_form_platform, audit_website, find_website, run_full_audit). The verbs vary (check/audit/find/run) but the structural convention is consistent and readable.
Six tools is well-scoped for a focused web-presence audit: five atomic checks plus one composite orchestrator. Each tool earns its place with no redundancy or padding.
The surface covers website discovery, hygiene, form platform, tap-to-call, and NAP consistency, plus a full audit — solid lifecycle coverage for the domain. Minor gap: competitor/review checks are only reachable through run_full_audit rather than a standalone tool, but agents can still access them.
Free technical-SEO audit MCP: crawl a site, run checks, return an LLM-ready shareable report.
SEO for plumbers: the site's own MCP server — enquiry (enquiry = a human handoff, not a...
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
Audit, rank-track and analyze SEO for sites via an authenticated MCP server.
