Skip to main content
Glama
Sign In
Hostsmith MCP Server

Hostsmith MCP Server

by hostsmith
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

set_redirects

DestructiveIdempotent

Bulk-replace all user redirect rules for a site in one all-or-nothing call using a rule list or _redirects text, with optional version checks to prevent stale overwrites.

Instructions

Replace all of a site's user redirect rules in one call, all or nothing: pass either rules or text in the _redirects format, one from to [status] per line. Use this, or edit_redirects, for bulk work, such as moving a list of redirects from another host, rather than many add_redirect calls. Rules are checked in the order given, before the live deploy's file rules, and the status defaults to 301. A rule sent with the id of an existing rule keeps it. Pass the version from list_redirects to refuse the change if the rules changed since: the error is StaleVersion, with the latest version, so read the rules again and reapply the change. One invalid rule refuses the call with InvalidRules, listing each error by the rule's index or the text's line. The file rules don't change. Redirects apply only on the organization's own custom domains (CustomDomainRequired otherwise). Visitors get the change within about 5 minutes. Rules left out are deleted, and an empty list deletes them all: confirm with the user before dropping rules.

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>"
    },
    "name": "set_redirects"
  }
}

Input Schema

NameRequiredDescriptionDefault
textNoThe new list in the `_redirects` format, one `from to [status]` per line, such as `/old /new 301`. Pass this or `rules`.
rulesNoThe new list, in the order rules are checked. Pass this or `text`.
siteIdYesThe site ID (from `list_sites`).
versionNoThe `version` the rules were read at, from `list_redirects`. Omit to replace whatever the latest list is.
partitionNoData partition the site lives in. Omit to use the user's home partition.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the danger and repeatability profile is structured data, not description value. The description still adds real context beyond that: what gets destroyed (rules left out are deleted, an empty list deletes them all), the instruction to confirm with the user first, propagation delay of about five minutes, custom-domain restriction, and the exact error names `StaleVersion`, `InvalidRules` and `CustomDomainRequired`. That is solid but largely elaboration of the destructive hint rather than novel disclosure, so a 3 fits the calibrated bar for annotated tools.

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?

Purpose and the either/or input choice are front-loaded, and no sentence is filler. It runs long and stacks several topics (input format, ordering, versioning, errors, propagation, deletion) into one paragraph, so a reader must re-scan to find the versioning and deletion rules.

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?

No output schema exists, yet the description covers the outcomes an agent needs: success semantics (atomic, all-or-nothing, idempotent replacement), failure modes with error identifiers and how to resolve each, which rules are untouched (file rules), and timing. Nothing material is missing for a destructive bulk-write tool.

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%, so the schema already documents all five parameters and the nested rule fields; the description's job is to add meaning. It does add meaning for `version` (omitting it replaces whatever the latest list is, passing it guards against concurrent edits, and failure surfaces as `StaleVersion` with the latest version) and for ordering of `rules`, which is behavior the schema only hints at.

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?

"Replace all of a site's user redirect rules in one call, all or nothing" names the verb (replace), the resource (redirect rules), and the scope (whole site, not incremental), and it explicitly separates itself from `add_redirect` and `edit_redirects` so an agent can route without opening another 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?

It gives an explicit alternative and the condition selecting it: use this or `edit_redirects` for bulk work like moving a list of redirects, rather than many `add_redirect` calls. It also states the version workflow (read `list_redirects`, pass `version` to refuse concurrent changes) and the retry path after `StaleVersion`.

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