Skip to main content
Glama

sell

Sell items at market price on the station exchange (No fees for instant fills. Items are taken from cargo first, then station storage. Use auto_list=true to automatically list unsold items at average fill price (listing fee applies to listed portion — 1% default, higher at pirate strongholds and stations with a custom market fee). Accepts item_id or item name (e.g. 'Iron Ore').)

Input Schema

NameRequiredDescriptionDefault
item_idYesID of the item to sell (e.g., iron_ore, steel_plate)
quantityYesQuantity to sell
auto_listNoIf true, automatically create a sell order for unsold items at the average fill price (1% listing fee applies).
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 / item_id / description
      Previous value: -"ID of the item to sell (e.g., ore_iron, refined_steel)"New value: +"ID of the item to sell (e.g., iron_ore, steel_plate)"
  4. First observed

TDQS

A4/5.0
Behavior5/5

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

With only readOnlyHint=false available, the description carries the load well: no fees for instant fills, items drawn from cargo first then station storage, the 1% default listing fee, and the fact the fee rises at pirate strongholds and custom-fee stations. These are material behavioral facts an agent could not infer from the annotations.

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 core action and scoped by parentheses, with no wasted sentences given the fee and source complexity. The nested parenthetical is dense but each clause conveys an actionable fact.

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 4-param mutation with no output schema, it covers fee economics, item sourcing order, and auto_list behavior thoroughly. It omits any prerequisite context such as needing to be docked and gives no hint about the return/confirmation, leaving a small gap.

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 baseline is 3, and the description adds real value by stating item_id accepts a name as well as an ID (e.g. 'Iron Ore'), which extends the schema's narrower 'ID of the item' wording. The auto_list explanation largely restates the schema but the fee detail backs it up.

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

Purpose4/5

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

States a specific verb+resource: 'Sell items at market price on the station exchange'. It also implicitly distinguishes the instant-fill mechanic from listing via create_sell_order by contrasting instant fills with the auto_list listing portion. It never names the sibling explicitly, so sibling differentiation is inferential rather than stated.

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

Usage Guidelines3/5

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

Usage is implied — sell at market price for instant fills — and auto_list=true is presented as the condition for also listing unsold items. However there is no explicit when-to-use versus create_sell_order or jettison, no prerequisites (e.g. needing to be docked), and no exclusions.

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