Skip to main content
Glama
Sign In
Hostsmith MCP Server

Hostsmith MCP Server

by hostsmith
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

test_redirect

Read-only

Test a path against a site's live redirect rules to see which rule matches and where visitors are sent, or check draft rules and _redirects text before saving or deploying. Nothing is saved.

Instructions

Test a path against a site's redirect rules, as the site would answer it: the rule that matches, with its status and the location visitors are sent to, or match: null when the path is served as is. Tests the live rules by default. To check a change before saving or deploying it, pass draftRules to test in place of the saved user rules, or draftText to test in place of the live deploy's _redirects. A draft's errors are listed by index or line, and its valid rules are still tested. Nothing is saved.

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

Input Schema

NameRequiredDescriptionDefault
pathYesThe path to test, starting with `/`, with an optional query string, such as `/old-page?ref=mail`.
siteIdYesThe site ID (from `list_sites`).
draftTextNo`_redirects` text to test in place of the live deploy's file.
partitionNoData partition the site lives in. Omit to use the user's home partition.
draftRulesNoUser rules to test in place of the saved ones.

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 readOnlyHint=true; the description adds materially more: the default target is the live rule set, draft testing happens in place of saved rules or the live deploy's `_redirects`, draft errors are reported by `index` or `line`, valid draft rules are still tested despite errors, and nothing persists.

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?

Front-loaded with the primary behavior and return shape, then defaults, then draft modes. Every clause carries information, though the opening sentence is densely nested and slightly slows first-pass parsing.

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, so the description must carry the return contract — and it does, covering match/status/location, the null-match case, and the index/line error reporting for drafts. For a read-only test tool with 5 fully documented parameters, nothing an agent needs to call it correctly is missing.

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 schema already explains `siteId`, `path`, `draftRules` vs `draftText`, and `partition`. The description re-frames which rule set each draft parameter substitutes for and gives the default behavior, but adds little syntax or format detail the schema lacks. Baseline 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?

Specific verb (test) and resource (a path against a site's redirect rules) plus an explicit statement of the answer shape: the matching rule with `status` and `location`, or `match: null` when served as-is. This is clearly distinguishable from sibling mutators like add_redirect, edit_redirects, and set_redirects.

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?

States the default mode (tests live rules), the two alternative modes and when to pick them (pass `draftRules` or `draftText` to check a change before saving or deploying), and closes with the exclusion that matters — nothing is saved, so this is not a mutating route. No inference required.

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