Enables Authentik administration for users, groups, applications, providers, outposts, flows, events, and invitations.
Allows admin management of Cloudflare zones, DNS records, cache purging, firewall/WAF rules, IP access rules, page rules, custom hostnames, SSL/TLS certificate packs, zone settings, and analytics.
Enables Docker host administration, including containers, images, volumes, networks, stats, logs, container lifecycle operations, and pruning.
Allows management of Nginx Proxy Manager / NPMPlus proxy hosts, redirection hosts, streams, access lists, certificates, users, settings, and Let's Encrypt certificate requests.
Provides tools for managing Porkbun domains, DNS records, URL forwarding, nameservers, SSL bundles, and TLD pricing.
Provides Proxmox VE administration capabilities for nodes, VMs/LXCs, snapshots, backups, storage, cluster status, users, and background tasks.
Provides tools for managing Uptime Kuma monitors, heartbeats, maintenance windows, status pages, and notifications.
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., "@master-mcp restart the nginx container and show me its last 50 log lines"
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.
Ein einziger MCP-Server (stdio, TypeScript) für die Admin-Verwaltung von:
Cloudflare (Zonen, DNS, Cache, Firewall/WAF, Custom Hostnames, Zone-Settings, Analytics)
Porkbun (Domains, DNS, URL-Forwarding, Nameserver, SSL-Bundle, Pricing)
Docker (Container, Images, Volumes, Netzwerke, Stats, Logs - lokaler Socket oder Remote-TCP)
Proxmox VE (Nodes, VMs/LXCs, Snapshots, Backups, Storage, Cluster, Tasks)
Nginx Proxy Manager / NPMPlus (Proxy-Hosts, Redirects, Streams, Access-Lists, Zertifikate, Users)
Uptime Kuma (Monitore, Heartbeats, Wartungsfenster, Status-Pages, Notifications)
Authentik (Users, Gruppen, Applications, Providers, Outposts, Flows, Events, Invitations)
Coolify (Applications, Deployments, Datenbanken, Services, Server, Projekte, Teams)
Der Server exponiert selbst nur drei MCP-Tools (list_services, list_actions,
execute_action - siehe Architektur). Die eigentlichen ~150 Aktionen
sind serverseitig in einem Katalog organisiert; hier die vollständige Liste je Dienst.
Jede Aktion wird über execute_action mit service, action, optional instance und
den unten genannten Parametern aufgerufen. ⚠️ markiert destruktive Aktionen
(Löschen/Stop/Prune/... - irreversibel oder zustandsändernd mit Risiko).
Aktion | Beschreibung |
| Zonen (Domains) im Account auflisten, optional nach Name gefiltert |
| Details einer einzelnen Zone per ID |
| DNS-Records einer Zone auflisten, optional nach Typ/Name gefiltert |
| Neuen DNS-Record (A, AAAA, CNAME, TXT, MX, ...) anlegen |
| Felder eines bestehenden DNS-Records ändern |
| DNS-Record löschen |
| Edge-Cache einer Zone leeren (bestimmte Dateien oder alles) |
| (Legacy) Firewall-Regeln einer Zone auflisten |
| Alle Zone-Settings lesen (SSL-Modus, Always-Online, Minify, ...) |
| Ein Zone-Setting ändern (z.B. |
| Page Rules einer Zone auflisten |
| Page Rule mit Ziel-URL-Muster und Aktionen anlegen |
| Page Rule löschen |
| IP/Land/ASN-Zugriffsregeln (Block/Challenge/Whitelist) auflisten |
| IP/IP-Range/Land/ASN-Zugriffsregel anlegen |
| IP-Zugriffsregel löschen |
| SSL/TLS-Zertifikatspakete einer Zone auflisten |
| Custom Hostnames (SSL for SaaS) auflisten |
| Custom Hostname anlegen |
| Custom Hostname löschen |
| Analytics-Dashboard-Summen (Requests, Bandbreite, Threats) für einen Zeitraum |
Aktion | Beschreibung |
| API-Erreichbarkeit prüfen, liefert die öffentliche IP zurück - guter Smoke-Test |
| Alle Domains im Account auflisten (paginiert, optional mit Labels) |
| DNS-Records einer Domain abrufen (per ID, per Typ+Subdomain, oder alle) |
| Neuen DNS-Record anlegen |
| Bestehenden DNS-Record ändern |
| DNS-Record löschen |
| Autoritative Nameserver einer Domain ändern (wirkt global auf die Auflösung) |
| Kostenloses SSL-Zertifikatsbündel (Chain, Private Key, Public Key) abrufen |
| Bestehende URL-Weiterleitungen einer Domain auflisten |
| URL-Weiterleitung für Domain/Subdomain anlegen |
| URL-Weiterleitung löschen |
| Aktuelle Nameserver einer Domain abrufen |
| Porkbuns TLD-Preisliste abrufen (Registrierung, Verlängerung, Transfer) |
Aktion | Beschreibung |
| Container auflisten (per Default nur laufende, |
| Vollständige Inspect-Details (Config, State, Mounts, Netzwerk) eines Containers |
| Gestoppten Container starten |
| Laufenden Container stoppen, optional mit Grace-Timeout |
| Container neu starten, optional mit Grace-Timeout |
| Container entfernen, optional forciert + inkl. Volumes |
| Aktuelle stdout/stderr-Logs (mit Zeitstempeln) abrufen |
| Vorhandene Images auf dem Host auflisten |
| Image (optional bestimmter Tag) aus der Registry ziehen |
| Volumes auf dem Host auflisten |
| Netzwerke auf dem Host auflisten |
| Kompakte Host-Zusammenfassung (Container-/Image-Zahlen, Version, OS, CPU, RAM) |
| Container umbenennen |
| Momentaufnahme der Ressourcennutzung (CPU %, Speicher, Netzwerk-I/O) |
| Laufende Prozesse in einem Container auflisten (wie |
| Neuen Container aus einem Image anlegen, optional sofort starten |
| Alle gestoppten Container entfernen |
| Image entfernen, optional forciert |
| Neues repo:tag auf ein bestehendes Image anwenden |
| Ungenutzte Images entfernen (per Default nur dangling) |
| Netzwerk anlegen (Default-Driver: bridge) |
| Netzwerk entfernen |
| Volume anlegen (Default-Driver: local) |
| Volume entfernen, optional forciert |
| Alle ungenutzten Volumes entfernen |
Aktion | Beschreibung |
| Cluster-Nodes mit Status, CPU, Memory, Uptime auflisten |
| VMs (qemu) und/oder LXC-Container auflisten, pro Node oder Cluster-weit |
| Aktuellen Status (running/stopped, CPU, Mem, Uptime) einer VM/eines LXC abrufen |
| Gestoppte VM/LXC starten |
| VM/LXC hart stoppen (wie Stromstecker ziehen) - Datenverlust bei ungesichertem Zustand möglich |
| VM/LXC per ACPI/Agent-Signal sauber herunterfahren |
| VM/LXC sauber neu starten |
| Storage-Pools auflisten (pro Node oder Cluster-Konfiguration) |
| Cluster-Status: Member-Nodes, Quorum, Cluster-Info |
| Konfiguration (Cores, Memory, Disks, Netzwerk, ...) einer VM/eines LXC abrufen |
| Konfiguration (Cores, Memory, Beschreibung) einer VM/eines LXC ändern |
| Snapshots einer VM/eines LXC auflisten |
| Neuen Snapshot anlegen |
| Snapshot löschen |
| VM/LXC auf einen Snapshot zurücksetzen, verwirft den aktuellen Zustand |
| Backup-Archive auf einem Node auflisten (bestimmter Storage oder alle) |
| Detaillierten Node-Status abrufen (Uptime, Load, Memory, CPU) |
| Proxmox-Zugriffskontroll-Benutzer auflisten |
| Status eines Background-Tasks per UPID abfragen (z.B. laufenden Start/Stop/Snapshot-Task pollen) |
Aktion | Beschreibung |
| Alle Proxy-Hosts auflisten, inkl. Owner/Access-List/Zertifikat-Details wenn unterstützt |
| Neuen Reverse-Proxy-Host anlegen (Domain(s) → Forward-Ziel, SSL/Caching/Security-Optionen) |
| Forward-Ziel, Domains, SSL oder Security-Einstellungen eines Hosts ändern |
| Proxy-Host löschen |
| Deaktivierten Proxy-Host aktivieren |
| Proxy-Host deaktivieren - nimmt die dahinterliegende Seite offline |
| Konfigurierte Redirection-Hosts (Domain-Weiterleitungen) auflisten |
| Konfigurierte TCP/UDP-Streams auflisten |
| Konfigurierte Access-Lists (Basic-Auth/Allow-Deny-Regeln) auflisten |
| Bekannte SSL-Zertifikate auflisten |
| NPM/NPMPlus-Benutzer auflisten |
| Neuen NPM-Benutzer anlegen und Passwort setzen (zweistufig: User anlegen, dann Auth setzen) |
| Name/Nickname/E-Mail/Admin-Rolle/Disabled-Status eines Benutzers ändern |
| NPM-Benutzer löschen |
| Konfigurierte 404/Catch-all-("Dead")-Hosts auflisten |
| Alle NPM/NPMPlus-Anwendungseinstellungen auflisten |
| Eine Anwendungseinstellung per ID ändern (z.B. |
| Neues Let's-Encrypt-Zertifikat für eine oder mehrere Domains anfordern |
| SSL-Zertifikat löschen |
Aktion | Beschreibung |
| Alle Monitore (ID, Name, Typ, URL/Hostname, Aktiv-Status, Check-Intervall) auflisten |
| Historische Heartbeats (Up/Down über die Zeit) für einen Monitor, über einen Zeitraum in Stunden |
| Monitor pausieren - stoppt Checks und Alerting bis zur Wiederaufnahme |
| Pausierten Monitor wieder aktivieren |
| Monitor und dessen Historie dauerhaft löschen |
| Neuen HTTP(s)-Monitor anlegen, der eine URL periodisch auf Erreichbarkeit prüft |
| Name/URL/Check-Intervall/Retry-Intervall/Resend-Intervall/Aktiv-Status eines Monitors ändern |
| Konfigurierte Notification-Provider (E-Mail, Discord, Telegram, ...) auflisten |
| Konfigurierte Wartungsfenster auflisten |
| Wartungsfenster anlegen, optional auf bestimmte Monitore beschränkt, unterdrückt Alerts währenddessen |
| Öffentliche Status-Pages auflisten, keyed nach Slug |
Hinweis: Accounts mit 2FA werden nicht unterstützt (Login schlägt mit klarer Fehlermeldung fehl, statt hängenzubleiben).
Aktion | Beschreibung |
| Authentik-Benutzer auflisten, optional nach Suchtext/Aktiv-Status gefiltert |
| Details eines einzelnen Benutzers per ID |
| Neuen Benutzer anlegen (Username, Name, E-Mail, optionale Gruppenmitgliedschaften) |
| Name/E-Mail/Aktiv-Status eines bestehenden Benutzers ändern |
| Benutzer löschen |
| Passwort eines Benutzers setzen/zurücksetzen |
| Gruppen auflisten, optional nach Suchtext gefiltert |
| Neue Gruppe anlegen, optional mit Superuser-Rechten |
| Benutzer einer Gruppe hinzufügen |
| Benutzer aus einer Gruppe entfernen |
| Applications auflisten, optional nach Suchtext gefiltert |
| Alle Provider auflisten (OAuth2, SAML, Proxy, LDAP, ... - alle Typen kombiniert) |
| Outpost-Instanzen (Proxy/LDAP/RADIUS-Deployments) und deren Health auflisten |
| Flows (Login, Enrollment, Recovery, ...) auflisten, optional nach Suchtext gefiltert |
| Audit-Log-Events auflisten, standardmäßig neueste zuerst |
| Enrollment-Einladung anlegen, optional mit vorausgefüllten Daten und Ablaufdatum |
Aktion | Beschreibung |
| Alle Applications über alle Projekte/Server auflisten |
| Vollständige Details einer Application per UUID |
| Gestoppte Application starten |
| Laufende Application stoppen |
| Application neu starten |
| Deployment anstoßen (per Application/Resource-UUID oder Tag), optional erzwungener No-Cache-Rebuild |
| Aktuelle Logs einer Application abrufen |
| Umgebungsvariablen einer Application auflisten |
| Umgebungsvariable einer Application anlegen/überschreiben |
| Umgebungsvariable einer Application per Key löschen |
| Aktuell laufende/wartende Deployments auflisten |
| Details/Status eines Deployments per UUID |
| Alle Coolify-verwalteten Datenbanken auflisten |
| Vollständige Details einer Datenbank per UUID |
| Gestoppte Datenbank starten |
| Laufende Datenbank stoppen |
| Datenbank neu starten |
| Alle Services auflisten (One-Click-App-Stacks wie Plausible, Ghost, ...) |
| Vollständige Details eines Service per UUID |
| Gestoppten Service starten |
| Laufenden Service stoppen |
| Service neu starten |
| Alle mit dieser Coolify-Instanz verbundenen Server auflisten |
| Vollständige Details eines Servers per UUID, inkl. Erreichbarkeits-/Nutzbarkeits-Status |
| Alle Projekte auflisten |
| Vollständige Details eines Projekts per UUID, inkl. Environments/Ressourcen |
| Alle Teams auflisten, auf die dieser API-Token Zugriff hat |
Related MCP server: InfraOps MCP Server
Token-effizientes Search+Execute-Pattern statt eines Tools pro Aktion: der Server
exponiert nur drei MCP-Tools (list_services, list_actions, execute_action); die
eigentlichen 151 Aktionen (siehe Alle Aktionen im Detail)
liegen serverseitig in einem Katalog und werden erst bei Bedarf per Freitextsuche
gefunden.
Jeder Dienst kann mehrere benannte Instanzen mit eigenen Zugangsdaten/Zielen haben
(z.B. zwei Docker-Hosts oder zwei Proxmox-Nodes) - siehe .env.example.
src/
core/
types.ts - ActionDef/ServiceModule/InstanceConfig Interfaces
instances.ts - Multi-Instanz-Discovery aus ENV-Variablen
registry.ts - Katalog, Suche, Instanz-Auflösung
http.ts - axios-Client-Helper
services/
cloudflare.ts, porkbun.ts, docker.ts, proxmox.ts, npm.ts, uptimeKuma.ts, authentik.ts, coolify.ts
index.ts - Aggregiert alle ServiceModules
index.ts - MCP-Server-Wiring (stdio)npm install
cp .env.example .env # eintragen, welche Dienste genutzt werden
npm run buildclaude mcp add master-mcp -- node /pfad/zu/masterMCP/dist/index.js(oder die passende Konfiguration in claude_desktop_config.json / MCP-Client
deiner Wahl - stdio-Transport, Env-Variablen aus .env werden beim Start via
dotenv geladen.)
npm run dev # tsx, ohne Build
npm run typecheck
npm test # vitest, 146 Tests über alle 8 Module
npm run buildAlle Credentials kommen ausschließlich aus Umgebungsvariablen (.env, nie committen).
execute_action markiert jede Aktion als readOnly/destructive - destruktive
Aktionen (Löschen, Stop/Reboot, Prune, ...) sind klar gekennzeichnet.
insecureTls-Felder (Proxmox, NPM, Authentik, Docker-TLS) sind Opt-in und
standardmäßig false - nur für selbstsignierte LAN-Zertifikate gedacht.
Execute one action against one instance of a service. Look up the action id and its params schema via list_actions first. instance selects which configured target to use (e.g. which Proxmox node or Docker host) - omit it only if the service has exactly one instance configured. Destructive actions (as flagged by list_actions) change or delete remote state - double check params before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action id as returned by list_actions. | |
| params | No | Action-specific params object, validated against its schema. | |
| service | Yes | Service id, e.g. 'docker', 'proxmox', 'cloudflare'. | |
| instance | No | Instance id, e.g. 'home'. Required if the service has more than one instance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key mutation trait: destructive actions change or delete remote state, with a warning to double-check params. That is real behavioral context beyond the schema. It does not cover auth/permission requirements, idempotency, or error/side-effect behavior on partial failure, so it falls short of fully transparent.
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?
Three short sentences, front-loaded with the core action, then prerequisite, then parameter rule, then risk warning. Every sentence carries distinct, non-redundant information and there is no 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 mutation tool with no annotations, no output schema, and a nested params object, the description covers purpose, prerequisite lookup, instance selection, and destructive risk. The remaining gap is return/response behavior and error handling, which matters more here because no output schema exists to fill it.
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 100%, so the schema already documents all four parameters, including the instance requirement and params validation. The description restates the instance selection semantics and the params-schema validation rather than adding new syntax, formats, or examples, so the baseline of 3 applies.
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 states a specific verb and resource ('Execute one action against one instance of a service') and bounds the scope to a single action/instance pair. It implicitly and explicitly distinguishes itself from the sibling listing tools by referencing list_actions as the lookup step that precedes execution.
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 an explicit prerequisite ('look up the action id and its params schema via list_actions first') and an explicit conditional rule for the optional parameter ('omit it only if the service has exactly one instance configured'). It also flags when extra care is warranted (destructive actions). Nothing about when to reach for this tool 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.
Search/list available actions across configured services. Returns each action's id, owning service, a one-line summary, whether it's read-only or destructive, and its JSON input schema. Use query to search by keyword (e.g. 'restart container', 'dns record', 'proxy host'); omit both filters to list everything. Only configured services' actions are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text keyword search over action id/summary/service. | |
| service | No | Restrict to one service id, e.g. 'docker' or 'proxmox'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers unusually well by disclosing the exact return shape (id, service, summary, read-only/destructive flag, JSON input schema). It also states the scoping constraint that only configured services' actions appear. It does not confirm the operation is side-effect free, nor mention result limits or pagination for a potentially large listing.
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?
Four dense sentences, each doing distinct work: purpose, return fields, query usage, default/scope behavior. The purpose leads, and there is no filler or repetition.
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?
Because there is no output schema, the description's enumeration of return fields is essential and present, and the configured-services limitation is called out. It leaves open how large result sets are bounded (pagination, truncation) for an unfiltered list-everything call.
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 coverage is 100%, so the baseline is 3 and the schema already documents both parameters. The description adds real value on top by giving concrete keyword examples for `query` and by clarifying that omitting both filters is equivalent to listing everything — behavior the schema does not express.
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?
Names a specific verb and resource ('Search/list available actions across configured services') and even enumerates the returned fields, so the agent knows exactly what comes back. It does not explicitly name its siblings list_services or execute_action, so the differentiation from execute_action is only implicit in the word 'list'.
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 concrete usage instruction plus examples: search via `query` with samples like 'restart container', 'dns record', 'proxy host', and the default of omitting both filters to list everything. It never states when to reach for a sibling tool instead (e.g., list_services to enumerate services, execute_action to run one), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all admin services this MCP can reach (Uptime Kuma, NPMPlus/Nginx Proxy Manager, Porkbun, Cloudflare, Docker, Proxmox), which are configured, and which named instances exist for each (e.g. multiple Docker hosts or Proxmox nodes with separate credentials). Call this first if you're unsure what's available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden; it discloses what information is surfaced (which services exist, which are configured, which named instances/credentials exist per service). It implies a safe read but never explicitly says the call is read-only or cheap, so one point is left on the table.
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?
A single information-dense sentence followed by a one-line call to action. The purpose is front-loaded and every clause earns its place; nothing is redundant with the name or title.
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?
No output schema or annotations exist, yet the description tells the agent exactly what the response conveys: required services, configuration state, and per-service instances. For a zero-parameter discovery tool this is complete enough to call confidently.
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, which is the baseline 4 case. There are no parameter semantics to disambiguate, and the description does not need to add any.
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 the specific verb (List) and resource (all admin services this MCP can reach), then enumerates the concrete backends (Uptime Kuma, NPMPlus, Porkbun, Cloudflare, Docker, Proxmox) and the per-service detail returned (configured status, named instances). This is unambiguous and clearly distinct from the sibling read/execute tools.
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?
Explicitly tells the agent when to reach for it: 'Call this first if you're unsure what's available.' That is a clear entry-point condition, but it does not name an alternative tool or state when this tool is NOT the right choice.
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.0execute_actionlist_actionslist_servicesScored across 3 tools
The three tools target clearly distinct phases: discovering services/instances, discovering available actions, and executing a chosen action. There is no overlap in purpose, and the descriptions reinforce the correct order of use.
All tool names follow a consistent verb_noun snake_case pattern: list_services, list_actions, execute_action. The plural vs. singular noun choice is natural for listing multiple items versus executing one action.
Three tools are well-scoped for a generic admin-action gateway: one for service discovery, one for action discovery, and one for execution. The dynamic action surface avoids tool bloat while covering the server's purpose.
The tool set provides complete lifecycle support for the gateway pattern: list services/instances, list available actions with schemas and safety flags, and execute any action against a chosen instance. No obvious operational gaps exist for the stated domain.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Remote MCP for RunComfy: ComfyUI deployments, hosted models, LoRA training. 31 tools.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
