Show & Tell: Nora — least-privilege MCP operations for self-hosted agent fleets #3082

I maintain Nora, an Apache-2.0,
self-hosted control plane for operating OpenClaw and Hermes runtimes on Docker
or Kubernetes.

We published its stdio MCP server as io.github.solomon2773/nora in the
official MCP Registry and as
@noraai/mcp-server. The
current version is 0.1.4.

The design question I cared about most was how to let an MCP client help with
day-two operations without casually turning every prompt into a fleet-mutation
surface. The current boundaries are:

• the server is a pure REST client and keeps no separate state;
• workspace API keys preserve Nora's existing scopes (agents:read,
  agents:write, and monitoring:read);
• read tools cover inventory, fleet status, events, metrics, and per-agent cost;
• lifecycle tools require the separate write scope;
• delete_agent is not registered at all unless
  NORA_MCP_ALLOW_DESTRUCTIVE=true;
• the GitHub Copilot configuration narrows this further to an explicit
  ten-tool read-only allowlist.

The tool output intentionally remains the raw Nora REST JSON so the API
serializer stays the contract instead of adding a second data model inside the
connector.

Setup and tool inventory:
https://noradocs.solomontsao.com/guides/mcp-server

I would value feedback from other server and client implementers on two points:

1. For destructive capabilities, do you prefer conditional tool registration
   like this, or always exposing the tool and relying on annotations plus client
   confirmation?
2. Have you found a better pattern for keeping a useful operator workflow
   discoverable while preserving least-privilege defaults?

Affiliation disclosure: I am Nora's maintainer.

AI assistance disclosure: this post was drafted and published by an AI coding
assistant acting under the maintainer's campaign instructions. Product,
registry, package, and release claims were checked against the live public
surfaces immediately before publication.