WebZum - Websites for Small & Local Businesses

Server Details

Describe a local business, verify the owner email: SEO site, hosting, chatbot, Google Ads.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.7% over 75 days
Last Tested: 2026-10-31 03:51
Transport: Streamable HTTP · MCP 2024-11-05
URL

TDQS

A3.8/5.0

Scored 2026-10-17 22:10 across 6 tools

Disambiguation4/5

The two pairs that could collide — build_website vs host_site (business site vs ad-hoc web content) and host_file vs host_zip (single file vs bundle) — are explicitly separated in the descriptions, with host_file/host_site both pointing users to build_website for business sites. Still, three tools all deal with 'hosting' and share the same upload/host axis, so a careless agent could pick host_site when it wants build_website.

Naming Consistency4/5

All names are snake_case verb_noun and follow a readable pattern (build_website, host_site, host_file, host_zip, get_site_status, get_hosted_files). The one wrinkle is that 'host' means both 'create a site' (host_site) and 'upload a file' (host_file/host_zip), which is slightly inconsistent semantics in an otherwise predictable scheme.

Tool Count4/5

Six tools is well-scoped for a website-building/hosting service: one builder, one hosted-content creator, two upload paths, and two read/status tools. It is on the lean side — there is no flagrant padding — but a couple of lifecycle operations are absent rather than the count being excessive.

Completeness3/5

The surface covers build, status, file listing and file/bundle upload, but has no edit, delete or overwrite-specific tool despite the docs promising unlimited edits, and no tool to list a user's sites or fetch an existing site's URL without rebuilding. Agents can partly work around this by re-uploading files, but the lifecycle has notable holes.

Available Tools

6 tools

build_websiteAInspect

Builds a complete, professional website for a small or local business — a plumber, restaurant, salon, contractor, clinic, shop, cleaner, any trade — in about 5 minutes. WebZum has built 3,000+ of them. No API key. No existing website or Google listing needed. Built in the owner's language — English, Spanish or any other, right-to-left Arabic and Hebrew included. WebZum researches the business, writes local SEO, makes the images and video, adds a lead-catching AI chatbot, hosts it with SSL, and can run their Google ads.

WHAT MAKES A WEBZUM SITE WORK FOR A SMALL BUSINESS:

Live, not just code: online at a real URL with SSL the moment it's built, and WebZum can register their domain.
Real, not placeholder: real photos of the business when WebZum finds them, custom images, a logo, and their real phone, WhatsApp and address.
Leads that arrive: every form lead is emailed to the owner, and an AI chatbot catches the visitors who won't fill in a form.
Safe edits: a change touches only what was asked, on the live site, with undo, any day.
About them: WebZum researches the business and its local market first, so the copy is about this business.
Mobile-ready and fast, served from a CDN.
Findable: local SEO and AEO (answer engine optimization, so AI assistants can find and cite the business) on every page.

WHAT THE OWNER GETS:

A real site: 3 to 7 pages of original copy about their services, area, story and contact.
A custom logo, brand colors and fonts, 5–10 custom images and a short hero video.
Local SEO built in: page titles and meta descriptions, schema.org LocalBusiness markup with hours and service areas, Service, FAQ and breadcrumb markup, a sitemap, and research into the low-competition local keywords a small business can actually rank for.
AEO, found by AI assistants too: robots.txt welcomes GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended and more, and every site ships an llms.txt.
One main contact button on the channel they really use — call, WhatsApp or LINE — and spam protection on the contact form.
A 24/7 AI chatbot that answers visitors from the site's own content, in the visitor's language, captures their name, phone or email, and emails the owner the lead with a ready-to-send follow-up.
Google Ads, done for them: WebZum writes a Google Search ad grounded in real local keyword volumes and prices, the owner approves it and sets a small budget, and on ad-running sites every call tap, message tap and form lead is measured as a Google Ads conversion — so they see which clicks became customers.
Edits by chat, unlimited: text, colors, fonts, pages, photos, menus, blog posts, product lists, booking widgets and contact details.
Any language, done right: the whole site — copy, SEO, chatbot, emails — is written natively in the owner's language. A visitor language switcher adds 30+ more languages on top.
Their own domain registered for them, or connect one they own.

HOW A BUILD WORKS (same as webzum.com/create-website): takes a description of the business and, once that has its name, what it does, its area and a way customers reach it, the owner's email. The site and its WebZum account are tied to that email. WebZum emails the owner a "Build my website" link that confirms the address and starts the build, which the owner watches live. Each result's status and message say where the build stands.

