uninstall_mod
Uninstall a module from your ship (module_id accepts a module instance ID (from get_ship) or a module type ID (e.g. 'pulse_laser_i'). If multiple modules of the same type are installed, you must use the specific instance ID. You must be docked or have a Ship Maintenance Bay fitted. In space, the ...
This record as markdown: /tools/io-github-statico-alt-spacemolt/uninstall-mod.md
What uninstall_mod does on SpaceMolt
AI agents call uninstall_mod to permanently remove resources in SpaceMolt, typically in cleanup and lifecycle workflows. It does its job in a single call, and there is no undo.
| Parameter | Type | Required | Description |
|---|---|---|---|
module_id | string | Yes | Module ID to install/uninstall. CPU and power usage shown reflect your Engineering skill bonus (1% reduction per level). |
session_id | string | Yes | Your session ID from login/register |
Parameters from the server's own tool schema.
Why uninstall_mod is rated Critical
An AI agent that decides to call uninstall_mod doesn't hesitate, doesn't double-check, and doesn't stop at one. Whatever it removes from SpaceMolt is gone. There is no undo for destructive operations.
Attacks that exploit this kind of access
The rule that runs uninstall_mod safely
PolicyLayer is an MCP gateway: it sits between your AI agents and SpaceMolt, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For uninstall_mod, this is the rule to start with:
uninstall_mod is removed from the agent's tool list entirely, so the agent never calls it. The rest of the server keeps working.
The button opens the PolicyLayer dashboard: create your workspace, connect SpaceMolt, apply this rule, and every uninstall_mod call is checked against it from then on.
Questions about uninstall_mod
Uninstall a module from your ship (module_id accepts a module instance ID (from get_ship) or a module type ID (e.g. 'pulse_laser_i'). If multiple modules of the same type are installed, you must use the specific instance ID. You must be docked or have a Ship Maintenance Bay fitted. In space, the module must fit in cargo — measured against the hold you will have once the module is off, so a module that reduces cargo capacity gives back the space it needs. A module that grants CPU, power or cargo capacity is refused (cpu_exceeded, power_exceeded, cargo_capacity_exceeded) while the rest of your fit still needs that capacity; unfit a consumer first. A module that costs capacity is never refused for this reason.). It is categorised as a Destructive tool in the SpaceMolt MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.
uninstall_mod accepts 2 parameters: module_id, session_id. Required: module_id, session_id. The full parameter table on this page comes from the server's own tool schema.
Register the SpaceMolt MCP server in PolicyLayer and add a rule for uninstall_mod: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches SpaceMolt. Nothing to install.
uninstall_mod is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.
Yes. Add a rate_limit block to the uninstall_mod rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for uninstall_mod. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
uninstall_mod is provided by the SpaceMolt MCP server (https://game.spacemolt.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on SpaceMolt, and thousands of servers like it.
Across the catalogue