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 54 days
Last Tested: 2026-10-10 21:10
Transport: Streamable HTTP · MCP 2024-11-05
URL

TDQS

A4/5.0

Scored 2026-10-06 05:10 across 6 tools

Disambiguation4/5

build_website and host_site are the main potential confusion point, but the descriptions draw a clear line (complete researched business site vs. arbitrary HTML/CSS/JS content), and both explicitly cross-reference each other. host_file/host_zip are clearly distinguished by single-file vs. bundle upload, and the two get_* tools target distinct resources (file listing vs. build progress).

Naming Consistency5/5

Every tool follows a consistent snake_case verb_noun pattern: build_website, get_hosted_files, get_site_status, host_file, host_site, host_zip. The host_* prefix consistently signals write/hosting operations and get_* signals reads, making the set highly predictable.

Tool Count5/5

Six tools is well-scoped for what this server does: one builder, three content-upload paths (single file, zip, new site), and two read/status tools. Each tool earns its place with no redundant or filler operations.

Completeness4/5

The surface covers the core lifecycle — create a site, upload content, check build status, list files — and covers both the business-site and generic-hosting paths. Minor gaps exist: no delete/remove-file or version-rollback tool, and no direct editing tool (edits are handled via chat through build_website), but these are workable for the stated purpose.

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 2,900+ 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.

ParametersJSON Schema

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.5/5.0

Behavior4/5

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

Annotations are shallow (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds substantial behavioral context beyond them: the ~5-minute build, the email 'Build my website' confirmation that starts the build, ownership/account binding to the email, and 'each result's status and message say where the build stands.' That is genuinely useful for invocation, though much of the rest is output-artifact marketing rather than tool behavior.

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 purpose is front-loaded in sentence one, but the body is a long marketing brochure — multiple bulleted sections ('WHAT MAKES A WEBZUM SITE WORK', 'WHAT THE OWNER GETS') with feature sales copy (AEO, chatbots, Google Ads, llms.txt) that adds little to an agent's decision or invocation. This is over-specification that buries the operational content.

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, open-world build tool with no output schema, the description does supply what an agent needs to call it correctly: required email, the description field's expected content, and the resulting confirmation/status flow. It is complete on essentials, though the volume of promotional material dilutes signal.

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. The description loosely restates what the description field should contain (name, what it does, area, how customers reach it) and confirms the email drives account/site binding, but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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?

The opening sentence states a specific verb+resource and scope: 'Builds a complete, professional website for a small or local business.' It is immediately clear what the tool produces. It does not explicitly differentiate from siblings like host_site or host_zip, so it lands at 4 rather than 5.

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

Usage Guidelines3/5

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

The 'HOW A BUILD WORKS' paragraph implies usage by describing prerequisites (a description containing name, what it does, area, contact, plus the owner's email). But there is no explicit when-to-use vs the sibling hosting/status tools and no stated exclusions or alternative routes.

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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

Nose for Leads
com.noseforleads
Finds, filters, and verifies local-business leads; every email carries a verification receipt.
Marketing Email
2
radveo A
com.radveo
Checks if AI assistants name a local business. Free shareable report, honest fixes, no guarantees.
Marketing Search
22
XeoRank BOAuth
com.xeorank
SEO, AEO and GEO audits, rank tracking, AI-citation scans and WordPress editing for any site.
2401
lead-generation-mcpOAuth
com.themineworks
B2B and local lead gen: verified emails, site contacts, Maps and Yellow Pages leads.
Web Scraping Browser Automation
11

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)
28 PyPI
MIT
Nose for Leads MCP
CRM Marketing Web Scraping
NoseForLeads
A
license
Not graded
quality
C
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 a month ago (2026-09-11 05:20 UTC)
-
daxoom
Search E-commerce & Retail Location Services
CITROOT
F
license
Not graded
quality
F
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 4 months ago (2026-06-19 16:27 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?