Skip to main content
Glama

scan

Scan a target, or sweep the area for cloaked ships when no target is given (target_id accepts a player ID, username, empire NPC ID, pirate NPC ID/name, wildlife creature ID, or intact-prize actor ID. Reveals information about the target ship by scanner power tier — pilot name, ship class, hull/shield, cloak status, faction (for ships), or species, role, danger, hull and the species lore entry (for creatures — scanning fauna always succeeds). Scanning an intact prize reveals physical hull information without exposing its hidden personnel complement or a boarding-strength estimate. Scanner power = scanner modules + integrated_scanner hull, scaled by your Scanning skill (1% per level) and any scanner buff, contested against the target's cloak strength plus separate sensor-dampener scan reduction. Cloaked targets are harder to scan. Player targets are notified when scanned. NPC, creature, and intact-prize actor IDs are visible in get_nearby results. Omit target_id to run an area sensor sweep: it contests your scanner against every cloaked ship at your location and identifies those whose total scan defense it exceeds — the only way to find an unknown cloaked ship. get_nearby shows an 'unknown signature' hint when a cloaked ship is near your sensor threshold. A charted POI ID (or station base ID) in your system as target_id runs a remote POI scan: it needs a ship scanner (sensor rating above 0) and contests every ship there (players, empire NPCs, pirates, and leviathans; never wildlife) at your sensor rating, or 10 less at a POI other than your own. The result carries poi_id, scan_power, contacts, npcs, pirates, and leviathans. A cloaked scanner is never named in the scan notice its target receives. Add mode=cargo with a player target_id to run a cargo scan. You must both be undocked at the same POI, and you must be able to see the target. It takes 3 ticks, and you can queue nothing else until it finishes. The target is notified when it starts. It fails (success false with a reason) if the target leaves your POI, docks, boards a carrier or cloaks beyond your sensors (target_left, target_lost), or if you leave (scanner_left). At the end, your scanner is contested against the target's stealth plus their Piracy, Smuggling and Stealth scan evasion. Any power above 0 returns mode cargo, scan_power, cargo (the get_cargo item list), cargo_used and cargo_capacity. It never reveals credits. Power 0 fails with reason evaded. From a ship with a fitted warp scrambler, a cargo scan also holds the target for 5 ticks: the 3 scan ticks plus 2 to act. The hold follows the toll hold rules (see trade_offer): it is a crime in empire space, it counts toward the once-per-360-ticks hold limit, and safe_passage, already_held or hold_cooldown refuse the scan. If the target's warp stabilization is at least your scramble power, the hold is cancelled but the scan runs (hold_cancelled true). A toll trade_offer with hold=true that you send while your scan hold stands continues it as a toll hold, with no second crime.)

Input Schema

NameRequiredDescriptionDefault
modeNoOptional. cargo runs a 3-tick cargo scan of a player undocked at your POI and returns their cargo, never credits. From a ship with a warp scrambler it also holds the target for 5 ticks, which is a crime in empire space like a toll hold.
target_idNoPlayer ID/username, NPC ID/name, wildlife creature ID, or intact-prize actor ID to scan. Prize actor IDs come from get_nearby. A charted POI ID (or station base ID) in your system runs a remote POI scan of every ship there; it needs a ship scanner and loses 10 power away from your own POI. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers.
session_idYesYour session ID from login/register

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "Optional. cargo runs a 3-tick cargo scan of a player undocked at your POI and returns their cargo, never credits. From a ship with a warp scrambler it also holds the target for 5 ticks, which is a crime in empire space like a toll hold.",
      +  "enum": [
      +    "cargo"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / target_id / description
      Previous value: -"Player ID/username, NPC ID/name, wildlife creature ID, or intact-prize actor ID to scan. Prize actor IDs come from get_nearby. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers."New value: +"Player ID/username, NPC ID/name, wildlife creature ID, or intact-prize actor ID to scan. Prize actor IDs come from get_nearby. A charted POI ID (or station base ID) in your system runs a remote POI scan of every ship there; it needs a ship scanner and loses 10 power away from your own POI. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers."
  3. Added
  4. Removed
  5. Changed1 schema field changed
    • changedInput schema / properties / target_id / description
      Previous value: -"ID/username of the player or NPC to scan. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers."New value: +"Player ID/username, NPC ID/name, wildlife creature ID, or intact-prize actor ID to scan. Prize actor IDs come from get_nearby. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers."
  6. Changed2 schema fields changed
    • changedInput schema / properties / target_id / description
      Previous value: -"Player ID to scan"New value: +"ID/username of the player or NPC to scan. Omit to run an area sensor sweep that reveals cloaked ships at your location your scanner out-powers."
    • changedInput schema / required
      Previous value: -[
      -  "session_id",
      -  "target_id"
      -]New value: +[
      +  "session_id"
      +]
  7. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With only readOnlyHint=false supplied in annotations, the description carries the full behavioral burden and does so extensively: it explains scanner contests, cloak interactions, target notifications, tick duration, crime consequences, hold limits, and failure reasons. It also describes what results are returned for cargo and POI scans despite there being no output schema.

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

Conciseness3/5

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

The description is front-loaded with the main scan behavior, but it is a very long, dense block with extensive parenthetical detail. Much of the detail is useful, yet the lack of structure and repetitive explanation of target types and cargo rules reduce conciseness.

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

Completeness5/5

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

For a complex tool with multiple modes, contested mechanics, notifications, crime effects, and no output schema, the description is complete enough for an agent to understand expected outcomes and failure modes. It even summarizes the result fields for POI and cargo scans.

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

Parameters3/5

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

Schema description coverage is 100%, so target_id and mode=cargo are already documented in the schema. The description repeats much of that information and adds mostly behavioral detail rather than new parameter-level semantics; baseline 3 is appropriate.

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?

The description states specific actions and resources: scanning a target, running an area sweep for cloaked ships, performing a remote POI scan, and using cargo mode. It clearly separates these behaviors and distinguishes them from related tools such as get_nearby.

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

Usage Guidelines5/5

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

It explicitly says when to omit target_id for an area sensor sweep and calls that the only way to find an unknown cloaked ship. It also gives precise conditions for cargo scans, POI scans, failure cases, and interactions with warp scramblers and toll holds.

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