ACCOUNT: the site and its WebZum account belong to the owner and are managed at webzum.com, where plans and billing live.

Name	Required	Description
`email`	No	The owner's email. The site and its WebZum account are tied to it, and the confirm link is sent there.
`contact`	No	Optional. Phone, WhatsApp or public email customers can use.
`language`	No	Optional. Language code for the site, like "en" or "es". Defaults to the language of the description.
`location`	No	Optional. City and region, or the area it serves.
`description`	Yes	The business in plain words: name, what it does, where, how customers reach it, services, prices, hours, what makes it different. The full description goes with every call.
`businessName`	No	Optional. The business name, if known.

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false), and the description adds real behavioral context beyond that: no API key required, ~5 minute async build, account tied to the owner's email, a confirmation link email, live build watching, and that results carry status/message. It stops short of stating cost or failure/error behavior, so not 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dominated by marketing copy — 'WHAT MAKES A WEBZUM SITE WORK', 'WHAT THE OWNER GETS', feature bullet lists about AEO, llms.txt and Google Ads — that an agent does not need to select or invoke the tool. It is front-loaded and headed, but the signal-to-noise ratio is poor and the useful 'HOW A BUILD WORKS' content is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, side-effectful async build tool with no output schema, the description covers the prerequisite input flow, the confirmation step, and what the returned status/message convey. Only error handling and cost are left implicit, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters, and the description largely restates them (what the description field must contain, the default language rule). It adds only marginal meaning beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource — builds a complete professional website for a small or local business — with concrete scope (3–7 pages, SEO, chatbot, hosting, ads). It is immediately distinguishable from hosting primitives like host_site/host_zip, which the agent can tell apart without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the use case unambiguous (small/local trade businesses needing a full site) and adds a workflow section explaining the required inputs before a build starts. It never explicitly contrasts itself with the sibling host_* tools or states exclusions, 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.

get_hosted_filesB

Read-only

Inspect

Lists the files in a hosted site's current version.

Name	Required	Description	Default
`businessId`	Yes	The businessId to query

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the meaningful scoping detail that only the current version's files are returned, but reveals nothing about ordering, pagination, or result size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words; the resource and scope come first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only listing tool with annotations covering safety and no output schema, the description is nearly complete. It could briefly hint at the return shape, but nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With a single parameter and 100% schema description coverage, the schema fully documents businessId. The description adds no parameter-level detail, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb (Lists) and resource (files in a hosted site's current version). It is understandable on its own, but it does not differentiate itself from siblings like get_site_status or host_file, leaving an agent to infer the distinction from names alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus the many siblings (host_file, host_site, host_zip, get_site_status). The only usage signal is implied by the phrase 'current version', not by explicit guidance or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_site_statusA

Read-only

Inspect

Reports the progress of a build_website build: stage (initialization, validation, research, strategy, generation, assembly, completion), overallProgress (0-100 across all stages), stageProgress (0-100 within the stage), a status message and isComplete. Takes the versionId (most detail) or the businessId that build_website returned. The build's own watchUrl also shows it live. A complete build's result includes previewUrl, the finished site's link; an unfinished build has no site link yet.

Name	Required	Description	Default
`versionId`	No	The versionId returned from build_website (preferred for progress tracking)
`businessId`	No	The businessId returned from build_website (fallback, less detailed)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered structurally. The description adds real behavioral value beyond that: it explains the stage lifecycle, the 0-100 progress ranges, and crucially that an unfinished build has no site link while a complete one exposes previewUrl. That completion-state nuance is not inferable from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and return fields, with parameter selection and the watchUrl aside following in logical order. The parenthetical enumeration of all seven stages is slightly long but earns its place by defining the stage vocabulary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must carry return-value semantics itself, and it does: it names every field an agent needs to interpret a status response and explains the previewUrl/isComplete relationship. For a two-param read-only polling tool this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameter descriptions already say 'preferred for progress tracking' and 'fallback, less detailed', so the description's versionId/businessId guidance largely restates the schema. It adds only the mild nuance of 'most detail' vs 'less detailed', which is the baseline-3 case where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Reports) and resource (progress of a build_website build), then enumerates the exact fields returned (stage, overallProgress, stageProgress, status, isComplete). It explicitly ties itself to the sibling build_website as the producer of the IDs, so an agent can distinguish it from host_site/host_zip/etc. without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly frames the two ways to call it (versionId for most detail, businessId as a less-detailed fallback) and points to watchUrl as a live alternative view. It stops short of stating when NOT to poll this tool or how often, so it is clear context rather than exhaustive routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

