Skip to main content
Glama

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.

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?

Even with annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true), the description adds significant behavioral context: data is read live from each shop's shelf, results are always ordered alphabetically with no ranking or paid placement, `unreachable` names shops that refused, and format is verified by reading bytes rather than trusting filenames. No contradictions with 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?

The description is long but tightly packed with essential information. It front-loads the primary usage, then covers parameter behavior, ordering, edge cases, and the alternative tool in a logical sequence. Each sentence earns its place, though it could benefit from paragraph breaks for readability; it is not rambling or redundant.

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?

With 10 parameters and no output schema, the description fully compensates by explaining the response shape: surviving shops with sample rows, listing IDs, preview images, and format/size when digital. It also covers the narrowing of quarters and the `unreachable` behavior. This is complete enough for a complex tool, leaving no critical operational detail unexplained.

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?

While schema coverage is 100%, the description adds critical interaction semantics: passing predicates narrows the quarters, sizes match words and codes ('large' finds 'Black / L'), and format matching is only against proven formats. It also explains the `from` parameter's purpose. These details go well beyond the schema's simple field descriptions.

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 states a specific verb ('walk') and resource ('the market as a place'), and clearly explains the two modes: standing at the gate vs. walking into a row via predicates. It differentiates from sibling `concierge_ask` by explicitly pointing to it for full shelf details, and the metaphor makes it distinct from `market_search`. Purpose is unambiguous.

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?

Provides explicit usage guidance: call with nothing first to see quarters, then pass any listed predicates to walk into a row, or use `from` to find related shops. It names `concierge_ask` as the alternative for a shop's full shelf, and explains the narrowing behavior. This leaves no ambiguity about when and how to invoke.

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