Skip to main content
Glama

caddy_reverse_proxy

Define reverse proxy routing by setting incoming domain and upstream targets. Provide a stable id to update the route in place, preventing duplicate entries.

Instructions

Add a reverse proxy route. The most common operation — just specify where traffic comes from and where it goes. Example: from='api.local' to=['localhost:3000']. When id is OMITTED the route is appended to the server's routes array — calling the tool twice with the same args produces TWO duplicate routes (non-idempotent). When id is SUPPLIED the route is written via PATCH under that @id, so repeat calls REPLACE in place (idempotent). Strongly recommended: supply a stable id for any route managed from automation or production tooling. Note: @ids are config-global in Caddy (NOT route-scoped). If id collides with an @id used by a non-route object (TLS issuer, server, etc.) the call refuses with an error rather than clobbering it. Once an @id is registered to a route under one server, subsequent calls update that route in place regardless of the server argument. Upstream scheme is honored: an https:// upstream gets a TLS transport and defaults to port 443, anything else is dialed in the clear. A to list that MIXES https:// and non-https entries is refused — the TLS transport applies to the whole handler, not per-upstream — so split those into two routes or use caddy_add_route.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoOptional stable @id for the route. When set, repeat calls REPLACE the route in place (idempotent). When omitted, the route is APPENDED — calling twice with identical args creates a duplicate route. @ids are config-global in Caddy: if this id is already used by a non-route object the call refuses rather than clobbering it.
toYesUpstream addresses, at least one (e.g., ['localhost:3000', 'localhost:3001']). An 'https://' prefix dials the upstream over TLS (port 443 unless one is given); http:// and bare addresses are dialed in the clear. Do not mix https:// and non-https entries in one call.
fromYesDomain, path, or domain/path to match (e.g., 'api.local', '/api/*', 'app.local/ws')
serverNoCaddy server name (default: srv0)srv0

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv2.4.0
    • changedInput schema / properties / to / description
      Previous value: -"Upstream addresses (e.g., ['localhost:3000', 'localhost:3001'])"New value: +"Upstream addresses, at least one (e.g., ['localhost:3000', 'localhost:3001']). An 'https://' prefix dials the upstream over TLS (port 443 unless one is given); http:// and bare addresses are dialed in the clear. Do not mix https:// and non-https entries in one call."
    • addedInput schema / properties / to / items / minLength
      Added value: +1
    • addedInput schema / properties / to / minItems
      Added value: +1
  2. First observedv2.2.0

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses conditional idempotency (append vs PATCH replace), config-global @id semantics, collision refusal, behavior after an id is registered, and TLS transport rules. This goes well beyond the coarse annotations and is not contradicted by them.

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?

Dense but well organized: the one-line purpose and example come first, followed by idempotency, id-scoping behavior, and upstream handling. Every sentence carries operational information; there is no filler or repetition beyond what is safety-relevant.

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?

For a config-mutating tool with four parameters and no output schema, this description covers all calling modes, failure modes (collision refusal, mixed-scheme refusal), and side effects (in-place replacement, global id behavior). An agent has enough information to call it correctly and predict repeat-call behavior.

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 baseline is 3, but the description adds operational meaning beyond the schema: id omission vs supply changes idempotency, upstream scheme changes transport and default port, and mixed scheme lists are refused. The example also makes the from/to shape concrete.

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?

The description states a specific verb and resource ('Add a reverse proxy route') and gives a concrete from/to example, making the operation unmistakable. The domain-specific phrasing also separates it from the generic sibling caddy_add_route, and the final note references caddy_add_route as the lower-level fallback.

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?

The description explicitly recommends supplying a stable id for automation, warns that omitting id duplicates routes, and gives a clear alternative (caddy_add_route) for mixed https/non-https upstreams. This gives an agent concrete decision rules rather than leaving tool selection to inference.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/YawLabs/caddy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server