Skip to main content
Glama

WebZum - The Hosting Layer for AI-Generated Web Content

create_site

Destructive

Create a new website for a business. Pass a business candidate object from search_businesses to generate a website.

Requires authentication via API key (Bearer token). Generate an API key at webzum.com/dashboard/account-settings.

The site generation happens in the background. Use get_site_status to check progress.

Returns the businessId which can be used to access the site at /build/{businessId}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
candidateYesA BusinessCandidate object from search_businesses results (use the _raw array)
extraInfoNoOptional additional metadata to include with the registration

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Adds valuable context beyond annotations: requires API key authentication, site generation is background, and returns businessId for access. Annotations already indicate destructiveHint, so no contradiction.

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?

Six short, purposeful sentences. Each sentence adds necessary information (purpose, input, auth, background, output). Slightly longer than minimal but still concise and well-structured.

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?

Covers prerequisite (search_businesses), auth, background async behavior, status checking, and return value. Missing error handling or limits, but sufficient for a creation tool with no output schema.

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 params have descriptions. The description reinforces that candidate comes from search_businesses but doesn't add new syntax beyond the schema. 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?

The description clearly states 'Create a new website for a business' with a specific verb and resource. It also specifies the input from search_businesses, making the purpose distinct from siblings like clone_site or create_lead_gen_site.

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?

It gives clear usage context: pass a business candidate from search_businesses and check progress via get_site_status. It doesn't explicitly name alternatives or exclusions, but the workflow is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Most tools have clear, distinct purposes: cloning, creating, hosting, editing, and regenerating different site parts. The main ambiguity is between create_lead_gen_site and generate_geo_page, which both create lead-gen pages but differ in targeting and workflow; however, their descriptions clarify the use cases sufficiently.

Naming Consistency4/5

Tool names follow a consistent lowercase verb_noun pattern (e.g., clone_site, host_file, update_site_html). Minor inconsistencies exist: create vs. generate for similar actions (create_site vs. generate_geo_page) and get vs. list for retrieval (get_hosted_files vs. list_user_sites), but these are predictable and readable.

Tool Count3/5

With 17 tools, the count is slightly heavy for a hosting service, but the variety of operations (creation, cloning, file hosting, editing, regeneration, status, search) justifies most of them. A few tools (e.g., four regenerate_* tools) could potentially be consolidated, but the scope still feels reasonable.

Completeness4/5

The toolset covers the full lifecycle: create, clone, host, list, edit, update, and regenerate site components. Notable gaps include no delete operation for sites or files and no explicit version rollback, but agents can work around these by using host_file to overwrite and relying on site status for progress.

Resources