Loading ToolBench

Reading the current corpus…

opsgate MCP server · F · ToolBench

← Browse

opsgate

github.com/polymatx/opsgate

A safety gate between AI agents and your servers: an MCP server exposing structured, policy-checked, audited operations

2026-07-28+STDIO26 tools

48/100

Definition Quality48

Protocol Readiness48

SupportabilityNot measured-

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

opsgate exposes 26 tools with consistent naming (verb_noun pattern) and basic descriptions. All tools have descriptions (10-50 chars, below the 50-200 char optimum). Input schemas are present for parameterized tools but lack detail: most parameters have only a type and minimal description. Output schemas are not documented. Error handling is present but generic. Security posture is strong (read-only vs mutating risk classification, audit logging), but descriptions do not guide LLM selection or explain when to use each tool vs alternatives. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification in the data.

Tools (26)

compose_psread only43/100

Read-only tool to list Docker Compose services

dir_listread only50/100

Read-only tool to list directory contents

disk_usageread onlysource verified43/100

Read-only tool to check disk usage

docker_inspectread only50/100

Read-only tool to inspect Docker container

docker_logsread onlysource verified62/100

Read-only tool to get Docker container logs

docker_psread onlysource verified43/100

Read-only tool to list Docker containers

docker_restartreversiblesource verified62/100

Mutating tool to restart a Docker container

docker_startreversible50/100

Mutating tool to start a Docker container

Issues (5)

HIGHtool-description ↗

Descriptions are uniformly short (10-50 chars) and lack LLM-optimized guidance. Baseline for A+ tools is 50-200 chars with explicit WHAT/WHEN/WHY. E.g., 'Read-only tool to get system information' does not explain when to call system_info vs process_top vs listening_ports, or what fields are returned.

system_infodisk_usageprocess_toplistening_portsservice_listdocker_pscompose_psjournal_errorsnginx_testnginx_reload

HIGHresponse-shaper ↗

Output schemas are not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., does service_status return a boolean or an object with status+timestamp?). Baseline: 100% of A+ tools document return types.

system_infodisk_usageprocess_toplistening_portsservice_listservice_statusdocker_psdocker_logsdocker_inspectdocker_statscompose_psjournal_tail

Recommendations

Expand tool descriptions to 80-150 chars. Include WHAT (e.g., 'Returns CPU, memory, disk usage'), WHEN (e.g., 'Call before service_restart to diagnose issues'), and HOW TO DISTINGUISH (e.g., 'Use system_info for overall health; process_top for per-process breakdown'). Reference pattern:tool-description.
Document output schemas for all tools. Specify field names, types, and whether results are paginated. E.g., 'Returns {status: string, uptime_seconds: number, last_restart: ISO8601}'. Reference pattern:response-shaper.
Add tool annotations: mark all READ_ONLY tools with readOnlyHint=true, REVERSIBLE tools with idempotentHint=true (service_restart is idempotent), and DESTRUCTIVE tools with destructiveHint=true. This enables agents to reason about safety.
Enhance parameter descriptions with format/constraint guidance. E.g., 'Service name (e.g., nginx, postgresql; use systemctl list-units to discover)' or 'Container ID or name (use docker_ps to list)'. Reference pattern:constrained-input.
For shell_exec, implement a dry-run mode or require explicit confirmation via Multi Round-Trip Requests (result 'input_required'). Agents should preview the command and confirm before execution. Reference pattern:confirmation-request.

Score history

Overall score trend

First recorded score · v2 rubric

48/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	48	2026-07-28+	v2