Skip to main content
Glama

get_base

Read-onlyIdempotent

Get docked base details (You must be docked. Shows base services, fuel price, condition, and tourism appeal (dining_points and leisure_points), lifetime tourism_revenue, (use view_market for market prices). At pirate strongholds, pirate_recovery shows the next priority replacement hull, build status, and a one-hull material shopping list including immediate upkeep. quantity_missing excludes physical stock; quantity_to_supply also excludes inbound station freight. bid_price and bid_quantity describe the best current public station buy price and remaining quantity at that price. A shortage is not a promise of payment. Check view_market before acquiring supplies and sell into public station buy orders. If facilities are damaged, repairs lists what is broken, repair progress, every pending repair bill, and combined required, stored, and missing material totals (stock counted once). Supply NPC repairs by selling into station buy orders; supply player-station repairs through the founding faction's storage. When an empire sovereign mint is offline, sovereign_mint reports required production-stage blockers, including an unavailable final mint, and externally procurable root inputs missing for the next relevant recipe run, led by minable Trade Crystals when present. Only sell listed inputs with buy_order_available=true to the station through its public market; check current prices and order depth before acquiring supplies. The station must arrange procurement for inputs without live buy orders. Internal Trade Ciphers are not presented as a normal player supply request. When input prices limit replenishment, price_limits lists public station_buy_price and lowest_sell_price in credits per unit. price_limited can appear while existing stock or queued jobs still produce authenticators. The gap describes current public orders, not a private spending ceiling.)

Input 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.5/5.0
Behavior5/5

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

Although annotations already mark this as read-only and idempotent, the description adds substantial behavioral context: it discloses what fields are returned, clarifies counting semantics (e.g., 'quantity_missing excludes physical stock'), explains edge cases ('A shortage is not a promise of payment'), and describes repair and supply workflows. This goes far beyond the safety hints in annotations.

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 very long and heavily parenthetical, packing numerous sub-topics (tourism, pirate strongholds, repairs, sovereign mint, price limits) into a single dense paragraph. While much of the content is relevant, the lack of structure makes it harder to scan, and some points about market checking are repeated, reducing 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?

Given the tool’s complexity and the absence of an output schema, the description supplies thorough context: field meanings, data caveats, repair mechanics, sovereign mint behavior, and price-limit semantics. It provides enough detail for an agent to interpret the returned data and act appropriately.

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?

The only parameter is session_id, and its schema description coverage is 100%, so the schema already documents it fully. The description does not add any parameter-specific meaning beyond what the schema provides, which is the expected baseline when schema coverage is complete.

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 ('Get') and resource ('docked base details'), lists the concrete data returned (services, fuel price, condition, tourism appeal, etc.), and names a sibling alternative ('use view_market for market prices'). The scope is immediately clear and distinguishable from related tools.

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?

Explicitly states the prerequisite ('You must be docked'), gives a direct alternative for market prices ('use view_market for market prices'), and provides procedural guidance ('Check view_market before acquiring supplies', 'Only sell listed inputs with buy_order_available=true'). When and how to use this tool versus alternatives is clearly specified.

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