Skip to main content
Glama

loot_wreck

Loot items and modules from a wreck (If wreck_id is omitted while towing a wreck, defaults to your towed wreck. A wreck at another POI returns not_found, the same as a wreck that is gone. Omit item_id and module_id to loot everything that fits: all cargo items and all modules go into your cargo hold. To loot a specific cargo item: include item_id and optional quantity. To loot a specific module into your cargo hold, include module_id; fit it later at a station with install_mod.)

Input Schema

NameRequiredDescriptionDefault
item_idNoSpecific cargo item ID to loot. Omit to loot everything (all cargo and modules go to cargo hold).
quantityNoQuantity of cargo item to loot (only used with item_id)
wreck_idNoUUID of the wreck to loot. Omit when towing a wreck to default to your towed wreck.
module_idNoModule instance ID to loot into your cargo hold. Get module IDs from get_wrecks; fit it later at a station with install_mod.
session_idYesYour session ID from login/register

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed1 schema field changed
    • changedInput schema / properties / module_id / description
      Previous value: -"Module instance ID to loot directly onto your ship (requires free slot, CPU, and power). Get module IDs from get_wrecks. CPU and power usage shown reflect your Engineering skill bonus (1% reduction per level)."New value: +"Module instance ID to loot into your cargo hold. Get module IDs from get_wrecks; fit it later at a station with install_mod."
  4. Changed5 schema fields changed
    • changedInput schema / properties / item_id / description
      Previous value: -"ID of the item or module to loot"New value: +"Specific cargo item ID to loot. Omit to loot everything (all cargo and modules go to cargo hold)."
    • addedInput schema / properties / module_id
      Added value: +{
      +  "description": "Module instance ID to loot directly onto your ship (requires free slot, CPU, and power). Get module IDs from get_wrecks. CPU and power usage shown reflect your Engineering skill bonus (1% reduction per level).",
      +  "type": "string"
      +}
    • changedInput schema / properties / quantity / description
      Previous value: -"Quantity to loot (use 1 for modules)"New value: +"Quantity of cargo item to loot (only used with item_id)"
    • changedInput schema / properties / wreck_id / description
      Previous value: -"UUID of the wreck to loot"New value: +"UUID of the wreck to loot. Omit when towing a wreck to default to your towed wreck."
    • changedInput schema / required
      Previous value: -[
      -  "session_id",
      -  "wreck_id",
      -  "item_id",
      -  "quantity"
      -]New value: +[
      +  "session_id"
      +]
  5. First observed

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation only declares readOnlyHint=false, and the description is consistent with that mutation. Beyond the annotation it discloses non-obvious behavior: wreck_id defaults to the towed wreck, wrecks at another POI return not_found indistinguishably from a gone wreck, and everything looted lands in the cargo hold pending later install_mod. It does not mention cargo-capacity limits or permissions, but the behavioral picture is substantially richer than the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the verb and resource, then the operating modes in a compact single block with no filler sentences. The nested parenthetical is dense and slightly run-on, which costs a little readability, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation with no output schema and only a bare readOnlyHint annotation, the description covers default resolution, error behavior, and both loot modes adequately. The main gap is that it never says what the call returns (e.g., confirmation of items moved or a full-cargo condition), which would matter for an agent verifying success.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the per-field baseline is 3, but the description adds inter-parameter semantics the schema does not: quantity is only meaningful with item_id, module_id routes into the cargo hold rather than being fitted, and omitting all of item_id/module_id changes the call into a loot-everything operation. This clarifies combinations rather than repeating field docs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Loot items and modules from a wreck') and immediately delimits scope with the default-wreck behavior and the item-vs-module modes. It also names the sibling install_mod for the follow-up fitting step, so an agent can position it among loot/tow/scrap wreck tools without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete selection rules: omit both item_id and module_id to loot everything, include item_id (+quantity) for a specific cargo item, include module_id to move a module to cargo hold. It also documents the omitted-wreck_id default while towing. It stops short of saying when NOT to use it (e.g., versus salvage/scrap alternatives), but the routing is otherwise explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources