Skip to main content
Glama

faction_query_trade_intel

Read-onlyIdempotent

Search your faction's market price database, or an allied faction's (Query by base_id or station_name; base_id accepts either the station's Base ID or station POI ID. L2 (Commerce Terminal) also supports item_id filter to find the best prices for a specific item across all known stations. Auto-synced entries hold what view_market showed an online member docked there: other factions' private orders, fuel sell orders, and contraband that member could not trade are left out. Paginate with offset and limit (default 20, max 50). Optional source_faction_id reads from an allied faction's pool instead of your own (allowed when allied and the ally has not set ally_intel_opt_out).)

Input Schema

NameRequiredDescriptionDefault
limitNoMax results (default 20, max 50)
offsetNoPagination offset
base_idNoFilter by station Base ID or station POI ID
item_idNoFilter by item ID (requires L2 Commerce Terminal)
session_idYesYour session ID from login/register
station_nameNoFilter by station name
source_faction_idNoOptional ally faction whose trade intel pool to read (defaults to own faction). Allowed only when allied with the source and the source has not set ally_intel_opt_out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed1 schema field changed
    • changedInput schema / properties / base_id / description
      Previous value: -"Filter by base/station ID"New value: +"Filter by station Base ID or station POI ID"
  4. Changed3 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Max results (default 20, max 50)",
      +  "maximum": 50,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "description": "Pagination offset",
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / source_faction_id
      Added value: +{
      +  "description": "Optional ally faction whose trade intel pool to read (defaults to own faction). Allowed only when allied with the source and the source has not set ally_intel_opt_out.",
      +  "type": "string"
      +}
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it explains what auto-synced entries contain and explicitly what is excluded (other factions' private orders, fuel sell orders, untradeable contraband), plus pagination defaults and the ally opt-out permission gate. This is exactly the behavioral context an agent needs.

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-loads the core operation before the parenthetical details, and every clause is informative. The nested parenthetical structure makes it dense, but there is little waste.

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?

For a 7-param, read-only, no-output-schema tool, it covers filtering, pagination, permission gates, and data exclusions. An agent has everything needed to call it correctly.

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?

With 100% schema coverage the baseline is 3, but the description adds genuine meaning: base_id accepts either Base ID or station POI ID, item_id requires L2, and source_faction_id's alliance/opt-out constraint. It clarifies ambiguities the schema leaves implicit.

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?

Names a specific verb and resource (search your faction's market price database / allied faction's) and scopes it precisely against the sibling submit/status tools. An agent can distinguish it from faction_query_intel and view_market without opening a 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?

Gives clear conditions: item_id filter requires L2 Commerce Terminal, source_faction_id works only when allied and the ally has not set ally_intel_opt_out. It states context but does not explicitly compare against faction_query_intel or say when not to use this tool.

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