Skip to main content
Glama

use_item

Use a consumable item from cargo (Consumes an item for its effect. Repair kits restore hull, shield cells restore shields, fuel cells refuel, probes and enhancers grant temporary bonuses, defensive consumables counter ECM, tackle, missiles, or targeting, and power surge cells reset weapon cooldowns. Emergency warp devices jump to a random charted non-station POI in a nearby system. Quantity defaults to 1; instant repair, shield, and fuel effects accept multiple items. Buffs and power surges consume one. Works in battle and mid-flight, except emergency warp requires a real system.)

Input Schema

NameRequiredDescriptionDefault
item_idYesID of the consumable item to use (e.g., repair_kit, shield_cell, emergency_warp)
quantityNoNumber to consume (default 1). For repair/shield items, using more restores more. For buffs, only 1 is consumed.
session_idYesYour session ID from login/register

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only give readOnlyHint=false. The description adds substantial behavioral context: consumable is destroyed (consumption), quantity rules per item type, works in battle/mid-flight, and the emergency warp caveat requiring a real system. Doesn't cover failure cases (e.g. no item in cargo) but is well beyond the annotation bar.

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 purpose sentence, then a density of useful detail in well-structured clauses. Slightly long, but every clause about item effects and quantity rules earns its place and is easy to scan.

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?

No output schema, but the description covers what each consumable does, quantity behavior, and environment constraints. Missing: what happens if the item is absent/insufficient (error), and whether the item must be in the active ship's cargo specifically. Still more than adequate for a 3-param mutation tool.

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 coverage is 100%, so baseline 3 applies. The description's quantity rules (multiple accepted for repair/shield/fuel, one for buffs/power surges) reinforce the schema but add little that the schema's own description doesn't already say about quantity semantics.

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+resource ('Use a consumable item from cargo') and enumerates the item categories and their effects, distinguishing it clearly from sibling tools like repair, refuel, reload, which perform base operations rather than consumables. An agent can tell exactly what this does without opening the 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?

Explains per-item behavior (quantity handling for repair/shield vs buffs/power surges) and the battle/mid-flight applicability, plus the emergency-warp exception. It implies when to pick each type but does not compare against alternative routes like repair/refuel/refit which could achieve similar outcomes.

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