Click on "Deploy 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., "@Nginx Proxy Manager MCP list my Nginx Proxy Manager proxy hosts"
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.
A small tool that lets Claude read and change Nginx Proxy Manager through its API.
It runs on your own computer. Your password stays on your computer.
Check that NPM is up (npm_status).
List, look at, add, change, turn on, turn off, and delete: proxy hosts, redirection hosts, 404 hosts, and streams (npm_hosts).
List and delete certificates. List access lists (npm_hosts).
See the newest changes made in NPM (npm_audit_log).
Anything else in the NPM API, such as making or renewing a certificate, access lists, users, and settings (npm_call).
When Claude changes a host, the tool reads the current one first and merges your change. Nothing else on that host is lost.
Related MCP server: npm-mcp
Every call has a safety level.
read: runs right away.
change: adding, editing, turning on or off. It does not run until
Claude asks you and sets confirm. Claude shows you what will be sent first.
destructive: deleting anything, and any change to users or settings.
It also needs an exact phrase typed back, like delete proxy-hosts 5.
Other protections:
Login and token calls are blocked. The tool logs in by itself.
The password and the login token are never printed. They are removed from error messages.
Paths must start with /api/. The tool cannot be pointed at another site.
Open the NPM web page (port 81).
Go to Users, then Add User.
Use a separate user just for this, like claude@example.com.
Then you can turn it off on its own later.
Turn OFF two-step login for this user. The tool cannot do the code step.
Give it Administrator, or pick the permissions you want it to have.
Do not paste the password in a chat. Put it only in the config file below.
Open the Claude desktop app settings and find the MCP servers config file.
Add the block from claude_desktop_config.example.json.
Change the address, email, and password.
NPM_URL: your NPM admin address, like http://172.16.90.75:81
NPM_EMAIL: the login email of the user you made
NPM_PASSWORD: that user's password
That file now holds a secret. Do not share it. Do not put it on GitHub.
The example uses uvx. If you do not have it, use Python instead:
pip install D:\GitHub-Projects\nginx-proxy-manager-mcpThen use "command": "nginx-proxy-manager-mcp" and no args.
Restart the Claude desktop app.
Ask Claude: "Show my Nginx Proxy Manager proxy hosts."
NPM_VERIFY_TLS=false: for an https address with a self-signed certificate.
For a new outside address, use its own subdomain as a proxy host. Custom Locations under an existing domain were unreliable on this NPM.
The NPM API is not officially documented. This tool follows the
schema in the NPM GitHub repo. If a new NPM version changes it, use
npm_call and tell me what broke.
Not tested against a real NPM when first built. It was tested against a fake server.
Show the newest changes made in NPM (who did what, and when). Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
"..."'
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?
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?
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?
.
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?
States a concrete action ('show') applied to a clearly identified artifact type ('the newest changes' / audit-log style events among whom 'made' them), giving verb-plus-resource detail adequate to separate itself from unrelated siblings such as npm_status or npm_hosts during routine selection, though stronger families naming conventions reduce precision competent agents tolerate.
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?
'(who did what, and when)' clarifies content goals indirectly steering replacement interactions networks somewhat inviting possible versions potentially vaguely bosses wishing chronological organized java claiming worried sufficiently available recommended verses reads dates history tracing=
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call any NPM API path directly (the catch-all).
method: GET, POST, PUT, PATCH or DELETE. path: starts with /api/, for example /api/nginx/certificates. data: JSON body for POST and PUT. GET runs right away. POST and PUT need confirm=true after asking the user. DELETE, and anything under /api/users or /api/settings, also needs confirm_phrase set to ' ' exactly, for example 'DELETE /api/nginx/certificates/3'. Login and token paths are blocked. Use npm_hosts for normal hosts and streams. Use this for certificates (create, renew), access lists, users, settings, and the audit log.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| path | Yes | ||
| method | Yes | ||
| confirm | No | ||
| confirm_phrase | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does most of it: GET executes immediately while POST/PUT require confirm=true after user approval, and DELETE or anything under /api/users or /api/settings requires an exact confirm_phrase. It also discloses that login/token paths are blocked. It omits auth/permission and rate-limit behavior, hence not a 5.
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?
Line-per-parameter layout with the catch-all framing first, then per-method confirmation rules, then blocked paths, then sibling routing. Every sentence carries distinct operational information and none is redundant.
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 five-parameter, unannotated catch-all mutation tool this is complete: an agent knows the method semantics, the path format, how to build the body, exactly when and how to confirm, what is forbidden, and where to look for sibling operations. An output schema exists, so return-value explanation is unnecessary.
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 none of the five properties are typed or documented in the schema, so the description must compensate and does: it defines method's allowed values, path's required prefix and an example, data as the JSON body for POST/PUT, and the exact required format of confirm_phrase with a worked example.
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?
States a specific verb+resource ('Call any NPM API path directly') and explicitly frames itself as the catch-all, then names the sibling it complements ('Use npm_hosts for normal hosts and streams'). An agent can distinguish it from npm_hosts, npm_status and npm_audit_log without opening a schema.
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?
Gives explicit routing: use npm_hosts for hosts and streams, use this for certificates (create, renew), access lists, users, settings, and the audit log. It also states exclusions (login and token paths are blocked), so both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, look at, add, change, delete, enable or disable NPM items.
kind: proxy-hosts, redirection-hosts, dead-hosts, streams, certificates, or access-lists. action: list, get, create, update, delete, enable, disable.
list and get are read only. list gives a short summary unless full=true.
create needs data. Only the main fields are needed. Sensible
defaults fill the rest (for proxy-hosts: http, no certificate,
block_exploits on). Proxy host example:
{"domain_names": ["app.example.com"], "forward_host": "172.16.1.5",
"forward_port": 8080, "allow_websocket_upgrade": true}
update needs id and data with ONLY the fields to change. The tool
reads the current item and merges, so nothing else is lost.
create, update, enable and disable need confirm=true, after asking the user.
delete needs confirm=true and confirm_phrase='delete '. certificates and access-lists can only be listed, read, or deleted here. To make or change those, use npm_call. Tip: for a new outside address, use its own subdomain as a proxy host. Custom Locations under an existing domain have been unreliable on this NPM.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| data | No | ||
| full | No | ||
| kind | Yes | ||
| action | No | list | |
| confirm | No | ||
| confirm_phrase | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does: list/get are read-only, list returns a summary unless full=true, create only needs main fields with sensible defaults spelled out, and critically update does a read-merge so untouched fields are preserved. It also discloses the destructive-delete confirmation gate and exact confirm_phrase syntax.
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?
Front-loaded with the action/kind matrix and bulleted per-action rules; nearly every line earns its place. It runs long, and the trailing tip about Custom Locations is opinionated, but it is genuinely actionable rather than filler.
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 7-parameter, multi-action mutation tool with no annotations and 0% schema coverage, the description fills every gap an agent needs: action routing, per-action preconditions, merge semantics, defaults, and confirmation gating. An output schema exists, so return-value detail is rightly omitted.
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, and it does: kind values, action values, id role, data semantics with a concrete proxy-host example, full=true effect, confirm requirement per action, and confirm_phrase format. All 7 parameters are given meaning beyond the bare JSON types.
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 names the resource (NPM items), enumerates the exact kinds (proxy-hosts, redirection-hosts, dead-hosts, streams, certificates, access-lists) and the full action set, so an agent knows precisely what surface this tool covers. It also explicitly distinguishes itself from sibling npm_call for the certificate/access-list mutation case.
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 gives when-to-use routing ('certificates and access-lists can only be listed, read, or deleted here. To make or change those, use npm_call'), preconditions for each action (create needs data, update needs id+data, confirm=true required, delete needs confirm_phrase with exact format), and even a domain tip about subdomains vs Custom Locations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that Nginx Proxy Manager is reachable and logged in.
Returns the NPM version and how many proxy hosts, redirection hosts, 404 hosts and streams exist. Read only. Good first call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses that the call verifies login state (an auth-related behavior), declares 'Read only', and reveals the shape of the returned counts. It omits failure behavior (what happens when NPM is unreachable or not logged in), which is the main remaining gap for a diagnostic 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?
Two sentences with zero waste; the core action is front-loaded and the return summary follows. No filler or restatement of the tool name.
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?
An output schema exists, so explaining return values is not strictly necessary, yet the description's summary is harmless and aids selection. A no-parameter, read-only health check is otherwise fully covered; only error/offline behavior is left unspecified.
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 takes zero parameters, so the baseline of 4 applies; nothing is required of the description here beyond what it already establishes.
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?
States a specific verb and resource: checks whether Nginx Proxy Manager is reachable and authenticated, and enumerates what the result contains (version, host/stream counts). An agent can distinguish this health-check tool from npm_hosts, npm_call, and npm_audit_log without opening a schema.
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?
'Good first call' gives clear context for when to reach for this tool — as an initial connectivity/auth probe. It stops short of naming alternatives or an explicit when-not condition, but the use case is unambiguous.
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.
v0.1.0npm_audit_lognpm_callnpm_hostsnpm_statusScored across 4 tools
npm_status and npm_audit_log are clearly distinct, but npm_hosts and npm_call overlap for certificate and access-list operations. The descriptions provide clear guidance on when to use each, though npm_call as a catch-all could subsume other tools.
All names use snake_case with an npm_ prefix, which is consistent. However, they mix nouns (npm_status, npm_hosts, npm_audit_log) with a verb (npm_call), deviating from a strict verb_noun pattern.
Four tools cover the domain efficiently: a health check, a multi-resource manager, a raw API gateway, and an audit log. Each tool earns its place without redundancy or bloat.
The combination of npm_hosts (CRUD for hosts/streams) and npm_call (any API path) ensures full lifecycle coverage for all NPM resources. Minor convenience gaps (e.g., certificate creation only via npm_call) do not limit overall capability.
Manage hosts, redirects, SSL, and traffic analytics from Claude and other AI assistants.
Remote streamable-HTTP MCP server running on a single Cloudflare Worker. Your assistant gets live Airbnb, Amazon, Booking.com, Google Flights, Maps and Reddit data, social search on X, Instagram and TikTok, the Meta Ad Library, and image/video generation without any keys. Connect your own accounts to let it send WhatsApp or Telegram messages, work an IMAP inbox, manage Meta Ads campaigns and publish to X and LinkedIn. OAuth 2.1 with PKCE; stored credentials are AES-256-GCM encrypted.
Run field service from Claude, ChatGPT or Copilot: dispatch, billing, customer messages, photos, and change the software itself, with a confirm step before every change. This address is the India region; US East, Canada, Norway and NZ addresses are at fieldproxy.ai/mcp.
Supervised API-write gateway for AI agents with policy, human approval and execution receipts.
