Skip to main content
Glama

view_market

Read-onlyIdempotent

View the market at the current station (Without item_id: returns a compact summary (best prices, quantities) for all items — use category to filter (e.g. 'ore', 'commodity', 'module'). With item_id: returns full order book depth for that item. Accepts item_id or item name (e.g. 'Iron Ore'). Every response includes current_tick. Pass that value back as 'since' on a later call to poll for changes: the response then lists only items whose book changed since that tick (incremental:true), with emptied items shown carrying no orders. This is a stateless alternative to subscribe_market — no persistent connection needed. Re-baseline (call without 'since') after changing stations or if you get a 'stale_cursor' error. Fuel is excluded from incremental diffs, and so are items restricted by the station contraband policy. Your own faction's private Company Store orders already appear in the normal view alongside public ones, and can set the best price you are shown; other factions' are never visible. Set company_store:true to narrow the response to ONLY your faction's Company Store listings (requires faction membership).)

Input Schema

NameRequiredDescriptionDefault
sinceNoOptional: a prior current_tick. Returns only items whose book changed at or after that tick (incremental poll) instead of a full snapshot. Re-baseline (omit since) after changing stations or on a 'stale_cursor' error.
item_idNoOptional: filter to a specific item for full order book depth (e.g., iron_ore)
categoryNoOptional: filter summary by category (e.g., ore, commodity, weapon, module). Use without item_id.
session_idYesYour session ID from login/register
company_storeNoOptional: narrow the response to ONLY your faction's private Company Store listings. They already appear in the normal view alongside public orders; other factions' are never visible. Requires faction membership.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed1 schema field changed
    • changedInput schema / properties / company_store / description
      Previous value: -"Optional: show ONLY your faction's private Company Store listings (members-only buy/sell orders, hidden from non-members). Requires faction membership."New value: +"Optional: narrow the response to ONLY your faction's private Company Store listings. They already appear in the normal view alongside public orders; other factions' are never visible. Requires faction membership."
  4. Changed2 schema fields changed
    • addedInput schema / properties / company_store
      Added value: +{
      +  "description": "Optional: show ONLY your faction's private Company Store listings (members-only buy/sell orders, hidden from non-members). Requires faction membership.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / since
      Added value: +{
      +  "description": "Optional: a prior current_tick. Returns only items whose book changed at or after that tick (incremental poll) instead of a full snapshot. Re-baseline (omit since) after changing stations or on a 'stale_cursor' error.",
      +  "type": "integer"
      +}
  5. Changed2 schema fields changed
    • addedInput schema / properties / category
      Added value: +{
      +  "description": "Optional: filter summary by category (e.g., ore, commodity, weapon, module). Use without item_id.",
      +  "type": "string"
      +}
    • changedInput schema / properties / item_id / description
      Previous value: -"Optional: filter to a specific item (e.g., iron_ore)"New value: +"Optional: filter to a specific item for full order book depth (e.g., iron_ore)"
  6. Changed1 schema field changed
    • changedInput schema / properties / item_id / description
      Previous value: -"Optional: filter to a specific item (e.g., ore_iron)"New value: +"Optional: filter to a specific item (e.g., iron_ore)"
  7. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover readOnly/idempotent, but the description goes much further: it explains the incremental tick cursor, the stale_cursor failure mode, which records are excluded from diffs (fuel, contraband-restricted items), and which orders are visible by faction. This is exactly the behavioral context annotations cannot carry.

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 organized by mode, then by polling semantics, then visibility rules. It is dense but almost every sentence carries an actionable rule; the only cost is mild duplication of the per-parameter notes already in the schema.

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?

There is no output schema, and the description compensates by describing the response shapes: a compact best-price/quantity summary, full order-book depth, current_tick echoed back, incremental lists containing only changed items with emptied books shown without orders. An agent has everything needed to call and interpret it.

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, but the description adds real meaning beyond the schema: item_id also accepts an item name ('Iron Ore'), category is explicitly scoped to the no-item_id summary mode, and company_store requires faction membership. Some of this restates the schema, but the item-name acceptance and mode coupling are genuine additions.

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 opening sentence gives a specific verb+resource ('View the market at the current station') and immediately splits into two clearly differentiated modes (summary vs. full order book depth). It explicitly names the sibling it replaces ('stateless alternative to subscribe_market'), so an agent can route between them without opening either schema.

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?

States when to use each mode (no item_id = summary + category filter; with item_id = order book depth), names the alternative (subscribe_market), and gives concrete usage conditions including re-baselining after a station change or a 'stale_cursor' error and the faction-membership requirement for company_store.

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