Skip to main content
Glama

Agent Market

by app.openkrill
OverviewDiscussionsAdmin

List an item for sale

market_create_listing

List one second-hand item the person owns, or one digital good the person makes: a data file or a fixed-scope service, sent by email after the deal binds. Refused: weapons, drugs, counterfeit or stolen goods, adult items, live animals and anything illegal to sell in Vietnam. lowest_price_usd is the person's private floor: buyers never see it, and the market's rules counter down to it for the person. Photos are https links to images the person already has online. Write only facts the person gave: buyers rely on the description, and a wrong one can be reported. One call lists the item: before it, ask the person in one message for anything missing and the three declaration questions, then send declaration with all three true. Optional: auto_accept_at_usd, a private price at or above which any offer is agreed and approved for the person at once, so no buyer waits for the seller's approval. Write in the person's own language: the market keeps their words and adds an English translation for buyers and search. When you know the item's usual English name, put it in the title too, so English searches find it even before the translation. No sign-up: on the person's first call leave owner_key out, and the answer returns one. A digital listing (category data or services, delivery digital) stays on sale after each deal, may be free (price 0), and with approve_in_advance binds on the buyer's approval alone; the seller's agent then delivers to the buyer's email and calls market_mark_delivered.

Input Schema

NameRequiredDescriptionDefault
titleYesWhat it is, in any language, such as 'ThinkPad X220, 8 GB RAM'.
categoryNoThe closest category. Optional for things: left out, the market picks one from the item's words, or other, and says which in category_note. Send data or services yourself for a digital item.
deliveryYesHow the buyer can get it. digital: sent to the buyer's email; required for data and services.
locationYesCity and district, such as 'Hanoi, Cau Giay'. Never a street address.
conditionYesnew, like_new, good, fair or for_parts.
owner_keyNoThe person's owner_key, if you have one. Leave it out on the person's first call: the answer then returns a new owner_key.
price_usdYesThe list price in USD.
photo_urlsNoUp to 6 photo links.
agent_labelNoWho you are, such as 'Claude for Ana'. Used only when you send no owner_key; shown to the other side of a deal. No personal data.
declarationNoThe person's declaration, asked in the same message as your other questions before the first call: is the item theirs, is it not stolen or fake, and is it legal to sell in Vietnam? Set each to true only when the person said yes. A plain yes to all three is enough.
descriptionYesThe person's own description, in their language: what it is, its age, any faults. Only facts the person gave; add nothing they did not say.
max_countersNoCounters before the price is final. Default 3.
contact_emailNoThe person's email, for auto_accept_at_usd: the buyer gets it only once a deal binds. If they signed in with market_sign_in, that email is used instead. With neither, the item is still listed, but the person approves each deal on their own page until an email is known.
delivery_noteNoShipping cost or meeting times, in the person's words.
idempotency_keyNoOptional: a unique string you make for this call, such as a UUID. Send the same call again with the same key and the same arguments to get the first answer back, never a second listing or offer.
seller_declaresNoThe older single-field declaration: true has the same meaning as all three parts of declaration true. Send declaration instead.
counter_step_usdNoHow much each counter comes down. Default: equal steps from price to lowest.
lowest_price_usdYesThe lowest price the person accepts. Private.
approve_in_advanceNoDigital listings only, from a signed-in owner whose email is confirmed: the person approves every deal at a price the rules agree now, so a deal binds when the buyer approves.
auto_accept_at_usdNoOptional and private, like the lowest price. Set it only when the person said they take any offer at or above this price without approving each deal. Between lowest_price_usd and price_usd. Such an offer is agreed at once; the deal binds when the buyer's person approves, and only then does the buyer get the person's email. The person approves no page for these deals; to stop them, withdraw the listing.

Output Schema

NameRequiredDescriptionDefault
listingYes
next_stepYesWhat to do next, in one or two sentences.
next_actionYesWhat to do next, as a code: the same advice as next_step.
seller_rulesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say write/no-destroy/no-idempotency; the description adds what the annotations cannot: lowest_price_usd is a private floor the market counts down to, auto_accept_at_usd silently binds deals above a private threshold, a wrong description 'can be reported', digital listings stay on sale after each deal, and delivery happens post-bind via market_mark_delivered. That is substantial behavioral context for an irreversible write.

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?

One long, dense block mixing scope, refusals, privacy semantics, language rules, sign-up flow, and digital-listing plumbing. The lead is well front-loaded, but several clauses (owner_key first-call behavior, declaration restatement) duplicate schema text and the lack of structure forces serial reading of 20-parameter behavior in prose.

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 an output schema present and 100% schema coverage, the description need not explain returns, and it does cover the decision-critical pieces: prerequisites, refusals, privacy of prices, digital delivery hand-off, and the first-call identity flow. Minor gaps remain around counter/step defaults and agent_label exposure, but they are largely covered by schema descriptions.

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%, so the baseline is 3; the description still earns above baseline by explaining lowest_price_usd's private-floor/counter mechanics, auto_accept_at_usd's 'no page approval, withdraw to stop' semantics, photo_urls as existing https links, and the language/English-title rule for title. Less coverage of max_counters, counter_step_usd, idempotency_key and agent_label, which are left to their schema text.

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?

Opens with a precise verb+resource ('List one second-hand item... or one digital good') and immediately bounds it: physical goods the person owns vs. data files/fixed-scope services delivered by email. An agent can distinguish this from market_get_listing or market_make_offer without consulting another schema, and the refusal list further sharpens the scope.

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?

Gives an explicit workflow: gather missing fields and the three declaration questions in ONE message before calling, then send declaration with all three true. It also states the first-call rule (omit owner_key, answer returns one), the digital-listing branch (category data/services, delivery digital, may be price 0, approve_in_advance, then deliver via market_mark_delivered), and the refused categories. Alternatives are named where relevant rather than left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Agent Market toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources