WebZum - Websites for Small & Local Businesses

host_file

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.

Input Schema

TableJSON 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)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedMay 17, 2026

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"
+}

First observedMay 12, 2026

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.

All WebZum - Websites for Small & Local Businesses tools Inspect

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?