Skip to main content
Glama

mine

Mine resources from asteroids, ice fields, or gas clouds (Requires appropriate equipment: mining laser for asteroids, ice harvester for ice fields, gas harvester for gas clouds — keyed on the resource, not the POI type, so a gas cloud can hold ore a mining laser works. Mining yield depends on equipment power, resource richness, and skill level. get_poi and survey_system report supported_power, lock_minimum_stock and too_sparse per deposit, all computed for the hull you are flying: beam power above supported_power is capped rather than wasted, and a deposit below both a quarter of capacity and lock_minimum_stock cannot be worked at all (deposit_too_sparse). Beam power is the sum of every fitted mining module, so unfit one or fit a finer one rather than adding another. Deep core POIs are exempt from that cutoff and always work down to zero. Which deposit a cycle hits is a random draw weighted by each deposit's richness and, as your mining skill grows, by its rarity. A fitted extraction filter (filter_* modules) removes its ore from that draw entirely, so every cycle targets one of the remaining deposits instead — that raises your yield of what you do want rather than wasting the cycle. If a filter rejects every deposit you could work at that POI, the cycle returns the filtered no-yield shape and mines nothing.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYesYour session ID from login/register

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the single readOnlyHint=false annotation, the description discloses substantial behavioral detail: equipment keyed to resource rather than POI type, yield dependencies, beam power capping, sparse-deposit exclusion, deep core exemption, randomness in deposit selection, filter effects, and the no-yield result shape. This goes far beyond what annotations provide and prepares the agent for non-obvious outcomes.

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?

The core action is front-loaded in the first phrase, and the remainder is dense but purposeful: each clause explains a mechanic or edge case that materially affects whether mining succeeds or returns nothing. It is long and could be better organized, but no sentence is filler.

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

Completeness3/5

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

The description is remarkably thorough about mechanics, but because there is no output schema, it leaves the normal return shape unexplained; it only mentions the 'filtered no-yield shape.' It also never explicitly states how the target POI or ship is chosen given that session_id is the only parameter. For a complex action with minimal structured metadata, these are meaningful gaps.

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?

There is only one parameter, session_id, and the input schema already describes it fully. The description adds no parameter-specific meaning, but with 100% schema coverage this is acceptable. It does not clarify how the mining target is determined from session context, which would have been useful, but that is more of a contextual completeness concern than a parameter semantics failure.

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 opens with a specific verb and resource scope: 'Mine resources from asteroids, ice fields, or gas clouds.' This clearly distinguishes mining from nearby siblings like scan, survey_system, and attack. It identifies the action, the target types, and the resource-focused intent without ambiguity.

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?

The description gives explicit prerequisites: appropriate equipment per resource type, and references get_poi/survey_system for checking supported_power, lock_minimum_stock, and too_sparse. It also advises against adding more mining modules and clarifies when a deposit cannot be worked. It lacks a direct statement of when not to mine or which alternative tool to use instead, but the operational context is clear.

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