Skip to main content
Glama

Browse the market

market_walk
Read-onlyIdempotent

Walk the market as a place. Call it with NOTHING to stand at the gate and see which quarters exist — categories, storefronts, tags, kinds, sizes in stock and the price band across every listed shop, each with how many shops and items are in it. Then pass any of category/store/tag/kind/size/format/price_min_cents/price_max_cents to walk into a row: the surviving shops come back with live sample rows (each carrying its listing id, a preview image link you can show, and — for a digital file — the format PROVED by reading its bytes plus its size, which is often the ONLY thing telling two identically-titled rows apart), and the quarters NARROW to what is still open from where you now stand — so a thousand shops become the few worth asking. Pass from: <shop> instead to see who trades on that shop's row (shops sharing its categories and tags). Sizes understand words and codes alike ('large' finds 'Black / L'). Everything is read off each shop's own shelf at call time, ordered alphabetically always — nothing is ranked by us and no placement is for sale. unreachable names any shop whose shelf refused, so a shop that is missing is never confused with a shop that did not match. Then use concierge_ask on a shop for its full shelf and cited specs. THIS IS THE SHOPS' GROUND, NOT THE PLATFORM'S OWN CATALOGUE — for what the platform itself sells (plans, add-ons, subscriptions), call platform_catalog instead. AND WHEN SOMEONE ASKS VAGUELY WHAT IS FOR SALE, CALL THIS WITH NO ARGUMENTS FIRST: standing at the gate answers with the quarters that actually exist — the categories, storefronts, tags, kinds and price band — which is a real question to put back to them instead of guessing which corner they meant.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNonarrow by a flat tag, e.g. 'heavyweight'
fromNoinstead of predicates: a shop slug, to see who else trades on its row
kindNonarrow by kind: physical, digital or service
sizeNonarrow by size — a word or a code, 'large' and 'L' are the same question
storeNowalk one storefront within the shops, e.g. 'Merch'
formatNonarrow by file format, e.g. 'obj', '3mf', 'stl' — matched only against the format PROVED by reading the file, never a filename or a tag
categoryNowalk one category, e.g. 'T-Shirts' — from the gate's quarters
in_stockNodefault true — pass false to include sold-out rows in the walk
price_max_centsNodearest acceptable price, in minor units
price_min_centsNocheapest acceptable price, in minor units

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint, the description discloses live per-shop reads, alphabetical ordering, no ranking or paid placement, `unreachable` semantics for refused shelves, and format PROVED by reading bytes. These are meaningful behavioral traits not available in annotations or schema.

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?

The description is dense and front-loaded with the core mental model, and almost every sentence adds new information. It is somewhat verbose and repeats the gate/quarters concept and the quarter list, so it is not maximally concise.

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?

Despite having no output schema, the description covers the key return semantics: gate-level counts, live sample rows with listing id and preview image, narrowing quarters, and the `unreachable` field. It also tells agents what to do next with concierge_askto get full shelf details, making the tool practically complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial meaning beyond the schema: no arguments means 'stand at the gate', passing filters narrows both shops and quarters, `from` switches to a different walk mode, sizes treat words and codes as equivalent, and format is matched against proven bytes, not filenames. This is rich parameter-level guidance.

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 description uses a specific verb and resource ('walk the market as a place') and clearly distinguishes what a no-argument call returns versus a filtered walk. It also separates this tool from platform_catalog and points to concierge_ask, making sibling differentiation explicit.

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?

It gives explicit when-to-use guidance: call with no arguments first for vague 'what is for sale' queries, pass filters to narrow, pass `from` for related shops, and use platform_catalog for platform-owned items. Alternatives are named directly and the exact contextual trigger is spelled out.

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