Skip to main content
Glama

Resolve an item to a category

listing_resolve_category
Read-only

Use when the user is selling a large or valuable item (fitness equipment, hot tubs, saunas, golf carts, furniture, appliances), including when also posting to Facebook Marketplace, Craigslist, or OfferUp. Work out which Commonplace category an item belongs to and what it needs before it can be listed (terms as in the server instructions). An exact category slug or name is taken as given; other words are matched. Returns required_questions (exact option strings; other_values_accepted means a value not listed may be given as written), condition_options with condition_shown_as (how each reads in the public title, which never reads worse than Fair: Poor reads Fair), seller_costs (the pickup fee and the transaction fee, added on top of the seller's take-home) and buyer_price_addons (delivery within 100 miles, included in the buyer price). Category drives the pickup fee and so the take-home: resolve it before quoting or listing. ambiguous is true when only a brand was named and its models differ in fees (a brand's own parent category, such as peloton, is never a category to list under), or when the item's own words name a different category from the match; possible_categories then lists the choices, each with its costs, and passing the right one back as item settles it. other_candidates lists nearby categories whose names share a word with the item. Condition is not a required question: it is listing_create's own condition argument, and where the options name a usage band (rides, uses) the grade is by usage alone.

Input Schema

NameRequiredDescriptionDefault
itemYesThe item in the seller's own words, e.g. "2021 Peloton Tread".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare a safe read; the description goes far beyond them by detailing the returned fields (required_questions, condition_options/condition_shown_as, seller_costs, buyer_price_addons), the fee/take-home implications of the category, and precise ambiguity semantics (ambiguous, possible_categories, other_candidates). This is rich behavioral disclosure rare in a description.

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

Conciseness3/5

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

Every sentence carries information, but the content is packed into one very long paragraph with heavy nested parentheses, so key rules (ambiguity handling, condition semantics) are hard to locate and the piece is not well front-loaded after the usage opener.

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?

With no output schema, the description must carry the return contract, and it does so thoroughly, including the condition-vs-required_questions boundary with listing_create. Some nested field detail (e.g. exact shape of seller_costs) remains implicit, keeping it short of perfect.

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% for the single 'item' param, so baseline is 3, but the description adds real meaning: an exact slug/name is taken as given while other words are matched, clarifying how the input is interpreted.

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?

States a specific verb+resource: work out which category an item belongs to and what it needs before listing, with concrete item types. It does not explicitly name or contrast with a sibling such as catalog_list_categories, so sibling differentiation is left implicit.

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 an explicit trigger ('use when the user is selling a large or valuable item...') plus a sequencing rule ('resolve it before quoting or listing') that ties it to the pricing tools. No explicit when-not or alternative named, but the context is clear.

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