Skip to main content
Glama
Sign In
Hostsmith MCP Server

Hostsmith MCP Server

by hostsmith
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

list_redirects

Read-only

List a site's redirect rules in evaluation order to see user rules before deployed file rules, identify shadowed entries, and page through results for auditing or edits.

Instructions

List a site's redirect rules in the order they are checked; the first match answers. User rules come first: managedBy: "user", each with an id, kept on the hostname and changed with the redirect tools. Then the live deploy's _redirects rules: managedBy: "file", each with its line, changed only by deploying a new _redirects. A file rule with shadowedBy never answers, because a user rule for the same path comes first. Returns version, which set_redirects and edit_redirects take to refuse a change if the rules changed since; total and a page of at most 1,000 rules from offset; the file's report, with the lines it skipped and why, and whether it is enabled; and the limits. Redirects apply only on the organization's own custom domains: on a shared domain the report says notApplied: "CUSTOM_DOMAIN_REQUIRED".

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": "list_redirects"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoRules to return, at most and by default 1,000.
offsetNoPosition of the first rule to return, from 0. Defaults to 0.
siteIdYesThe site ID (from `list_sites`).
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

A3.8/5.0
Behavior4/5

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

`readOnlyHint: true` already covers the safety profile, and the description adds real substance beyond it: evaluation order, the shadowing behavior ('a file rule with `shadowedBy` never answers'), the optimistic-concurrency role of `version`, the 1,000-rule page cap, and the `notApplied: "CUSTOM_DOMAIN_REQUIRED"` restriction on shared domains. The only shortfall is that some of this is conveyed as raw field syntax rather than plain behavioral prose, but overall it is unusually informative for a read tool.

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?

The core purpose is front-loaded in the first clause, and every sentence carries information — nothing is filler. It is, however, a single dense paragraph with heavy backticked field names, so a reader scanning for 'what does this return' has to work through the rule-source taxonomy first.

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 carries the full burden of describing returns, and it does: `version`, `total`, the page, the file report with skipped lines and `enabled`, and the limits. It also discloses the domain restriction that determines whether redirects apply at all, so an agent has everything needed to call it and interpret the result.

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 coverage is 100%, with descriptions for `limit`, `offset`, `siteId`, and `partition` already in the schema, so the baseline applies. The description reinforces pagination ('a page of at most 1,000 rules from `offset`') but adds no meaning to `partition` or `siteId`, and its detail is mostly about returned fields rather than inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('List a site's redirect rules') and adds ordering semantics ('in the order they are checked; the first match answers') that no schema field conveys. It separates the two rule sources (user vs file) and names the writers (redirect tools vs deploying `_redirects`), which implicitly distinguishes it from `set_redirects`/`edit_redirects`, though it never states outright 'use this to inspect, not to modify'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the mention that `version` is taken by `set_redirects` and `edit_redirects` tells an agent to call this before editing, and the custom-domain caveat sets a precondition. But there is no explicit when-to-use/when-not guidance versus `test_redirect`, `list_domains`, or the other redirect tools, so the agent must infer the workflow.

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