remote-observer-mcp

remote-observer-mcp

A read-only MCP server for observing registered local and SSH hosts, providing system, service, container, Git, and GPU status/log inspection through a closed-world registry without arbitrary shell access.

Category
访问服务器

README

remote-observer-mcp

remote-observer-mcp gives ChatGPT a broad read-only view of explicitly registered local and SSH-accessible hosts and workspaces without exposing arbitrary shell execution, arbitrary hostnames, or arbitrary filesystem roots.

The repository also contains a separate Execution Bridge for exact commands and break-glass shell scripts. That bridge is intentionally not an MCP tool: every execution waits on an independent GitHub Environment approval before a self-hosted runner can invoke remote-observer-exec.

Architecture

ChatGPT
  |
  +-- read lane
  |    -> OpenAI Secure MCP Tunnel
  |    -> tunnel-client on gateway
  |    -> remote-observer-mcp (stdio child)
  |    -> logical host/workspace registry
  |    -> semantic observer
  |    -> preferred CLI / safe fallback
  |    -> local or strict SSH transport
  |    -> bounded + redacted result and metadata-only audit
  |
  +-- execution lane
       -> committed versioned execution request
       -> workflow_dispatch(request_id only)
       -> hosted validation + request digest
       -> GitHub Environment: remote-execution
       -> required reviewer approval
       -> [self-hosted, remote-observer] runner
       -> remote-observer-exec
       -> registered local or SSH target

Design and implementation records are under docs/superpowers/specs/ and docs/superpowers/plans/. Gateway deployment is in deploy/README.md; execution-runner deployment is in deploy/execution-runner.md; all remaining real-account/credential/runner operations are batched in USER_ACTIONS.md.

Safety boundary

The public MCP surface is semantic and read-only. It does not provide:

  • arbitrary execute, shell, ssh, command, argv, script, hostname, URL, method, or absolute-path tools;
  • arbitrary file reads outside registered workspace roots;
  • tmux send-keys / run-shell or session mutation;
  • fd --exec, AST rewrite/fix, yq in-place writes, Docker exec/inspect, package install/update, archive extraction, or service/process mutation;
  • automatic software installation or privilege elevation.

Hosts, workspaces and resources are referenced by logical IDs in a gateway-local TOML registry. Unknown or unsafe identifiers fail closed. Local observer processes use asyncio.create_subprocess_exec; SSH uses registered aliases with BatchMode=yes, StrictHostKeyChecking=yes, and a bounded connection timeout.

Read-only does not mean secret-free. Logs, diffs and workspace files can contain sensitive material. Collection uses allowlists and secret-path denial as the primary boundary. Output is bounded and best-effort redacted before crossing MCP. Metadata-only audit records never store raw observed output or argv.

Read-only MCP tools

Every tool is annotated read-only, non-destructive, idempotent and closed-world.

Host discovery and baseline system state

  • list_hosts
  • host_overview
  • system_status
  • disk_usage
  • process_status

Workspaces and files

  • list_workspaces
  • workspace_find
  • workspace_search
  • workspace_read
  • workspace_tree
  • file_info
  • checksum

Workspace inputs use a logical workspace ID plus validated relative paths. Concrete roots stay in local configuration and are not returned by discovery tools. Common secret paths such as .env, private keys and credential files are denied before content collection.

Code and structured data

  • code_search
  • json_query
  • structured_query

code_search uses search-only ast-grep; rewrite/fix options are not exposed. Structured selectors use a narrow dot-key / array-index grammar rather than arbitrary jq/yq programs.

tmux

  • tmux_sessions
  • tmux_windows
  • tmux_panes
  • tmux_capture

Only list/capture operations exist. tmux_capture is bounded; no key injection or tmux mutation is exposed.

Processes, network, filesystem and hardware

  • process_list
  • process_tree
  • network_listeners
  • network_interfaces
  • network_routes
  • dns_lookup
  • filesystem_status
  • disk_hotspots
  • user_sessions
  • hardware_info
  • sensor_status

Process observation avoids environment variables and full command lines by default. Network observation is passive; there is no port scan or arbitrary socket/URL probe.

systemd and journals

  • service_status
  • service_logs
  • service_failures
  • systemd_timers
  • journal_query

Log access is opt-in per registered service. journal_query accepts only fixed, bounded time/priority/line filters for registered services.

Docker and Compose

  • container_list
  • container_logs
  • container_stats
  • compose_status

Only configured containers are returned. Container logs are opt-in. Compose status is enabled only for workspaces with compose = true. No Docker exec/inspect/mutation exists in the MCP lane.

Git

  • repo_status
  • repo_diff
  • repo_log

Git diff collection excludes common sensitive paths plus validated configured patterns. Remote URLs are not part of the observer surface.

NVIDIA GPU

  • gpu_status
  • gpu_processes

Both use fixed nvidia-smi query fields; no process control is exposed.

Runtime, toolchain, package and archive inspection

  • tool_availability
  • runtime_versions
  • python_environment
  • node_environment
  • rust_environment
  • cargo_metadata
  • nix_environment
  • mise_environment
  • package_info
  • archive_list

cargo_metadata is offline. Nix observation uses offline/read-oriented metadata queries and does not build, update profiles or write lock files. archive_list lists members without extraction.

Preferred CLI and fallback behavior

The MCP API is independent of which CLI is installed. Backends are package-owned constants; model input never chooses an executable or flags.

