Which integrations are available for this server?

Allows inspecting nginx sites, checking SSL status for domains, reading nginx access/error logs, and optionally checking and reloading nginx configuration. Allows listing PM2 processes, reading PM2 app logs, and optionally restarting a named PM2 application.

How do I use vps-ops-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vps-ops-mcp check health and SSL status for my-vps" 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.

vps-ops-mcp

by Akdag94

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

vps-ops-mcp

Don't give your AI raw root SSH. A safe, structured MCP server that lets Claude (or any MCP client) inspect and operate your VPS — nginx, PM2, SSL, UFW, fail2ban — through typed, allowlisted tools instead of free-form shell access.

Read-only by default. Mutating actions don't even exist unless you opt in with an environment variable.

You: "Is everything OK on my server? Any cert expiring soon?"

Claude → server_health(myvps)     → load 0.08, disk 61%, RAM fine
       → ssl_status(myvps)        → b2fest.com expires in 71 days ✓
       → security_audit(myvps)    → ufw active, root login disabled ✓

Why not just an SSH MCP server?

Generic SSH MCP servers hand the model a root shell and hope for the best. This server takes the opposite approach:

	Raw SSH MCP	vps-ops-mcp
Command surface	anything	fixed command templates only
User input in commands	interpolated	strict allowlist regex, rejected otherwise
Credentials	often stored in config	never touched — delegates to your `ssh` client, `~/.ssh/config`, ssh-agent
Password prompts	can hang	`BatchMode=yes`, fails fast
Writes/restarts	always on	off by default, opt-in via env var
`pm2 restart all`	sure, why not	refused by design

Related MCP server: mcp-tool-server

Quickstart

Requires Node 18+ and a working ssh <your-host> from your terminal (key-based auth).

Claude Code

claude mcp add vps-ops -- npx -y vps-ops-mcp

Claude Desktop / Cursor / any MCP client — add to your MCP config:

{
  "mcpServers": {
    "vps-ops": {
      "command": "npx",
      "args": ["-y", "vps-ops-mcp"]
    }
  }
}

Then just ask: "Check the health of myvps" (any alias from your ~/.ssh/config, or user@host).

Enabling mutations (optional)

By default the server is strictly read-only. To enable the two mutating tools (nginx_check_and_reload, pm2_restart):

{
  "mcpServers": {
    "vps-ops": {
      "command": "npx",
      "args": ["-y", "vps-ops-mcp"],
      "env": { "VPS_OPS_ALLOW_MUTATIONS": "true" }
    }
  }
}

Even then: no free-form commands, nginx -t always runs before a reload, and pm2 restart all is refused.

Tools

Tool	What it does	Needs
`list_hosts`	Lists aliases from your local `~/.ssh/config`	nothing (local)
`server_health`	Uptime, load, memory, disk, top processes	ssh
`list_sites`	Enabled nginx sites, PM2 process list, running web services	ssh
`ssl_status`	Cert expiry for every domain found in nginx configs (or one domain)	ssh
`read_logs`	Tail nginx access/error, PM2 app, or journald unit logs	ssh (some logs: sudo)
`security_audit`	Listening ports, UFW, fail2ban, sshd hardening, pending security updates, recent logins	ssh (richer with sudo)
`nginx_check_and_reload` 🔒	`nginx -t`, then graceful reload only if the test passes	opt-in + sudo
`pm2_restart` 🔒	Restart one named PM2 app (never `all`)	opt-in

🔒 = only registered when VPS_OPS_ALLOW_MUTATIONS=true.

About sudo

Some checks (ufw, fail2ban, sshd -T) need root. The server always uses sudo -n (non-interactive): if passwordless sudo isn't configured for those commands, the check degrades gracefully and tells you, instead of hanging on a password prompt. You choose how much to allow in /etc/sudoers.d/.

Safety model

No credential handling. We spawn your system ssh binary. Keys, agents, ProxyJump, known_hosts — all yours, all untouched.
Fixed command templates. Remote commands are string constants. There is no run_command tool and there never will be one in read-only mode.
Allowlist validation. Every user-supplied value (host, app name, domain, unit) must match a strict regex before it goes anywhere near a command line. No escaping heuristics — invalid input is simply rejected.
Bounded output. Every call has a timeout and an output cap, so a runaway tail can't flood your context window.
Mutations are opt-in and minimal. Two tools, both narrow, both guarded.

Roadmap

site_provision — nginx vhost + certbot + PM2 registration in one guarded flow
Docker container inventory & log tools
Caddy support
Multi-server fleet summary (health across all hosts)
Scheduled-check examples (cron + Claude Code headless)

PRs welcome — especially real-world ops workflows this doesn't cover yet.

License

MIT © Azat Akdağ

Available Tools

6 tools

list_hostsList SSH hostsA

Lists host aliases from the local ~/.ssh/config. Purely local — no connection is made. Use one of these aliases as the host argument for the other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries full transparency burden. It discloses that the tool is read-only and local ('purely local — no connection is made'), which is critical for agent safety. It does not specify details like whether it reads all aliases or the output format, but the given context is sufficient.

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?

