nginx-certbot-mcp

Overview Schema Source Related Servers Discussions Admin

create_site

Create a new nginx server block for a domain, proxying to a given upstream host and port. It validates with nginx -t before applying and rolls back on failure, preparing the site for reload and SSL.

Instructions

Create a new nginx server block from the websocket-capable default template. Validates and test-renders (nginx -t) before touching live config, and rolls back automatically if the test fails. Does NOT reload nginx or request a certificate - follow with reload_nginx to go live, then issue_cert to get SSL. To point an existing site at a different upstream later, use update_site instead of recreating it.

Input Schema

TableJSON Schema

Name	Required	Description
`domain`	Yes	Domain for the new server block, e.g. mysite.julcap.net
`upstream_host`	Yes	Hostname or IP nginx should proxy_pass to
`upstream_port`	Yes	TCP port on the upstream host

Output Schema

TableJSON Schema

Name	Required	Description
`success`	Yes
`config_path`	No	Present on success: absolute path of the written config
`test_output`	Yes	Output of `nginx -t` against the rendered config
`reload_required`	Yes	True on success - nginx has not actually been reloaded yet

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Sep 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the minimal annotations (openWorldHint and destructiveHint only), the description discloses key behavior: validation via `nginx -t`, automatic rollback on failure, and what it deliberately does not do (reload/cert). This fully informs the agent of side effects and prerequisites.

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?

Three sentences, no redundancy, and the most important facts (purpose, safety, follow-up) are front-loaded. Every sentence earns its place, making it efficient for an agent to parse.

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?

Given the tool's moderate complexity and the presence of an output schema, the description covers all essential aspects: what it does, safety mechanism, required follow-up, and alternatives. Nothing an agent needs to call it correctly or decide whether to use it is missing.

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?

The schema covers 100% of parameters with clear descriptions, so the baseline is 3. The description adds context that the parameters define an nginx proxy upstream (host/port) and ties the domain to a server block, enriching meaning beyond the schema's mechanical definitions.

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 clearly states the tool creates a new nginx server block using a specific template, distinguishing it from related tools like update_site. The verb 'create' and resource 'server block' are specific, and the mention of 'websocket-capable default template' adds precision.

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?

It explicitly provides usage context: does NOT reload nginx or request a certificate, and instructs to follow with reload_nginx and issue_cert. It also names the alternative (update_site) for existing sites, giving clear when-to-use vs. when-not-to guidance.

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