Skip to content
Customer Docs

Managing Servers

The Servers surface is honest about the boundary: server metadata is current, panel-backed evidence is partial, and unwired mutation paths are unavailable or roadmap—not implied by a saved URL or a product tour.

Registering a server

Use the authenticated Servers surface to store a tenant-scoped Minecraft server record and its configuration metadata. You can record the address, edition, version, optional modpack link, optional panel link, and which tenant agents are assigned to the server. The record is configuration storage; it is not a connectivity test, health guarantee, or proof that an agent can operate the host.

Capability status

Server records and configuration

Current

Authorized tenant admins can register, edit, and remove a tenant-scoped server record: name, address, port, edition, version, links, and agent assignments. A saved panel URL is metadata, not proof of a working panel connection.

Read-only tenant context

Read-only

Support / RAG can answer from tenant-provided documents and configuration, and Code Reviewer can inspect candidate evidence without mutation. Read-only access never implies live panel telemetry or permission to change a server.

Panel-backed status and utilization

Partial

The console has a tenant-scoped status read path and can show the latest stored sample, including an explicit stale/unknown state. Panel-MCP read contracts and the sampler seam exist, but live external panel assembly and repeatable production evidence are not complete; a linked URL alone does not make this live.

Power actions, console, and crash-diff incidents

Unavailable

Start, stop, restart, live console tail, and an automatic crash-diff incident pipeline are not customer-available capabilities here. Their routes must fail honestly or show unavailable until a real effector, persistence, verification, and read-back path is wired.

Files, config mutation, SFTP, restore, and automatic modpack mutation

Unavailable

Do not use this page to promise file-tree reads/writes, remote SFTP delivery, backup restore, archive unpacking, or automatic CurseForge/Modrinth installation or updates. Those effectors are not wired for customer use.

Verified live panel operations and delivery

Roadmap

A future release can move bounded read/act operations, artifact delivery, restore, or pack workflows forward only after tenant ownership, credentials, trust, metering, real effectors, independent verification, rollback, and live read-back are proven.

Trust and evidence boundaries
  • Observe can inspect allowed evidence and report a current, stale, or unknown state.
  • Propose can describe a scoped remediation, evidence request, or candidate change without applying it.
  • Act requires a specific tenant-owned effector, the right role/trust scope, metering, audit, and independent verification. A button or route is not evidence that an external effect occurred.
What to expect from this page

Current and partial status labels may change as a released integration is independently verified. Roadmap items are product direction only; they are not an instruction to upload files, restore a world, change a modpack, run console commands, or power-cycle a server through an unwired route.


Next

Activity & Usage