Skip to main content
Glama

Compare CS2 marketplaces

compare_markets

Where one CS2 item is cheapest: lowest price (USD cents) and listing count on each marketplace, with a buy link where the market publishes one. Requires an Ultimate-tier API key. Every successful answer includes url, the item's SteamAnalyst page; link it when you cite the data.

Input Schema

NameRequiredDescriptionDefault
market_nameYesExact Steam market hash name, e.g. "AK-47 | Redline (Field-Tested)". Use search_items for loose names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the auth requirement (Ultimate-tier API key), the return shape (lowest price in USD cents, listing count per marketplace, buy link where available), and a mandatory `url` field with citation guidance. It lacks details on error behavior or rate limits, but covers the key behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three efficiently packed sentences, front-loaded with the core purpose and followed by prerequisite and output/citation guidance. Every sentence contributes useful information with no wasted wording.

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 single-parameter, no-output-schema read tool, the description covers purpose, auth, return fields, and a citation requirement. It stops short of explaining not-found behavior or result ordering, but is otherwise complete enough for correct invocation.

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 description coverage is 100%, and the schema already explains that `market_name` must be an exact Steam market hash name and to use search_items for loose names. The description adds only that it expects 'one CS2 item,' which is consistent but not substantially beyond the schema.

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?

The description clearly states the specific action and resource: comparing where one CS2 item is cheapest across marketplaces, returning lowest price and listing count. It distinguishes itself from siblings like get_price and price_history by emphasizing cross-market comparison, though it does not explicitly name those alternatives.

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 by 'Where one CS2 item is cheapest,' and the Ultimate-tier API key prerequisite is stated. However, there is no explicit guidance on when to use this versus get_price, price_history, or search_items, leaving the agent to infer selection criteria.

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