Skip to main content
Glama
Sign In
Hostsmith MCP Server

Hostsmith MCP Server

by hostsmith
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

deploy_files

Destructive

Publish generated in-memory file contents directly to an existing Hostsmith site and get the deployment version and status, with no disk writes required.

Instructions

Publish in-memory file contents to a Hostsmith site without writing to disk. Use when you have just generated content (an HTML page, a report, JSON data) and the user wants it live. Returns the deployment version and status; call get_site afterwards if you need the public URL to share. The site must already exist - call create_site first if you do not have a siteId. Deploying to a site that already has content overwrites it - confirm overwrite with the user first. A redirect host (kind: "redirect") takes no files and answers RedirectHostHasNoFiles: change its rules with the redirect tools instead.

Anti-pattern: do not use this tool to ship binaries (images, PDFs, video, fonts, zips) by base64-embedding or data-URI inlining them into HTML/CSS/JSON. Binaries belong on deploy_create_upload. If that path is blocked by sandbox/network, escalate to the user (ask them to enable egress, or offer manual upload of the presigned URL) - never reach for this tool as a workaround. Inlining bloats pages, breaks browser caching, and reships the bytes on every deploy.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "siteId": "<siteId>",
      "files": "<files>"
    },
    "name": "deploy_files"
  }
}

Input Schema

NameRequiredDescriptionDefault
filesYesFiles to deploy. For an HTML site, include an `index.html` as the entry point; otherwise any single file (PDF, image, JSON, etc.) works on its own.
siteIdYesThe site ID to deploy to (from `list_sites` or `create_site`).
partitionNoData partition the site lives in. Omit to use the user's home partition.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.2

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true; the description supplies the actual consequence ('Deploying to a site that already has content overwrites it - confirm overwrite with the user first') and the return values (deployment version and status, with get_site for the public URL). It also surfaces a specific failure mode, RedirectHostHasNoFiles, which an agent cannot learn 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?

The core behavior, prerequisite, and overwrite warning are front-loaded in the first few sentences, and the error case follows logically. The bolded anti-pattern block is long relative to the rest, but it carries genuinely non-obvious routing guidance rather than filler.

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?

With no output schema, the description compensates by stating what is returned (version and status) and how to obtain the public URL. For a destructive write tool it covers prerequisites, overwrite behavior, an error code, and the binary-workaround trap, leaving little an agent would need to infer.

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 parameters are already documented in structured form; the description only lightly reinforces semantics, e.g. that a redirect host takes no files and that siteId comes from list_sites or create_site. It adds no detail on the partition parameter or file-content sizing, so the baseline of 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 first sentence names a specific verb and resource ('Publish in-memory file contents to a Hostsmith site') and adds the defining constraint 'without writing to disk', which separates it from deploy_create_upload. The anti-pattern paragraph further hardens the boundary between this tool and the binary-upload sibling.

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?

It states when to use it (freshly generated HTML/report/JSON the user wants live), what prerequisites apply (site must exist, call create_site first if no siteId), and when not to use it (binaries, redirect hosts). It also names alternatives explicitly: deploy_create_upload for binaries and the redirect tools for redirect hosts.

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

Deploy Server

Other Tools