Skip to main content
Glama
YawLabs

@yawlabs/caddy-mcp

by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

caddy_tls

Idempotent

Check and configure Caddy TLS settings: view current status, set ACME email, CA URL, or ACME profile to manage HTTPS certificates.

Instructions

Get or configure TLS/HTTPS settings. Actions: 'status' shows current TLS config, 'set_email' sets the ACME email, 'set_acme_ca' sets the ACME CA URL, 'set_acme_profile' sets the ACME profile (Caddy 2.10+), 'ech_status' reads the Encrypted ClientHello config at apps/tls/encrypted_client_hello (Caddy 2.10+, read-only here). Works on both fresh and existing Caddy instances, including one with no config at all: the set_* actions create apps/tls, and any missing parents, when it is not set. Writes target policies[0].issuers[0] only, and only when that issuer's module is 'acme' -- on a multi-policy TLS config, or one whose first issuer is 'internal' (Caddy's local CA), edit the intended issuer with caddy_config_set instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
caNoACME CA URL (for 'set_acme_ca' action)
emailNoACME email address (for 'set_email' action)
actionYesAction to perform
profileNoACME profile name (for 'set_acme_profile'). Requires Caddy 2.10+ and a CA that offers profiles; Let's Encrypt uses 'shortlived' for 6-day certificates. Valid names are defined by the CA, not by Caddy. EXPERIMENTAL upstream (the ACME profiles spec is still a draft; Caddy marks the field 'subject to change' and may rename or drop it). Caddy accepts any name on load, so a success here does not mean the CA offers it: if this issuer's CA does not advertise the name, every order from this issuer fails at issuance time, reported only in Caddy's own logs. Caddy then either falls through to the next issuer in the policy, which issues WITHOUT the profile, or -- when this is the policy's only issuer, which is the shape this tool creates -- keeps retrying and issues no certificate at all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.4
    • changedInput schema / properties / profile / description
      Previous value: -"ACME profile name (for 'set_acme_profile'). Requires Caddy 2.10+ and a CA that offers profiles; Let's Encrypt uses 'shortlived' for 6-day certificates. Valid names are defined by the CA, not by Caddy."New value: +"ACME profile name (for 'set_acme_profile'). Requires Caddy 2.10+ and a CA that offers profiles; Let's Encrypt uses 'shortlived' for 6-day certificates. Valid names are defined by the CA, not by Caddy. EXPERIMENTAL upstream (the ACME profiles spec is still a draft; Caddy marks the field 'subject to change' and may rename or drop it). Caddy accepts any name on load, so a success here does not mean the CA offers it: if this issuer's CA does not advertise the name, every order from this issuer fails at issuance time, reported only in Caddy's own logs. Caddy then either falls through to the next issuer in the policy, which issues WITHOUT the profile, or -- when this is the policy's only issuer, which is the shape this tool creates -- keeps retrying and issues no certificate at all."
  2. Changed2 schema fields changedv2.3.2
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "status",
-  "set_email",
-  "set_acme_ca"
-]New value: +[
+  "status",
+  "set_email",
+  "set_acme_ca",
+  "set_acme_profile",
+  "ech_status"
+]
    • addedInput schema / properties / profile
      Added value: +{
+  "description": "ACME profile name (for 'set_acme_profile'). Requires Caddy 2.10+ and a CA that offers profiles; Let's Encrypt uses 'shortlived' for 6-day certificates. Valid names are defined by the CA, not by Caddy.",
+  "type": "string"
+}
  3. First observedv2.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Even though annotations already mark the tool as idempotent and non-destructive, the description reveals important side effects: set_* actions create apps/tls and missing parents, and writes only target policies[0].issuers[0] when that issuer's module is 'acme'. It also discloses version constraints (Caddy 2.10+), read-only behavior for ech_status, and the failure semantics of set_acme_profile when a CA does not support the profile.

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?

The description is dense but every sentence contributes operational guidance: purpose, action list, version gates, creation behavior, and the alternative path. It is front-loaded with the main purpose and action enumeration, and the longer edge-case clauses earn their length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers version requirements, fresh-vs-existing behavior, exact mutation targets, exclusions, and the alternative tool. The only notable gap is the lack of explicit return-value shape for status/ech_status, but since there is no output schema and the read actions are described as showing/reading config, this is a minor omission.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining how the action parameter changes config: set_* creates missing parents and targets only the first issuer under specific conditions. It also reinforces the meaning of each action, though ca and email formats remain mostly handled by the schema.

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 opening line states a specific verb and resource: 'Get or configure TLS/HTTPS settings.' The description then enumerates the five actions, making the tool's scope unmistakable. It also differentiates from generic config tools by pointing to caddy_config_set as the fallback for unsupported TLS shapes.

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 says when the tool is appropriate: 'Works on both fresh and existing Caddy instances, including one with no config at all.' It also gives a clear when-not-to-use rule by instructing that on multi-policy TLS configs or with an 'internal' first issuer, you should 'edit the intended issuer with caddy_config_set instead.'

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