Hostsmith

test_redirect

Read-only

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

Input Schema

Name	Required	Description
`path`	Yes	The path to test, starting with `/`, with an optional query string, such as `/old-page?ref=mail`.
`siteId`	Yes	The site ID (from `list_sites`).
`draftText`	No	`_redirects` text to test in place of the live deploy's file.
`llm_model`	Yes	The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
`partition`	No	Data partition the site lives in. Omit to use the user's home partition.
`draftRules`	No	User rules to test in place of the saved ones.
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely new context beyond that: nothing is persisted, drafts are still tested even when invalid, and a draft's errors are reported by `index` or `line`. That is substantive disclosure about partial-failure behavior rather than a restatement of the read-only hint.

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 core behavior and return shape, then the mode-selection guidance, then the error-reporting caveat. The opening sentence is dense but every clause adds information; no filler or restatement of the name.

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 nonetheless describes the return value (match, status, location, or match: null) and the error shape for drafts. Combined with 100% schema coverage, an agent has everything needed to call this correctly, including the no-side-effect guarantee.

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 a 3 would be the floor, but the description goes further: it explains the precedence semantics of `draftRules` (replaces saved user rules) versus `draftText` (replaces the live deploy's `_redirects`), which the schema fields alone don't clarify. The remaining parameters (`partition`, `conversation_id`, `llm_model`) are left to their already-thorough schema descriptions.

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 ("Test a path against a site's redirect rules") and immediately specifies the response shape: the matching rule with `status` and `location`, or `match: null` when served as-is. That distinguishes it cleanly from mutation siblings like add_redirect, set_redirects, and edit_redirects.

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?

Clearly establishes the default mode (live rules) and the two alternative modes: pass `draftRules` to test in place of saved user rules, or `draftText` to test in place of the live deploy's `_redirects`. It doesn't name sibling tools as alternatives, but the "Nothing is saved" framing implies the contrast with editing tools without leaving the modes to inference.

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

All Hostsmith tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.