craft

Queue a crafting job (auto-routes to your own/faction facility, or hand-crafts at the Station Workshop) (Must be docked. Ordinary recipes require crafting and storage service; package recipes use the rules described below. Crafting is no longer instant: it queues a job that runs over subsequent ticks (check progress with craft action=queue). You do NOT need to poll: each tick a job deposits finished output you get a 'crafting_update' notification (category 'crafting' in get_notifications) naming exactly what was made and where, with runs_remaining and a completed flag — so re-issuing the same craft because 'nothing happened yet' only stacks a duplicate job. 'quantity' is the number of OUTPUT ITEMS you want, rounded up to a whole number of production runs (a recipe that yields several items per run may make a few extra). Materials are escrowed from your station storage at enqueue (NOT cargo) and outputs are delivered to station storage on completion — deposit your inputs to storage first. Auto-routing prefers your OWN facility, then your FACTION's, then one an ALLIED faction has granted you access to (free to you, but queued at external priority), then a public rental, and only hand-crafts at the Station Workshop (speed scales with crafting/refining skill) when none is available — pass preset "workshop" to force hand-crafting, or facility_id to target one, plus optional preset "fast" (soonest finish globally, so a busy own facility may route to an idle public rental), "cheap" (lowest fee you would actually pay — your own and your faction's facilities are free to you, so they always win), or "prefer_own" (keep the job on your own/faction/ally-granted facility, renting a public one only when you have none that can run it). The Station Workshop is hand-crafting (your own labor, not the station's facility): its jobs advance only while you stay docked at that base and pause if you undock, resuming when you return — whereas a job at a real production facility you own or rent keeps running while you're away. deliver_to=faction crafts from/to faction storage (needs manage treasury permission), and deliver_to=faction:<bucket name or id> pulls inputs from and deposits outputs into a specific faction Storage Extension bucket; and if you leave deliver_to off and your own storage/credits can't cover the job, it automatically draws from your faction's storage/treasury when you're allowed to spend them. Renting another player's public facility prepays a per-run fee. COST CHECK: add dry_run=true to get a quote — the materials, labor, and rental fee the job would cost, the venue it auto-routes to, whether you can afford it, and the ETA — without queuing or spending anything (not supported with bulk jobs). Use 'recycle' to reverse a recipe at a recycler. BULK: pass jobs=[{recipe_id, quantity, facility_id?, preset?, deliver_to?, source?, package_ids?, output_package_label?}, ...] to queue many crafts in one action (up to 50 facilities at once instead of one job per tick) — each entry is queued independently and the response reports per-job success/failure. Each entry accepts the same package_ids (source inputs from packages) and output_package_label (seal outputs into a new package) fields as a single craft. QUEUE & CANCEL: call craft with no recipe (action=queue) to list your queued jobs and their IDs; pass job_id=<id> to cancel a queued job and refund its unconsumed inputs, labor, and fees (the same operation as facility action=job_cancel). Pass job_ids=[id1,id2,...] to cancel several at once (per-job success/failure). PACKAGE INPUTS/OUTPUT: package_ids=[...] sources the craft's inputs from those packages (raw id or package:<id>) instead of loose storage — they must all sit in the source location and their pooled contents must equal the recipe inputs times quantity EXACTLY (no shortage or overage, no storage backfill), or it's rejected before anything is consumed. output_package_label="..." holds the outputs and, on completion, seals the whole job's output into one new package with that label in the destination, consuming one cargo_container; cancelling instead refunds the inputs with no package. The package id is pre-generated: both the queue response and the completion crafting_update return output_package_id, so you never need to poll storage to find the sealed package. Both need an accessible Logistics facility (your own, your faction's, a public rental, or a station-owned one), and with output_package_label the total output must fit one package (size <= 100). Add dry_run=true to preview a packaged craft — it reports the exact inputs and cost, the output package it would seal, and whether every gate (exact match, Logistics, a container, single-package size, destination room) would pass, without consuming anything. Not supported with bulk jobs. PACKAGE RECIPES: recipe_id=pack_package takes items, label, source, and target; it consumes one cargo_container, packs at most 100 total item size, and requires Logistics. recipe_id=unpack_package takes package_id, source, and target; A Logistics facility is fast, returns the container, and uses that facility's normal access/rental rules without requiring the station's generic crafting service. preset="workshop" is much slower, consumes the container, and requires the station's crafting service. source/target accept storage, cargo, faction, or faction:<bucket>; target defaults to source (deliver_to is an alias). Package jobs use this same queue and job_id cancellation.). 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.

craft accepts 12 parameters: jobs, count, items, label, action, job_id, preset, source, target, dry_run, job_ids, quantity. 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 craft: 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.

craft 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 craft 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 craft. 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.

craft 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.