MCSManager Controller#

Use this skill to operate an MCSManager instance safely and consistently.

Scope and safety#

• Use only configuration the user explicitly provides in the prompt, session context, or a config file intentionally created for this skill.
• Do not assume a specific host, home directory, panel URL, token, or instance UUID.
• Do not search unrelated workspace files for secrets.
• Do not infer credentials from random local files.
• If required config is missing, ask for it.

Quick workflow#

1. Confirm the target instance.
   • Use the instance identifier the user provided.
   • If a dedicated skill config file exists and the user set it up for this skill, use its default instance value.
2. Prefer read-only checks first.
   • Check whether MCSManager is reachable.
   • Check whether the instance is online before restarting anything.
   • Read logs before making changes.
3. Only then perform state changes.
   • Start, stop, restart, kill, or send commands.
4. Report back clearly.
   • Say what was checked.
   • Say what changed.
   • Include the important log line or symptom.
   • If something is broken, say the broken thing directly.

Operating rules#

• Prefer the API over brittle browser clicking.
• Prefer read-only actions before writes.
• Avoid restart spam. If a start or restart fails, inspect logs before retrying.
• Preserve exact console commands when sending them.
• For dangerous commands like stop, kill, or destructive plugin actions, confirm intent unless the user explicitly asked.
• If the API details are missing, read references/api-notes.md and adapt to the installed MCSManager version.
• If the user wants reusable local config, use config.json in this skill directory.
• If config.json does not exist, create it by copying config.example.json and filling in user-provided values.

Common tasks#

Check status#

Use when the user asks whether the server is up, lagging, or crashed.

• Verify MCSManager service reachability.
• Query the target instance state.
• If the API is unavailable and the user has provided host-side access details, fall back to host-side process and port checks.

Read logs#

Use when the user reports crashes, plugin errors, failed joins, or startup problems.

• Fetch recent instance logs.
• Prioritize Java exceptions, plugin stack traces, port bind errors, world corruption, and authentication issues.
• Quote the minimal log excerpt that explains the failure.

Send console commands#

Use for commands like whitelist changes, saves, broadcasts, plugin commands, or graceful shutdowns.

• Echo the exact command in the response.
• Prefer graceful commands before hard stop actions.
• For batch commands, serialize them and avoid flooding the panel.

Restart safely#

Use when the instance is stuck, plugins need reload-by-restart, or the user asks for a restart.

• Confirm the server is actually online first.
• If players may be connected, warn about impact when appropriate.
• Stop gracefully if possible.
• Start once.
• Re-check status and read the first meaningful startup lines.

Local config pattern#

Recommended setup:

• Commit config.example.json.
• Keep your real config.json untracked.
• Put per-server values in config.json.
• Treat config.json as user-managed local config, not something to discover by rummaging through unrelated files.

Reference file#

Read references/api-notes.md when you need request patterns, environment conventions, or fallback strategy.