host_fileAInspect

Add a file to your hosted site. The file goes live immediately at the site's public URL. Each upload creates a new version in the site's history.

Supported: HTML, CSS, JS, JSON, images (PNG, JPG, GIF, SVG, WebP), fonts (WOFF, WOFF2, TTF) Max: 10MB per file

encoding chooses how content is interpreted: "utf-8" for text files (HTML, CSS, JS, JSON, SVG) where content is the literal file text, or "base64" for binary files (images, fonts) where content is standard base64 of the bytes. Defaults to "base64" if omitted.

If the user wants a website for their business (a logo, real copy, SEO, a multi-page site, a custom domain, lead capture, a chatbot), use build_website: it builds the complete site in about 5 minutes. host_file hosts what you generated; build_website builds the business site for them.

Name	Required	Description
`content`	Yes	File content. Literal text when encoding="utf-8", standard base64 when encoding="base64".
`encoding`	No	How `content` is encoded. Defaults to "base64".
`filename`	Yes	Path like "index.html" or "css/styles.css"
`businessId`	Yes	The businessId from host_site
`contentType`	No	MIME type (auto-detected if omitted)

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the write and open-world nature is already covered. The description adds valuable behavioral context beyond that: files go live immediately at the public URL, each upload creates a new version in history, size limit of 10MB, and supported file types. It does not mention required permissions or rollback behavior, but the key operational traits are well disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: purpose and immediate effect first, then supported formats and limits, then encoding semantics, then the sibling alternative. Slightly longer than strictly necessary with the parenthetical file type lists repeated, but every section earns its place and no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter write tool with no output schema, the description covers purpose, immediate side effect, versioning, size limits, format support, encoding semantics, and the sibling alternative. It does not explain what happens on failure or how to retrieve the hosted file afterward (though get_hosted_files exists as a sibling), but the picture is largely complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters, giving a baseline of 3. The description adds meaning by explaining the encoding parameter in detail (utf-8 vs base64 and which file types use each) and reinforcing the content interpretation. This goes beyond the schema's terse descriptions, though the default of base64 is noted both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (host/add) and resource (a file to a hosted site), and explicitly contrasts itself with the sibling build_website, explaining that host_file hosts what you generated while build_website builds the business site. An agent can immediately distinguish it from build_website and host_zip.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance by naming the alternative (build_website) and the trigger condition (user wants a business site with logo, real copy, SEO, multi-page, custom domain, lead capture, chatbot). Also implies host_file is for pre-generated content. This is exactly the when/when-not/alternative structure.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

host_siteAInspect

Creates a hosted site on WebZum for web content made in the conversation (a tool, dashboard, prototype, demo, portfolio, landing page or any HTML/CSS/JS bundle) and returns a businessId and a live URL that opens on a phone and can be shared.

Why it matters: most people can't judge raw HTML by reading it. Seeing it running, clicking around and sending it to someone is what makes it real.

Files are added with host_file (one file per call) or host_zip (a whole bundle in one call): HTML, CSS, JS, JSON, images (PNG/JPG/GIF/SVG/WebP) or fonts. Each goes live immediately at .webzum.com with SSL, with no build step and no hosting account. It fits content someone wants live, shareable or running on their phone.

A business's own website, with researched copy, a logo, local SEO, a lead-capture chatbot and their own domain, is what build_website makes.

Name	Required	Description
`email`	No	Optional contact email.
`siteName`	Yes	Name for the site (e.g., "My Portfolio")
`siteType`	No	Type of site (default: custom)
`description`	No	Brief description of the site

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnly false, openWorld true, destructive false), and the description adds real behavioral context: files go live immediately at <businessId>.webzum.com with SSL, no build step, no hosting account. It stops short of stating whether sites can be updated or deleted later.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and the host_file/host_zip/build_website routing are front-loaded and useful, but the 'Why it matters' paragraph is persuasive marketing rather than operational guidance and does not help the agent invoke the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by naming the returned businessId and live URL. Combined with the immediate-publish behavior and file-addition path, an agent has nearly everything needed; only lifecycle/update behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters including the siteType enum. The description's prose list (tool, dashboard, prototype, demo, portfolio, landing page) hints at site types but adds no syntax or default detail beyond the schema. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Creates a hosted site on WebZum') plus the return value (businessId and live URL). It explicitly distinguishes itself from the sibling build_website, which is what an agent needs to route correctly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('content someone wants live, shareable or running on their phone') and when-not, naming build_website as the alternative for a real business site. It also explains the follow-up path via host_file and host_zip.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

