Provides tools for inspecting routes, upstream health, certificates, and reloading configuration via the Caddy admin API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-caddy show me the upstream health"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Caddy web server management. Exposes 7 tools for inspecting routes, upstream health, certificates, and reloading configuration via the Caddy admin API.
With uvx (recommended):
CADDY_HOST=http://10.0.0.31:2019 uvx mcp-caddyWith Docker:
docker run -i \
-e CADDY_HOST=http://10.0.0.31:2019 \
ghcr.io/aaronckj/mcp-caddy:latestAdd to Claude Code:
claude mcp add caddy -s user -e CADDY_HOST=http://10.0.0.31:2019 -- uvx mcp-caddyRelated MCP server: Identity Admin MCP Server
Variable | Required | Default | Description |
| No |
| Caddy admin API URL |
| No |
| HTTP timeout in seconds |
The Caddy admin API binds to localhost:2019 by default. Depending on your setup:
MCP server on same host as Caddy → use the default http://localhost:2019
Caddy in Docker, MCP server on the same Docker host → add ports: ["127.0.0.1:2019:2019"] to your Caddy compose service, then use http://localhost:2019
Remote Caddy host → SSH tunnel: ssh -L 2019:localhost:2019 user@caddy-host, then use http://localhost:2019
Caddy exposes admin via reverse proxy → set CADDY_HOST=https://caddy-admin.example.com
The Caddy admin API has no authentication by default. If you expose it beyond localhost, add Caddy basic auth to that route.
Tool | Description |
| Caddy version and loaded modules |
| Full configuration as JSON |
| All virtual hosts with upstream targets |
| Upstream proxy health status |
| TLS automation policies and ACME issuers |
| Convert a Caddyfile snippet to JSON |
| Reload config from a JSON string or file path |
git clone https://github.com/aaronckj/mcp-caddy
cd mcp-caddy
uv sync --extra dev
uv run pytest -vConvert a Caddyfile snippet to JSON config using Caddy's built-in adapter.
| Name | Required | Description | Default |
|---|---|---|---|
| caddyfile | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only states 'Convert using built-in adapter.' It omits whether the operation is side-effect-free, error handling, or output format. The term 'convert' suggests read-only, but details are lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is very concise at 10 words. It efficiently conveys the core purpose without extraneous text, though it could be slightly expanded for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter and no output schema or annotations, the description is insufficient. It does not explain the output (JSON config path or content), error scenarios, or how to use the result, leaving the agent without enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must elaborate on the parameter 'caddyfile.' The description only mentions 'Caddyfile snippet,' which adds minimal meaning beyond the parameter name, failing to specify format constraints or valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Convert' and the resource 'Caddyfile snippet to JSON config using Caddy's built-in adapter.' It specifies the tool's function and naturally distinguishes it from sibling tools like add_reverse_proxy_route or server_info, which deal with different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no context about prerequisites or output interpretation, and no mention of related tools or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an HTTP redirect route. from_host: domain to redirect (e.g. 'old.example.com'). to_url: destination URL. status_code: 301 (permanent), 302 (temporary), 307, or 308.
| Name | Required | Description | Default |
|---|---|---|---|
| to_url | Yes | ||
| from_host | Yes | ||
| server_name | No | ||
| status_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only explains parameters and status codes, not side effects like whether redirect creation overwrites existing rules, requires server existence, or triggers reload. Minimal disclosure beyond parameter semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second sentence concisely describes all parameters. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and key parameters, but lacks information on return values, prerequisites (e.g., does the server need to exist?), and how the redirect is applied. Gaps remain given the sibling tools and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It explains from_host, to_url, and status_code with examples and allowed values. However, server_name is left undocumented, so not all parameters are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Add an HTTP redirect route,' using a specific verb and resource. The tool name and description clearly distinguish it from sibling tools like add_reverse_proxy_route and add_static_file_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over siblings (e.g., when a redirect vs reverse proxy is appropriate). The description implies usage for redirects but provides no exclusion criteria or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a reverse proxy route to Caddy. host: domain (e.g. 'app.example.com'). upstream: backend dial address (e.g. 'localhost:3000'). server_name: Caddy server block (auto-detects first server if empty).
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| upstream | Yes | ||
| server_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses auto-detection of server_name but lacks details on idempotency, whether it overwrites existing routes, or any side effects like configuration reload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently explains all parameters and mentions auto-detection. No superfluous words, though a structured list might improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides sufficient context for a simple add tool: explains each parameter and server_name behavior. However, missing details like error handling, duplicate behavior, or idempotency, which could be important for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds clear semantic meaning for all 3 parameters with practical examples (e.g., 'host: domain (e.g. app.example.com)'). This compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a reverse proxy route to Caddy,' specifying the verb and resource. It does not differentiate from siblings like add_redirect or add_static_file_server, but the name and context make the purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples for host and upstream, and mentions auto-detection for server_name. However, no explicit guidance on when to use this tool versus alternatives, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a static file server route to Caddy. path: URL path to match (e.g., '/files/*'). root: filesystem directory to serve. server_name: auto-detects first server if empty.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| root | Yes | ||
| server_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behaviors like side effects (e.g., config modification, persistence), but it only gives basic parameter info. No mention of what happens on conflict or system impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: one sentence plus brief parameter explanations. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description is sparse. It covers core parameters but lacks details on return values, error handling, or duplicate routes. Minimal but functional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'path' with an example, 'root' as filesystem directory, and 'server_name' with auto-detection behavior, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a static file server route to Caddy, which distinguishes it from sibling tools like add_reverse_proxy_route. The verb 'Add' and resource 'static file server route' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or when-not-to-use conditions. The description only explains what the tool does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific Caddy config node at the given path. config_path: e.g. '/apps/http/servers/srv0'. Changes take effect immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| config_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'Changes take effect immediately,' which is a key behavioral trait, but lacks details on reversibility, safety, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and path specification. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description covers the essential: action, path format, and immediate effect. Could elaborate on behavior if path doesn't exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description in schema). The description only provides an example for config_path, not adding much beyond the schema. No constraints or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Delete a specific Caddy config node at the given path' with a concrete example of config_path ('/apps/http/servers/srv0'). Differentiates from siblings like get_config_path and update_config_path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for deleting config nodes, with an example path. No explicit when-not or alternatives, but the context of deletion is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a route by index from an HTTP server's route list. Use list_routes to find the index. Changes take effect immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| route_index | Yes | ||
| server_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It reveals that changes take effect immediately, a key behavioral trait. But it omits potential side effects, irreversible nature, or permissions needed, which would be helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action. No unnecessary words, every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the essential: what it does, how to prepare, and the immediate effect. Minor gaps include handling of invalid inputs or confirmation of success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal meaning beyond the parameter names. It hints that route_index is used to identify the route by its index, but does not explain server_name or provide constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a route by index') and the specific resource ('HTTP server's route list'). It distinguishes from sibling tools like list_routes and get_route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a prerequisite (use list_routes to find the index) and notes that changes take effect immediately. However, it does not explicitly state when not to use this tool or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List TLS certificate automation policies: subjects, ACME issuers, and CAs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the responsibility for behavioral disclosure. It states the tool 'lists' (a read operation) but does not mention any side effects, authentication requirements, rate limits, or behavior when no policies exist. Minimal beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the purpose with no wasted words. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low complexity, the description is fairly complete: it states what is listed (subjects, issuers, CAs). It could mention if the result is a list or single item, or behavior on empty results, but it is adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the baseline is 4 per scoring rules. The description does not need to add parameter meaning as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing certificate automation policies, specifying the listed aspects (subjects, ACME issuers, CAs). The verb 'list' and resource 'certificate automation policies' are specific and unambiguous, and it distinguishes itself from sibling tools which focus on routes, servers, or configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives or exclusions. As a simple list tool with no parameters, usage is implied but not elaborated. A 3 is appropriate as it covers the basic context without providing comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full Caddy configuration as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the basic action. It does not mention whether the operation is read-only, requires authorization, or any side effects like possibly large payloads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is concise and front-loaded, effectively communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately states what it does and the output format. However, it could be more complete by noting the scope ('full configuration') and lack of side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is trivially 100%. According to the guidelines, 0 parameters yields a baseline of 4. The description adds no extra parameter semantics, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'full Caddy configuration', and the output format 'JSON'. It distinguishes itself from sibling tools like 'get_config_path' which retrieves a specific path, and other tools that modify config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_config_path' for a specific path or 'server_info' for server details. The description lacks context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific Caddy config node by path. config_path: e.g. '/apps/http/servers' or '/apps/tls'.
| Name | Required | Description | Default |
|---|---|---|---|
| config_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, any authentication requirements, or possible side effects. For a tool that retrieves configuration, basic safety information is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the action, the second provides examples. No extraneous text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter, but with no output schema, the description could mention what the returned data looks like (e.g., JSON object). The examples help but the overall completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for the config_path parameter, but the description adds value by providing concrete examples ('/apps/http/servers', '/apps/tls'), clarifying the expected format beyond the schema's bare string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'Caddy config node by path', with examples. This clearly distinguishes the tool from siblings like delete_config_path or update_config_path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_config, list_servers, or list_routes. It lacks any explicit 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full configuration of a specific route by index. Use list_routes to find server_name and index.
| Name | Required | Description | Default |
|---|---|---|---|
| route_index | Yes | ||
| server_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states it 'gets' the configuration, implying a read operation, but does not explicitly confirm it is non-destructive, require any permissions, or describe the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with no wasted words. The purpose and a key usage hint are front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of the return format (e.g., configuration fields) despite no output schema. Also missing behavioral context like read-only guarantee. While the tool is simple, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds context that route_index and server_name come from list_routes, but does not explain their meaning beyond names or specify constraints (e.g., range of route_index). This is partial but helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full configuration of a specific route by index, and points to list_routes as a way to find the needed parameters. This distinguishes it from sibling tools like add_reverse_proxy_route, delete_route, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear prerequisite hint ('Use list_routes to find server_name and index'), which guides the agent on how to obtain the required parameters. However, it does not explicitly state when not to use the tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured routes (virtual hosts) with hosts, handler, upstreams, listen addresses, and route index.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description accurately discloses the tool's read-only nature and the specific data returned. It does not mention side effects or prerequisites, but none are expected for a list operation. Behavioral transparency is sufficient for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource. Every word adds value. Ideal conciseness for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully explains what the tool does and what it returns (hosts, handler, upstreams, listen addresses, and route index). Complete for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters; schema coverage is 100% trivially. With no parameters to describe, the baseline is 4. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states the verb 'List' and the resource 'all configured routes (virtual hosts)'. Specifies the returned fields: hosts, handler, upstreams, listen addresses, and route index. Clearly distinguishes from sibling tools like get_route (single route) and add_reverse_proxy_route (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use, but the purpose is clear: retrieve an overview of all routes. Siblings like get_route are implied for single route retrieval. For a simple list operation with zero parameters, the description provides adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Caddy HTTP server blocks with their names, listen addresses, and route counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not mention read-only nature, authentication requirements, or any side effects. For a list operation, at least indicating it is a read-only query would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence front-loading the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is fairly complete. However, given many sibling tools, a brief distinguishing hint would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline 4 applies. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Caddy HTTP server blocks', and specifies the returned information (names, listen addresses, route counts). It distinguishes itself from sibling tools like 'server_info' (detailed info for one server) and 'list_routes' (list routes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as 'server_info' or 'list_routes'. Given multiple sibling tools, some usage context would help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all reverse proxy upstreams with their health status and request counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only list but does not explicitly state side effects, permissions, or response details. Adequate for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundancy, front-loaded with key information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description hints at returned data (health status, request counts). Lacks mention of edge cases (e.g., empty list) but sufficient for a zero-parameter list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no parameter detail. Per the scoring rule, 0 params yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (reverse proxy upstreams), and included details (health status and request counts). It distinguishes from sibling tools like add_reverse_proxy_route and list_servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states what it does without context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload Caddy config. source: raw JSON string (starts with '{') or path to a JSON config file.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It does not disclose whether the operation is safe (e.g., config validation before applying), whether it's destructive (overwrites current config), or what error conditions exist. The importance of this transparency is high given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the action and the crucial parameter constraint. It is front-loaded with the verb 'Reload'. However, splitting into two sentences (action, then source format) might improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description omits what the tool returns (success status, error details, etc.). Given the operation complexity (reloading server config) and numerous sibling tools, the description lacks context about expected outcomes and when to use this tool over similar ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the parameter 'source' is just a string. The description adds significant value by clarifying it can be 'raw JSON string (starts with '{') or path to a JSON config file.' This reduces ambiguity and helps the agent choose the correct format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reload Caddy config') and specifies the source format. This distinguishes it from sibling tools like get_config (read-only) or adapt_config (isolated validation). However, it could be more explicit about what 'reload' entails (e.g., applying new configuration in-place).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It explains the source parameter format but does not mention prerequisites (e.g., config validity), expected side effects, or alternatives among siblings. An agent given this description might not know when to prefer reload over adapt_config or delete_route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Caddy server version and list of loaded modules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool returns version and modules, but does not explicitly mention that it is read-only or free of side effects. The name 'get' implies safety, but the description could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It communicates the core functionality efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is largely complete. It mentions what is returned (version and modules), though the exact format is not detailed. Still, it is sufficient for an agent to understand the tool's value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (no parameters to describe). The description adds no parameter info because none exist, which is appropriate. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving Caddy server version and list of loaded modules. It uses specific verbs and resources, and distinguishes well from sibling tools which focus on routes, config, or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, given its simplicity and zero parameters, the context is implied. A score of 3 reflects the lack of explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a specific Caddy config path with a new value via PATCH. config_path: e.g. '/apps/http/servers/srv0/listen'. value: JSON string of the new value.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| config_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Only discloses it uses PATCH, but no information on side effects, permissions, error behavior, or whether the operation is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Efficiently communicates core info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing return value info, error behavior, and prerequisites. For a simple update tool, adequate but not comprehensive; output schema absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides zero descriptions (0% coverage). Description adds crucial meaning: config_path example and clarifies value is JSON string, significantly aiding parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Update' and resource 'Caddy config path', with example path. Differentiates from sibling tools like get_config_path and delete_config_path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites, exclusions, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0adapt_configadd_redirectadd_reverse_proxy_routeadd_static_file_serverdelete_config_pathdelete_routeget_certificatesget_configget_config_pathget_routelist_routeslist_serverslist_upstreamsreloadserver_infoupdate_config_pathEach tool targets a distinct operation: adding different route types, listing different resources, getting specific config nodes, etc. No overlapping purposes; descriptions clearly differentiate.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_reverse_proxy_route, list_servers, delete_route). Only 'reload' is a single verb but it's standard and fits the pattern.
With 16 tools, the server is well-scoped for managing Caddy configurations. Each tool serves a clear purpose without excessive granularity or missing essential operations.
The set covers full lifecycle: create (add_*), read (list, get), update (update_config_path), delete (delete_route/delete_config_path), plus reload, config adaptation, and certificate info. No obvious gaps for typical Caddy management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage Chili Piper scheduling links, meetings, routing rules, and teams. Admin only. Experimental.
Manage hosts, redirects, SSL, and traffic analytics from Claude and other AI assistants.
Tailscale device, route, DNS, key, user, and ACL management over MCP and CLI.
Secure tunneling, reverse proxy and remote access for local applications.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aaronckj/mcp-caddy'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