The description is two sentences: the first states the core functionality, the second provides usage guidance. It is front-loaded, brief, and contains no extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema. The description explains what the tool does and its side effects (none), but does not specify the output format (e.g., array of alias strings). For a simple list tool, this is adequate but could be more complete.

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?

The input schema has no parameters (coverage 100%), and the description adds no parameter information. Following the rule that high schema coverage defaults to 3, and since there are no parameters to explain, this score is appropriate.

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 explicitly states the tool lists host aliases from the local ~/.ssh/config and emphasizes it is purely local with no connection made. This clearly identifies the resource and action, distinguishing it from sibling tools that likely involve remote operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using the aliases from this tool as the 'host' argument for other tools, providing clear context for when to use it. It lacks explicit when-not-to-use guidance or comparisons with specific siblings, but the intent is clear.

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

list_sitesList hosted sites & appsA

Read-only inventory of what a server hosts: enabled nginx sites (domains, ports, upstreams), PM2 process list, and running web-related systemd services.

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	SSH host alias from ~/.ssh/config, or user@hostname

TDQS

A4.2/5.0

Behavior4/5

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

The description declares it read-only, which is a key behavioral trait. However, without annotations, it could detail authorization needs or response format. The offered detail is good but not exhaustive.

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?

Single, well-structured sentence front-loads the read-only nature and lists components precisely. No unnecessary words.

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?

The description covers the tool's domain and scope adequately, given no output schema. Could mention response structure or limits, but sufficient for understanding.

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?

The description does not add meaning beyond the input schema; the parameter 'host' is fully described in the schema. Baseline 3 applies due to high schema coverage.

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 it lists hosted sites and apps, specifying nginx sites, PM2 processes, and systemd services. It distinguishes from sibling tools like list_hosts and server_health by focusing on inventory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for inspecting server hosting, but does not explicitly state when to avoid using it or contrast with alternatives. Context from sibling tools suggests differentiation, but lacking explicit guidance.

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

read_logsRead server logsA

Read-only tail of common logs: nginx access/error, a PM2 app, or a systemd unit's journal. name is required for pm2 (app name) and journal (unit name).

ParametersJSON Schema

Name	Required	Description
`host`	Yes	SSH host alias from ~/.ssh/config, or user@hostname
`name`	No	PM2 app name or systemd unit name (required for pm2/journal)
`lines`	No	Number of lines to tail (10–500, default 100)
`source`	Yes	Which log to read

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavior. It states 'Read-only tail' (non-destructive) and lists sources, but does not mention rate limits, authentication requirements, or error handling. The absence of annotations places a higher burden, but the description covers the essential behavior.

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?

Two sentences, no redundant information. The purpose is stated first, followed by a critical parameter dependency. Efficient and well-structured.

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?

For a simple read-only log tail tool, the description covers source types and parameter constraints. The only minor gap is the lack of output format description (e.g., returns raw log lines), but this is not critical given the context.

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?

Schema coverage is 100%, baseline 3. The description adds value by clarifying that `name` is conditionally required (for pm2 and journal), which is not enforced by the schema. This additional constraint helps the agent correctly invoke the tool.

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?

Description clearly states 'Read-only tail of common logs' and lists specific log types (nginx, PM2, systemd), distinguishing it from sibling tools that cover hosts, sites, security, health, and SSL status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for using the tool to read logs, and specifies that `name` is required for pm2 and journal sources. No explicit when-not-to-use or alternatives are mentioned, but given sibling tools are unrelated, this is sufficient.

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

security_auditSecurity auditA

Read-only security posture check: listening ports, UFW firewall rules, fail2ban jails, sshd hardening flags (root login / password auth), pending security updates, recent logins. Sub-checks that need passwordless sudo degrade gracefully with a note.

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	SSH host alias from ~/.ssh/config, or user@hostname

TDQS

A4/5.0

Behavior4/5

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

The description discloses that the operation is read-only and that sub-checks requiring passwordless sudo will 'degrade gracefully with a note'. This adds valuable behavioral context beyond the input schema, especially since no annotations are provided.

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?

The description is concise with two sentences, no extraneous information, and front-loads the purpose. Every sentence adds value.

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?

Given the tool has one parameter and no output schema, the description covers the main functionality and important behavior (degradation). It lists the checks performed, which helps an agent infer output structure. Slightly less complete if the output format is needed, but adequate.

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?

The input schema already fully describes the single 'host' parameter with its format. The description does not add additional semantic meaning beyond this, so a baseline score of 3 is appropriate.

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 it is a 'Read-only security posture check' and enumerates specific areas checked (listening ports, UFW, fail2ban, sshd, updates, logins), making its purpose unambiguous and distinct from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for security checks but does not explicitly state when to use this tool versus alternatives like server_health or ssl_status. It mentions graceful degradation for missing sudo, which gives some context but lacks clear when-to-use / when-not-to-use guidance.

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

server_healthServer health checkA

