nginx-certbot-mcp

Overview Schema Source Related Servers Discussions Admin

update_site

Idempotent

Redirect an existing site to a new backend by rewriting its proxy_pass directive, preserving SSL and other settings. Automatically tests config and rolls back on failure.

Instructions

Update an existing site's upstream by rewriting its proxy_pass directive(s) in place - everything else in the config, including any SSL server block issue_cert/certbot added, is left untouched. Fails if the domain has no existing config (use create_site instead) or has no proxy_pass directive to update. Test-renders before keeping the change and rolls back automatically if nginx -t fails. The previous config is backed up first, so a bad-but-valid change can be undone later with rollback_site. Does NOT reload nginx - call reload_nginx afterward.

Input Schema

TableJSON Schema

Name	Required	Description
`domain`	Yes	Domain of the existing site to update
`upstream_host`	Yes	New hostname or IP nginx should proxy_pass to
`upstream_port`	Yes	New TCP port on the upstream host

Output Schema

TableJSON Schema

Name	Required	Description
`success`	Yes
`test_output`	Yes	Output of `nginx -t` against the rewritten config, or an explanatory message if nothing was changed
`backup_created`	No	True once the previous config was backed up; undo with rollback_site
`reload_required`	Yes	True on success - nginx has not actually been reloaded yet

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.2Sep 19, 2026

addedOutput schema / properties / backup_created

Added value: +{
+  "description": "True once the previous config was backed up; undo with rollback_site",
+  "type": "boolean"
+}

Addedv0.1.1Sep 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations, disclosing that it rewrites in place, leaves SSL cert blocks untouched, fails on missing config or missing proxy_pass, test-renders with automatic rollback on nginx -t failure, backs up the prior config, and skips the reload. This is rich behavioral context for a mutation tool, and nothing contradicts the idempotentHint=true or destructiveHint=false annotations.

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?

Four sentences, each earning its place: purpose/scope, failure conditions with alternative, safety and backup behavior, and the critical no-reload caveat. Front-loaded with the primary action and progressively revealing caveats in logical order — appropriate length for a mutation tool with meaningful failure and recovery semantics.

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 3-required-param tool with a simple schema and an output schema present, the description covers everything an agent needs to call it correctly: purpose, prerequisites, failure modes, safety guarantees, recovery path, and required follow-up. No significant gaps remain.

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 clear descriptions for all three parameters, so the schema carries the semantic weight. The description marginally reinforces that upstream_host/upstream_port become the new proxy_pass target and that domain must reference an existing config, but it adds no substantial meaning beyond what the schema already provides.

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?

States a specific verb-resource pair: 'Update an existing site's upstream by rewriting its proxy_pass directive(s) in place'. This precisely distinguishes it from siblings like create_site (which creates new configs) and rollback_site (which restores backups). The scope is exact — it names what is changed and what is left untouched.

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?

Explicitly routes to alternatives: 'use create_site instead' when no config exists, 'rollback_site' for undoing a bad-but-valid change, and 'call reload_nginx afterward' because it does not reload. The when-to-use, when-not-to-use, and follow-up steps are all stated without leaving anything to inference.

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