Nginx Proxy Manager MCP

Overview Schema Source Related Servers Discussions Admin

Create Access List

create_access_list

Create an access list in Nginx Proxy Manager to define host access controls using optional IP allow/deny rules and basic-auth users.

Instructions

Create an access list containing optional IP allow/deny rules and basic-auth users. Use this to define access controls for hosts; use update_access_list to change an existing list. NPM stores the rules and credentials, while item passwords are write-only and cannot be read back. Returns the created list object with its ID, name, and rules. Set dry_run=True to preview the exact request without changing NPM.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Human-readable name for this access list.
`items`	No	Basic-auth users as username/password pairs; passwords are write-only in NPM.
`clients`	No	IP or network rules; each directive must be allow or deny.
`dry_run`	No	When True, return the exact request preview without changing NPM.
`pass_auth`	No	Whether NPM passes basic-auth credentials upstream.
`satisfy_any`	No	Whether satisfying any configured access rule is sufficient.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.5.2Oct 16, 2026

addedInput schema / properties / clients / description

Added value: +"IP or network rules; each directive must be allow or deny."

addedInput schema / properties / dry_run / description

Added value: +"When True, return the exact request preview without changing NPM."

addedInput schema / properties / items / description

Added value: +"Basic-auth users as username/password pairs; passwords are write-only in NPM."

addedInput schema / properties / name / description

Added value: +"Human-readable name for this access list."

addedInput schema / properties / pass_auth / description

Added value: +"Whether NPM passes basic-auth credentials upstream."

addedInput schema / properties / satisfy_any / description

Added value: +"Whether satisfying any configured access rule is sufficient."

First observedv0.5.1Oct 16, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that NPM stores rules and credentials, that item passwords are write-only and cannot be read back, that the created object is returned, and what dry_run does. It does not state permission/auth requirements or whether the operation can fail partway, which is the only notable gap.

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 tight sentences, front-loaded with purpose, then routing, then behavioral caveat, then the dry_run escape hatch. Every sentence contributes and nothing is padded.

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?

An output schema exists, so the return-value sentence is mild redundancy rather than a necessity, but the write-only password and dry_run notes are genuinely useful for a mutation tool. Auth/permission prerequisites are the one omission for a create operation with no annotations.

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%, so every parameter already carries its own description; the baseline is 3. The description reinforces two of them (write-only passwords, dry_run preview) but adds no syntax, format, or constraint detail beyond 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?

States a specific verb and resource ('Create an access list') and immediately specifies its contents (IP allow/deny rules and basic-auth users). It explicitly names the sibling update_access_list as the tool for an existing list, so an agent can distinguish it without opening either schema.

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?

Names the alternative explicitly ('use update_access_list to change an existing list') and gives the selecting condition, plus a preview path (dry_run=True) for verifying before committing. Nothing about when to pick this over its sibling is left to inference.

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