opsgates-agent
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
OpsGate gives you controlled access to this server. Reading is free within the allowed paths. Anything that changes state (writing files, modifying commands, restarting services) first returns a preview and only runs when called again with confirm=true: always show the preview to the user and ask before confirming. Secrets are hidden as *** in outputs; never write *** back into a file (use edit_file on the specific lines instead).
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_dirA | List an allowed directory (depth 1-4). Protected files are shown but marked [protected]. |
| read_fileB | Read an allowed text file in chunks (offset in lines). Secrets are shown as ***. |
| search_filesB | Search a regular expression in files under an allowed path (recursive, skips protected files). |
| tail_logB | Last N lines of a log file under the allowed log folders (default /var/log). |
| service_statusB | Status of a systemd service (is-active + recent journal lines). |
| asterisk_cliB | Asterisk CLI command: read-only ones (pjsip show..., core show channels...) run directly; reloads (only if the owner enabled the Asterisk profile) need confirm=true. Only on servers with Asterisk. |
| db_queryA | One SELECT/SHOW/DESCRIBE/EXPLAIN statement on the configured MySQL/MariaDB (read-only user). |
| run_commandA | Run an allow-listed command (no shell: | ; > * are not interpreted). Path arguments must be in allowed folders. Commands that change things (cp, mv, git pull...) require confirm=true. |
| start_sessionB | Start an allow-listed command in the background; read its output with read_session. |
| read_sessionC | New output of a session since the last read. |
| stop_sessionC | Stop a session. |
| list_sessionsC | Open process sessions. |
| write_fileA | Write a file in allowed paths. Without confirm=true it only returns the diff. Backs up first. |
| edit_fileA | Replace one unique snippet of a file. Without confirm=true it only returns the diff. Backs up first. |
| backup_createB | Timestamped copy of a file into the backups folder. |
| service_restartA | Restart a systemd service (requires confirm=true and the owner's sudo authorization). |
| service_reloadA | Send HUP to a service's main process (graceful reload, e.g. gunicorn/nginx; requires confirm=true). |
| account_statusA | OpsGate plan and this month's tool-call usage (does not count as a call). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools target distinct resources (files, logs, services, sessions, DB, Asterisk), and descriptions draw clear lines between the closest pairs (write_file=whole file vs edit_file=unique snippet; restart=full restart vs reload=HUP). The main soft overlap is service_restart/service_reload/service_status and run_command vs asterisk_cli, but the descriptions resolve these well enough that misselection is unlikely.
Almost everything is snake_case and grouped by domain with recognizable prefixes (service_*, *_session, *_file). There is a minor stylistic split between verb_noun (list_dir, read_file, start_session) and resource_verb (service_restart, db_query, account_status), but the pattern stays readable and predictable per subsystem.
18 tools sits at the heavier end but the breadth maps to genuinely different subsystems of a server-ops agent (filesystem, logs, systemd, DB, Asterisk, process sessions, account). Each tool appears to earn its place, so the count is slightly heavy but not padded.
Core read/write/edit/backup, service control, log tailing, read-only DB, and a full session lifecycle are covered, which is strong. However there are notable gaps for an ops domain: no directory creation, no file delete, and no service start/stop/enable (only restart and reload), so some lifecycle workflows dead-end.