Current preference chains include:

Capability Preferred Fallback
text search rg grep
file discovery fd find
tree view eza find
disk hotspots dust du
process list procs ps
checksum b3sum sha256sum, then shasum -a 256
JSON native parser -
structured data fixed yq where required native JSON/TOML parser where supported

If no safe equivalent backend exists, the tool returns unsupported_capability. The MCP never installs missing software automatically. A fallback is rejected when it cannot preserve the requested security policy; for example, a grep fallback will not silently ignore a configured exclusion it cannot safely represent.

Runtime configuration

Runtime configuration normally lives at:

~/.config/remote-observer-mcp/config.toml

or at the path selected by REMOTE_OBSERVER_CONFIG. The gateway runbook uses /etc/remote-observer-mcp/config.toml.

Start from config.example.toml. Do not store passwords, API keys, SSH private keys or other credentials in this TOML file.

Example:

[hosts.gateway]
transport = "local"

[hosts.remote]
transport = "ssh"
ssh_alias = "example-host"
gpu = true

[hosts.remote.services.app]
unit = "app.service"
logs = false

[hosts.remote.containers.api]
name = "api"
logs = false

[hosts.remote.repos.app]
path = "/srv/app"
secret_patterns = ["private/**"]

[workspaces.app]
host = "remote"
root = "/srv/app"
secret_patterns = ["private/**"]
compose = false

The v1 identifier/path grammars are deliberately narrow. Add legitimate unsupported naming conventions through a reviewed schema change instead of bypassing validation.

Development and deterministic verification

Requirements: Python 3.12.

python -m pip install -e '.[dev]'
python -m ruff check .
python -m pytest -q
python scripts/smoke_stdio.py

The deterministic suite does not require real SSH hosts, credentials, Docker, systemd, NVIDIA hardware, modern CLI installations, Secure MCP Tunnel access, a GitHub Environment, or a self-hosted runner. Observer/backend tests use fake transports where appropriate. scripts/smoke_stdio.py performs a real MCP stdio initialize/list-tools/call exchange against a temporary local config.

Run the read-only MCP server

export REMOTE_OBSERVER_CONFIG="$HOME/.config/remote-observer-mcp/config.toml"
remote-observer-mcp

This command expects an MCP client on stdin/stdout. In production, tunnel-client spawns it as its stdio child; it is not a separate standalone daemon. See deploy/README.md.

Execution Bridge

Arbitrary or mutating work belongs to the separate approval-gated execution lane, not to MCP.

Execution requests are versioned JSON documents. mode="argv" preserves an exact argument vector and runs without a local shell. mode="shell" is break-glass, always risk R4, and uses a fixed bash -lc implementation after approval. Requests are bounded, reject secret-like literals, resolve only registered hosts/workspaces, and produce a SHA-256 request digest plus sanitized execution evidence.

The executor entry point is:

remote-observer-exec <request_id>

The GitHub workflow accepts only request_id, validates the committed request on a hosted runner, then gates the self-hosted execution job itself on Environment remote-execution. No Issue body, comment, PR title, branch text, command, script, argv, host or path is accepted as executable workflow input.

All R1-R4 executions require the independent Environment approval in v1. See execution_requests/README.md and deploy/execution-runner.md.

Gateway deployment and production acceptance

The read-lane production supervisor is tunnel-client; it owns the stdio child lifecycle and systemd owns the tunnel-client process. The deployment sequence is:

  1. deterministic local MCP smoke;
  2. optional short gateway/tmux Tunnel smoke;
  3. managed gateway/systemd service;
  4. ChatGPT read-tool acceptance.

The Execution Bridge has a separate acceptance sequence for the GitHub Environment and self-hosted runner.

No real Tunnel, SSH, Environment approval or self-hosted execution is required by repository CI. USER_ACTIONS.md contains those remaining steps, including the no-extra-cost gate before account-backed Secure MCP Tunnel traffic.

Supported target assumptions

v1 system/service/Docker/Git/GPU observation is primarily designed for Linux targets. The gateway may be a Mac during development. SSH remote command serialization assumes a POSIX-compatible remote login shell; Windows remote targets are outside v1.

Validation status semantics

  • PASS: the stated command/check was actually run and passed.
  • FAIL: it was run and failed.
  • NOT RUN: intentionally not executed.
  • BLOCKED: a required user-controlled dependency/environment is unavailable.

Real SSH, Secure MCP Tunnel, GitHub remote-execution approval, self-hosted runner, and ChatGPT production acceptance remain NOT RUN until the steps in USER_ACTIONS.md are performed. Deterministic CI success must not be presented as production connectivity.

推荐服务器

Baidu Map

Baidu Map

百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。

官方
精选
JavaScript
Playwright MCP Server

Playwright MCP Server

一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。

官方
精选
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。

官方
精选
本地
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。

官方
精选
本地
TypeScript
VeyraX

VeyraX

一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。

官方
精选
本地
graphlit-mcp-server

graphlit-mcp-server

模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。

官方
精选
TypeScript
Kagi MCP Server

Kagi MCP Server

一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。

官方
精选
Python
e2b-mcp-server

e2b-mcp-server

使用 MCP 通过 e2b 运行代码。

官方
精选
Neon MCP Server

Neon MCP Server

用于与 Neon 管理 API 和数据库交互的 MCP 服务器

官方
精选
Exa MCP Server

Exa MCP Server

模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。

官方
精选