Read-only snapshot of a server: uptime, load average, memory, disk usage, and the top processes by CPU and memory.

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	SSH host alias from ~/.ssh/config, or user@hostname

TDQS

A3.7/5.0

Behavior3/5

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

The description states 'Read-only snapshot', indicating no side effects, and lists the data returned. However, with no annotations, it fails to disclose authentication requirements, potential performance impact, or error conditions, so transparency is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that efficiently conveys the tool's purpose and contents. It is front-loaded with 'Read-only snapshot' and avoids unnecessary words, though a slightly more structured presentation (e.g., list) could improve scannability.

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?

No output schema is present, so the description must explain return values. It lists key data points (uptime, load, memory, disk, top processes), which is fairly complete for a health check. It lacks error handling details but is otherwise sufficient for the tool's simplicity.

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?

The input schema has one parameter 'host' with a clear description. The tool description does not add additional meaning beyond the schema's description. Since schema coverage is 100%, baseline score of 3 is appropriate.

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 provides a read-only snapshot of server health including uptime, load average, memory, disk usage, and top processes. It is specific about the resource (server health) and the action (snapshot), and the listed content distinguishes it from sibling tools like list_hosts or read_logs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for monitoring server health but does not explicitly state when to use versus alternatives like security_audit or ssl_status. No guidance on when not to use or prerequisites (e.g., SSH access) is provided.

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

ssl_statusSSL certificate statusA

Checks TLS certificate expiry dates. Without domain, auto-discovers domains from the server's nginx configs and checks each one (max 20). Read-only; runs openssl s_client on the server itself, so it also works for internal-only DNS.

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	SSH host alias from ~/.ssh/config, or user@hostname
`domain`	No	Check a single specific domain instead of auto-discovering

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses read-only operation via openssl s_client, server-side execution, and auto-discovery limit of 20 domains. Could mention output format.

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?

Two sentences, front-loaded with purpose, every word earns its place. No wasted verbiage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Good given no output schema, but lacks description of output format (list of domains with expiry dates? any warnings?). Adequate but could be more complete.

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?

Schema coverage 100% (baseline 3). Description clarifies 'host' as SSH alias and 'domain' as override for auto-discovery, adding meaning beyond 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?

The description clearly states it checks TLS certificate expiry dates, specifies auto-discovery vs explicit domain, and is distinct from sibling tools like security_audit or server_health.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Describes when to use with/without domain, mentions internal DNS capability, but doesn't explicitly compare to sibling security_audit or state when not to use.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 8, 2026
- First observedlist_hosts
- First observedlist_sites
- First observedread_logs
- First observedsecurity_audit
- First observedserver_health
- First observedssl_status

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored 2026-07-08 22:51 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing SSH hosts, inventorying sites, reading logs, security auditing, health checks, and SSL status. There is no overlap in functionality.

Naming Consistency4/5

All tool names use snake_case and follow a predictable pattern, though not all are verb_noun (e.g., security_audit, server_health, ssl_status are noun_noun). Overall consistent and readable.

Tool Count5/5

Six tools is a well-scoped set for a VPS monitoring server, covering essential inspection operations without unnecessary bloat.

Completeness4/5

The tool set covers major inspection needs for a VPS (hosts, sites, logs, security, health, SSL). Missing action-oriented tools (e.g., restart, deploy), but the read-only focus is intentional and well-covered.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
emisarOAuth
dev.emisar
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Cloud Platforms Security Networking & Infrastructure
2354
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

Remote Server MCP
Shell Access Monitoring
elmuz
A
license
Not graded
quality
D
maintenance
A security-first MCP server that gives AI assistants controlled, safe access to manage remote servers via SSH with whitelisted operations and no generic command execution.
Updated 5 months ago (2026-04-12 23:35 UTC)
MIT
mcp-tool-server
File Systems Monitoring
coderman002
A
license
Not graded
quality
C
maintenance
A secure, production-grade MCP server that provides filesystem operations, AST math evaluation, and system diagnostics for LLM agents.
Updated 3 months ago (2026-06-21 11:55 UTC)
MIT
masaro-infra-mcpofficial
Cloud Platforms Networking & Infrastructure
masaro-media
F
license
Not graded
quality
C
maintenance
A secure MCP server providing read-only tools to interact with Cloudflare, Coolify, and other infrastructure services, enabling AI clients to safely diagnose and validate environments.
Updated 2 months ago (2026-07-04 21:58 UTC)
-
RemoteBridge
Shell Access Command Line Developer Tools
varaprasadreddy9676
A
license
Not graded
quality
D
maintenance
A safe, configurable MCP server enabling AI agents to sync, deploy, diagnose, and compare remote servers via structured tools like rsync and SSH.
Updated 5 months ago (2026-04-04 06:15 UTC)
52
5
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Akdag94/vps-ops-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

vps-ops-mcp

Why not just an SSH MCP server?

Quickstart

Enabling mutations (optional)

Tools

About sudo

Safety model

Roadmap

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

masaro-infra-mcpofficial

Latest Blog Posts

MCP directory API