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., "@local-audit-mcp audit https://salon-example.com and recommend the best offer"
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 audits a local business's public web presence and returns a sales-ready score and offer. Point any MCP-capable agent (Claude Code, Cursor, opencode, ...) at a business's website and get a structured audit you can send as a pitch.
Tool | What it does |
| Fetch a public page, return readable text (scripts/styles stripped) |
| Pull signals from a business site: mobile readiness, phones, emails, WhatsApp, booking system, socials, chat widgets, price hints, FAQ schema |
| Score 0–10 across 10 audit checkpoints, list gaps ranked by revenue impact, recommend the offer to pitch |
| Pull FAQ Q&As for chatbot demos: structured FAQ schema first, then question headings, then question-like lines |
Related MCP server: SyteCheck MCP Server
npm install
npm start # runs the stdio server
npm test # 25 checks against a local fixture site (deterministic)"mcp": {
"local-audit": {
"type": "local",
"command": ["node", "/absolute/path/to/local-audit-server/index.js"],
"enabled": true
}
}For other agents (Claude Code, Cursor, etc.), point their MCP config at node /path/to/index.js (stdio transport).
extract_signals(url: "https://salon-example.com")
→ score_presence(signals: {...}, google_claimed: false)
→ score 4/10, gap #1: no online booking
→ recommended: AI assistant $300 setup + $50/mo
→ extract_faqs(url) → seed demo-widget.html → send demo to ownerRegex-based HTML parsing, not a DOM — fine for typical small-business sites, not SPAs (JS-rendered pages return little text). Next version: optional Playwright mode.
4 of the 10 checkpoints (Google profile, review replies, social activity, response time) can't be verified from a website alone — they come back as manual checks for a human to verify in ~2 minutes.
Only public pages. No logins, no scraping behind auth.
Never invent audit facts — if a tool says manual, a human confirms before anything goes to a prospect.
Automates ~80% of a local-business audit: score a prospect in seconds, then focus human effort on the pitch
Produces reproducible, evidence-based audits — no invented facts (manual checkpoints stay manual for a human to verify)
A template for custom MCP builds for businesses (agent integrations, internal tools)
Pull FAQ question/answer pairs from a business website: structured FAQ schema first, then question headings, then question-like text lines. Use to seed chatbot demos.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Max FAQs to return (default 10) | |
| url | Yes | Business page URL (https://...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the extraction order (structured FAQ schema, then headings, then text lines), which is useful behavioral context, but does not mention return format, rate limits, or failure modes.
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 two sentences with zero waste: it front-loads the core action and extraction strategy, then adds a use case. Every sentence 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?
The tool is simple with a fully described schema and annotations covering safety. The description states what it does and how it extracts, and implies it returns Q/A pairs. Minor gaps remain regarding return format and behavior when no FAQs are found, but these are small for a simple extraction 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 description coverage is 100%, so both parameters (url, max) are fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, making the baseline 3 appropriate.
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 states a specific verb ('Pull') and resource ('FAQ question/answer pairs') from a business website, and adds extraction strategy detail. However, it does not distinguish this tool from sibling tools like fetch_page or extract_signals, which prevents a 5.
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 one use case ('Use to seed chatbot demos'), which implies usage but does not state when to use this tool versus alternatives or when not to use it. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a business's website and extract signals: mobile readiness, contact info, booking system, socials, chat widgets, pricing hints, FAQs. Output feeds score_presence.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Business homepage URL (https://...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile and network reach are covered. The description adds the extraction scope but says nothing about failure modes (unreachable site, paywalled content), timeouts, or whether it renders JavaScript — relevant for an open-world web fetch.
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?
One tight sentence front-loads the verb and resource, then lists outputs, then names the consumer. No filler.
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?
With no output schema, the description must carry the return shape, and it does by enumerating signal categories. The remaining gap is behavioral edge cases for an open-world fetch, which are not covered.
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 100% with a single required 'url' parameter already documented as 'Business homepage URL (https://...)'. The description adds no constraints such as whether subpages are crawled or whether the URL must be the root.
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 ('Fetch a business's website and extract signals') and enumerates exactly which signal categories are produced (mobile readiness, contact info, booking system, socials, chat widgets, pricing hints, FAQs). It also names the downstream consumer score_presence, which separates it from a raw fetch_page.
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?
'Output feeds score_presence' implies part of a workflow, so the agent can infer this is the step before scoring. But there is no explicit when-to-use or when-not versus fetch_page or extract_faqs, which overlap in subject matter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public web page and return its readable text (scripts/styles stripped). Use for quick content checks before deeper analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public page URL (https://...) | |
| max_chars | No | Max characters of text to return (default 8000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety and external-network behavior are covered. The description adds useful behavioral detail that returned text has scripts and styles stripped, but says nothing about failure modes, paywalls, redirects, rate limits, or whether content is truncated silently.
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?
Two tight sentences with the core action and output form front-loaded, followed by a single usage cue. No wasted phrasing.
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 simple two-parameter tool with no output schema, the description covers what the tool does, what the output looks like, and where it fits in a workflow. It lacks any note on error/empty results or truncation behavior, which would matter for an open-world fetch.
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 100%, so both url and max_chars are already documented with format and default. The description adds no parameter-specific meaning (e.g., how truncation interacts with readability), so baseline 3 applies.
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 (fetch a public web page) and specifies the output form (readable text with scripts/styles stripped). The phrase 'before deeper analysis' implicitly distinguishes it from the analysis-oriented siblings (extract_signals, extract_faqs), though no sibling is named explicitly.
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?
Gives clear context: use for quick content checks before deeper analysis, which positions it as the retrieval step preceding sibling tools. It does not name the alternatives outright or state when-not conditions (e.g., authenticated pages, non-HTML content), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a business's web presence using audit checkpoints (0-10), list gaps ranked by revenue impact, and recommend the offer to pitch. Provide either signals (from extract_signals) or a url (will extract first). Manual overrides: google_claimed, replies_to_reviews, social_active_90d, fast_response_24h.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Business URL — used if signals not provided | |
| signals | No | Signals object from extract_signals | |
| google_claimed | No | Google Business Profile claimed + complete? | |
| fast_response_24h | No | Replies to enquiries within 24h? | |
| social_active_90d | No | Posted on social in last 90 days? | |
| replies_to_reviews | No | Owner replies to Google reviews? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real behavior beyond that by disclosing the implicit extraction step when only a url is passed, and that the four booleans act as manual overrides of extracted signals. It does not state how overrides interact with conflicting signal values, 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?
Dense but front-loaded: purpose and outputs come first, input routing second, override list last. Some compression makes it read as a run-on, but no sentence is filler.
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 scoring tool with no output schema, the description sufficiently characterizes the return (numeric score, ranked gaps, recommended offer) and the two input paths. The only soft spot is not saying what happens when override booleans conflict with extracted signals.
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 100%, so the schema already documents each field. The description adds the precedence rule between url and signals and frames the four nullable booleans as 'manual overrides', clarifying that setting them supersedes derived signals — meaning beyond a bare field listing.
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 ('Score a business's web presence') and names the artifact it produces: audit checkpoints 0-10, gaps ranked by revenue impact, and a recommended offer. That output detail distinguishes it clearly from the sibling extraction tools, which only gather raw data.
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?
Explicitly routes the agent on input mode: 'Provide either signals (from extract_signals) or a url (will extract first)', naming the upstream sibling and the fallback path. It lacks an explicit when-not-to-use statement, but the context of use is unambiguous.
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.0extract_faqsextract_signalsfetch_pagescore_presenceScored across 4 tools
Each tool has a fairly distinct role in the pipeline (raw fetch, signal extraction, scoring, FAQ extraction), and score_presence explicitly documents its input dependency on extract_signals. However, fetch_page and extract_signals both fetch page content, and FAQs are listed as a signal inside extract_signals while also being the sole purpose of extract_faqs, which creates moderate overlap.
All four tools follow a clean snake_case verb_noun pattern: fetch_page, extract_signals, score_presence, extract_faqs. No mixed conventions or vague standalone verbs.
Four tools is slightly thin but fits a narrow, focused audit pipeline where each tool maps to a pipeline stage. Supporting optional parameters on score_presence (signals vs url, manual overrides) keep the count low without losing capability.
The core sequence fetch → extract → score is covered, but the surface has no way to persist or export an audit result, batch or compare multiple businesses, or re-fetch signals for a saved business. These are notable gaps for an audit workflow that otherwise looks self-contained.
Public website health scan, AI-crawler and structured-data readiness, and a local presence score.
Scan a public website for AI agent readiness: 60 checks, a score, and the evidence for each.
Scan a website for AI search and agent readiness, then get a fix checklist for your agent.
Scan any website or MCP server for agent-trust-readiness; returns a signed, verifiable scorecard.
