Skip to main content
Glama
Sign In
Hostsmith MCP Server

Hostsmith MCP Server

by hostsmith
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

list_sites

Read-only

Lists Hostsmith sites in the user's account with site IDs, domains, and status so agents can resolve existing sites before creating, deploying to, or deleting them.

Instructions

List Hostsmith sites in the user's account. Returns each site's siteId, subdomain, domain, kind ("redirect" for a redirect host, which takes no deploys) and current status - feed siteId into get_site, deploy_files, deploy_create_upload, or delete_site. This is the source of truth for "does the user already have a site at FQDN X" - call it before any create/deploy/delete to resolve the user's site reference. By default queries all data partitions and merges the results; pass partition: "us" or "eu" to limit the query.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_sites"
  }
}

Input Schema

NameRequiredDescriptionDefault
partitionNoFilter by data partition. Omit to query all partitions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.2

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuine behavior beyond that: the default is to query all data partitions and merge results, `partition` narrows it, and `kind: "redirect"` sites take no deploys. It does not mention result ordering, pagination, or volume limits, which is the remaining gap.

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?

Front-loaded with the list operation, then return shape, then usage routing, then the partition default. Three dense sentences with no filler; every clause carries either routing or return-value information.

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, and the description compensates by naming the returned fields (`siteId`, `subdomain`, `domain`, `kind`, status) and the redirect edge case. For a one-optional-parameter read tool, an agent has everything needed to call and interpret it.

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 coverage is 100% and the single parameter is already documented, so the baseline is 3. The description earns a bump by explaining the consequence of omitting `partition` — all partitions are queried and results merged — which is behavioral meaning the schema does not convey.

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 with scope: "List Hostsmith sites in the user's account." It then enumerates the returned fields, which implicitly differentiates it from the single-site sibling `get_site` and the deploy/delete tools named later.

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?

Explicit when-to-use: call before any create/deploy/delete to resolve the user's site reference, and it is the source of truth for "does the user already have a site at FQDN X." It also names the downstream consumers of `siteId` (get_site, deploy_files, deploy_create_upload, delete_site), so an agent knows exactly where to go next.

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