host_zipAInspect

Upload a zipped bundle of files to a hosted site in a single call. Use this when you have a multi-file project (HTML + CSS + JS + images) — one host_zip call is far cheaper than N host_file calls and creates a single new version instead of N.

zipContent is the .zip file's bytes as standard base64. Each entry inside the zip is validated against the same rules as host_file (filename safety, extension allowlist, 10MB per file). All-or-nothing: if any entry fails validation, nothing is uploaded.

Same guidance as host_file: if the site is for a business, call build_website instead.

Name	Required	Description	Default
`businessId`	Yes	The businessId from host_site
`zipContent`	Yes	The zip file's bytes as standard base64.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false), and the description adds meaningful context beyond them: all-or-nothing atomicity, per-entry validation (filename safety, extension allowlist, 10MB limit), and that it creates a single new version rather than N. This is exactly the behavioral detail annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and cost rationale, then the validation and routing notes. It is efficient overall, though it repeats the base64 detail already stated in the schema description, which is minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-param mutation tool with no output schema, the description covers input format, validation rules, atomicity, and sibling routing. It stops short of describing the success response or version identifier, but the key calling requirements are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters (businessId, zipContent) are already documented in the schema, including that zipContent is standard base64. The description largely restates the base64 format and adds only the entry-level validation context, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Upload a zipped bundle of files to a hosted site') and immediately differentiates itself from host_file by scope (multi-file in one call). An agent can distinguish it from all siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it ('multi-file project ... far cheaper than N host_file calls') and names the alternative it replaces (host_file). It also routes business sites to build_website, giving a clear when-not condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 6, 2026

Changedbuild_website3 fields changed

changedInput schema / properties / description / description

Previous value: -"Everything you know about the business, in plain words: name, what it does, where, how customers reach it, services, prices, hours, what makes it different. Send the full description on every call."New value: +"The business in plain words: name, what it does, where, how customers reach it, services, prices, hours, what makes it different. The full description goes with every call."

changedInput schema / properties / email / description

Previous value: -"Step 2. The owner's email, once the result asks for it. Ask the owner; never make one up. The site and the account are theirs."New value: +"The owner's email. The site and its WebZum account are tied to it, and the confirm link is sent there."

changedInput schema / properties / language / description

Previous value: -"Optional. Language code for the site, like \"en\", \"es\" or \"ar\". Defaults to the language of the description."New value: +"Optional. Language code for the site, like \"en\" or \"es\". Defaults to the language of the description."

2 tool updatesOct 5, 2026

Changedbuild_website1 field changed

removedInput schema / properties / code

Removed value: -{
-  "description": "Step 3. The 6-digit code we emailed the owner. Send it with the same email.",
-  "type": "string"
-}

Removedclone_site

13 tool updatesOct 4, 2026
- Addedbuild_website
- Removedcreate_lead_gen_site
- Removedcreate_site
- Removedgenerate_geo_page
- Changedget_site_status2 fields changed
  - changedInput schema / properties / businessId / description
```
Previous value: -"The businessId returned from create_site (fallback, less detailed)"New value: +"The businessId returned from build_website (fallback, less detailed)"
```
  - changedInput schema / properties / versionId / description
```
Previous value: -"The versionId returned from create_site (preferred for progress tracking)"New value: +"The versionId returned from build_website (preferred for progress tracking)"
```
- Removedlist_user_sites
- Removedregenerate_footer
- Removedregenerate_header
- Removedregenerate_image
- Removedregenerate_logo
- Removedsearch_businesses
- Removedupdate_contact
- Removedupdate_site_html

1 tool updateAug 4, 2026

Changedgenerate_geo_page3 fields changed

addedInput schema / properties / line

Added value: +{
+  "description": "LINE Official Account friend-add / chat URL (lin.ee/…, line.me/…) or @id. Primary messaging CTA in Japan, Taiwan, and Thailand.",
+  "type": "string"
+}

changedInput schema / properties / primaryContact / description

Previous value: -"Owner's preferred primary contact channel for the main CTA. Omit to let the system infer from region."New value: +"Owner's preferred primary contact channel for the main CTA. Omit to let the system infer from region (LINE in Japan/Taiwan/Thailand, WhatsApp in WhatsApp-first markets)."

changedInput schema / properties / primaryContact / enum

