Skip to main content
Glama
Sign In
Hostsmith MCP Server

Hostsmith MCP Server

by hostsmith
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

edit_redirects

Destructive

Apply batches of redirect rule additions, updates, and deletions in one atomic change, so bulk edits either fully succeed or fail without partial updates.

Instructions

Apply a batch of adds, updates and deletes to a site's user redirect rules, in order, as one change: all of them or none. Use this, or set_redirects, for bulk work rather than many single calls. Rule ids come from list_redirects and start with r_. File rules can't be changed here: an operation naming a file rule's line answers FileRule, with the line and the operation's index. Pass the version from list_redirects to refuse the batch if the rules changed since (StaleVersion, with the latest version). One invalid rule refuses the batch with InvalidRules, listing each error by the operation's index. Redirects apply only on the organization's own custom domains (CustomDomainRequired otherwise). Visitors get the change within about 5 minutes.

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

Input Schema

NameRequiredDescriptionDefault
siteIdYesThe site ID (from `list_sites`).
versionNoThe `version` the rules were read at, from `list_redirects`. Omit to apply the batch to whatever the latest list is.
partitionNoData partition the site lives in. Omit to use the user's home partition.
operationsYesApplied in order, each to the list the ones before it left.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.0

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 adds substantial behavior beyond that: ordering as one atomic change, version-based staleness refusal, per-operation error indexing, the custom-domain precondition, and ~5 minute propagation. These are exactly the risks an agent needs before committing a destructive batch.

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?

Purpose and atomicity are front-loaded, followed by alternatives, then preconditions and error contracts. Every sentence carries actionable content; the error-code names double as machine-checkable outcomes rather than 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 destructive batch tool with no output schema, it covers preconditions, failure modes, and propagation. The remaining gap is the success response shape, which is not described and cannot be inferred from an output schema.

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 baseline is 3, but the description adds real meaning: `version` is explained as a staleness guard sourced from `list_redirects`, rule ids are said to start with `r_`, and `operations` are applied in order each to the list the prior ones left. That goes beyond field-level schema text.

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?

Opens with a specific verb and resource: 'Apply a batch of adds, updates and deletes to a site's user redirect rules, in order, as one change'. It also states atomicity ('all of them or none') and names what it is not (not the path for many single calls).

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?

Explicitly routes bulk work here or to `set_redirects` rather than many single calls, and states a clear exclusion: file rules can't be changed here. It does not explain how to choose between this tool and `set_redirects`, both of which are named for the same bulk job.

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