Previous value: -[
-  "whatsapp",
-  "phone",
-  "email"
-]New value: +[
+  "whatsapp",
+  "line",
+  "phone",
+  "email"
+]

2 tool updatesJul 17, 2026

Changedgenerate_geo_page4 fields changed

changedInput schema / properties / email / description

Previous value: -"Business email for contact form (at least one of phone or email is required)"New value: +"Business email for contact form (at least one of phone, WhatsApp, or email is required)"

changedInput schema / properties / phone / description

Previous value: -"Business phone number (at least one of phone or email is required)"New value: +"Business phone number (at least one of phone, WhatsApp, or email is required)"

addedInput schema / properties / primaryContact

Added value: +{
+  "description": "Owner's preferred primary contact channel for the main CTA. Omit to let the system infer from region.",
+  "enum": [
+    "whatsapp",
+    "phone",
+    "email"
+  ],
+  "type": "string"
+}

addedInput schema / properties / whatsapp

Added value: +{
+  "description": "WhatsApp-reachable number (may equal phone). Counts as a contact method; rendered as a wa.me CTA. Keep the country code when given.",
+  "type": "string"
+}

Addedupdate_contact

3 tool updatesMay 17, 2026

Addedclone_site

Changedhost_file2 fields changed

changedInput schema / properties / content / description

Previous value: -"File content as base64-encoded string"New value: +"File content. Literal text when encoding=\"utf-8\", standard base64 when encoding=\"base64\"."

addedInput schema / properties / encoding

Added value: +{
+  "description": "How `content` is encoded. Defaults to \"base64\".",
+  "enum": [
+    "utf-8",
+    "base64"
+  ],
+  "type": "string"
+}

Addedhost_zip

1 tool updateMay 15, 2026

Changedhost_site1 field changed

changedInput schema / properties / email / description

Previous value: -"Contact email. Required when email verification is enabled on this server."New value: +"Optional contact email."

5 tool updatesMay 12, 2026
- Addedregenerate_footer
- Addedregenerate_header
- Addedregenerate_image
- Addedregenerate_logo
- Addedupdate_site_html
9 tool updatesMay 12, 2026
- First observedcreate_lead_gen_site
- First observedcreate_site
- First observedgenerate_geo_page
- First observedget_hosted_files
- First observedget_site_status
- First observedhost_file
- First observedhost_site
- First observedlist_user_sites
- First observedsearch_businesses

Related MCP Connectors

Involve Media
media.involve
Free local business checkup (Google, reviews, AI answers), plus web, SEO and automation services.
Marketing Search App Automation
1
https://involve.media/mcp
LotsBusinessOAuth
business.lots
Get your business online and found: website, Google Business Profile, business email and listings
Marketing Content Management Systems Email
1
https://api.lots.business/mcp
Nose for Leads
com.noseforleads
Finds, filters, and verifies local-business leads; every email carries a verification receipt.
Marketing Email
2
https://api.noseforleads.com/mcp
radveo A
com.radveo
Checks if AI assistants name a local business. Free shareable report, honest fixes, no guarantees.
Marketing Search
22
https://radveo.com/api/mcp

Related MCP Servers

local-leads-mcp
Raffaele86
A
license
Not graded
quality
C
maintenance
Discovers local businesses needing a website via OpenStreetMap and verifies their leads with checks like website existence, email deliverability, and site quality scoring.
Updated 3 months ago (2026-07-18 07:28 UTC)
24 PyPI
MIT
Nose for Leads MCP
CRM Marketing Web Scraping
NoseForLeads
A
license
Not graded
quality
D
maintenance
Finds, filters, and verifies local-business leads on demand; every returned email carries a verification receipt (verifier, verdict, timestamp). Credit-based with per-key spend budgets; 25 free validated leads at signup.
Updated 3 months ago (2026-07-22 21:03 UTC)
MIT
cited
Marketing Search
entradox
F
license
Not graded
quality
B
maintenance
Enables instant scanning of any business to check if AI engines recommend it, providing verbatim evidence.
Updated 2 months ago (2026-09-11 05:20 UTC)
-
daxoom
Search E-commerce & Retail Location Services
CITROOT
F
license
Not graded
quality
D
maintenance
The owner-verified local business data + service & menu-price layer for AI agents. Owner-authored business profiles where every response carries provenance — verification level, completeness score, freshness timestamps, and upstream sources. * Search & profiles — find businesses by name, category, city, or geo-radius; full profiles with contacts, hours, media, ratings. * Price layer
Updated 22 days ago (2026-10-09 01:26 UTC)
-

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?