marketplace-mcp

Name: marketplace-mcp
Author: llmops-pro

by llmops-pro

Overview Schema Related Servers Score Discussions

TypeScript

Remote

marketplace-mcp

A NOSTR storefront for your LLM agent — speaks both dialects. MCP server that lets an agent create + update marketplace events on your behalf, in two dialects out of the box:

NIP-15 (kind:30017 stalls + kind:30018 products) for NIP-15-native clients (Plebeian Market, etc.).
Shopstr-modern (kind:30019 shop profile + kind:30402 NIP-99 classified listings) — what shopstr.store actually renders. Includes an automatic cache-POST so events appear on the storefront, not just on relays.

Seven tools, defense-in-depth safety, MIT licensed.

v0.2 — dual-dialect publisher. v0.1.x shipped NIP-15-only and the listings never appeared on shopstr.store because Shopstr is a Postgres-backed CMS that only renders events from its own DB (populated via POST /api/db/cache-event) and its cacheable-event allowlist excludes NIP-15 kinds. v0.2 adds the Shopstr-modern tools and the cache-POST hook so the storefront actually populates. NIP-15 tools left in place for non-Shopstr targets.

Why this server exists

Shopstr (the canonical Bitcoin-Lightning marketplace UI on NOSTR) is not a relay-reading Nostr client — it's a Next.js app with a Postgres cache. Its marketplace page renders products from its own DB, populated when clients POST signed events to /api/db/cache-event. The cacheable-event allowlist (in shopstr-eng/shopstr → utils/db/cache-event-policy.ts) excludes NIP-15 stall/product kinds; modern Shopstr uses kind:30019 (shop profile with merchants: [<pubkey>]) and kind:30402 (NIP-99 Classified Listings, all data in tags). Without a ["t","shopstr"] tag the listing won't surface; without at least one ["image",<url>] tag the card silently never renders.

marketplace-mcp v0.2 builds the right events, POSTs them to Shopstr's cache after the relay publish, and keeps the legacy NIP-15 tools intact for anyone targeting other clients.

Related MCP server: agent-commerce

What you can build with this

A self-driving Shopstr storefront — agent generates shop profile + product listings from a config file, republishes whenever metadata changes, drops fresh t-tag categories per product for discoverability. Same call publishes to relays AND mirrors to Shopstr's cache.
A sales-channel multiplexer — the same product events propagate to every NIP-15- or NIP-99-aware client (Shopstr, Plebeian Market, etc.) by virtue of being on shared relays. Pick your dialect per-tool; publish to both if your audience spans clients.
A listing-as-code workflow — version-control your product JSON in git; CI calls shopstr_create_or_update_product to deploy. Republish with the same id = idempotent update (parameterized-replaceable events).
Cross-server identity — pair with nostr-ops-mcp and nwc-mcp to wire identity + commerce. Same signer, same npub, three specialized tool surfaces.

The seven tools

Shopstr-modern (new in v0.2) — required for shopstr.store visibility

Tool	Kind	Purpose
`shopstr_create_or_update_shop`	30019	Publish the seller's shop profile (`name`, `about`, `picture`, `banner`). The `d` tag is the seller's pubkey hex — one shop per pubkey. After relay publish, POSTs to Shopstr's cache so the storefront UI surfaces the shop.
`shopstr_create_or_update_product`	30402	Publish a NIP-99 Classified Listing. All product data in tags (`title`, `summary`, `price`, `location`, `shipping`, `image` × N, `t` × N, `quantity`, `condition`, `status`, `valid_until`). Auto-adds `["t","shopstr"]` so the product surfaces in Shopstr's marketplace feed. Cache-POST included.

NIP-15 legacy — for NIP-15-native clients (not Shopstr)

Tool	Kind	Purpose
`marketplace_create_or_update_stall`	30017	NIP-15 stall (`id`, `name`, `description`, `currency`, `shipping[]`). The `id` is the `d` tag — same id = replace. Relay publish only; no Shopstr cache POST (would be 400'd anyway, kind not allowlisted).
`marketplace_create_or_update_product`	30018	NIP-15 product (`stall_id`, `name`, `description`, `images`, `price`, `quantity`, `specs`, `shipping`, `categories`). Relay publish only.

Common

Tool	Kind	Purpose
`marketplace_list_my_stalls`	—	Fetch + parse your own NIP-15 stalls. Returns event id, created_at, `d` tag, parsed JSON.
`marketplace_list_my_products`	—	Same for NIP-15 products. Optional `stall_id` filter (client-side; relays don't index JSON content).
`marketplace_confirm_publish`	—	Two-step confirm dispatcher. Routes by tool name so Shopstr-modern publishes re-attach the cache-POST hook automatically.

Requirements

Node 20+
A NOSTR signer — strongly preferred: a NIP-46 bunker URI from Amber, nsec.app, or any NIP-46 implementation. Dev path: raw nsec in .env.
Relays your audience reads from. Sensible defaults in .env.example (relay.damus.io, nos.lol, relay.nostr.band, relay.primal.net).
For Shopstr-modern publishes: outbound HTTPS to shopstr.store (or your own Shopstr deployment).

Install

# From npm
npx -y marketplace-mcp

# From source
git clone <repo>
cd marketplace-mcp
corepack enable pnpm
pnpm install
pnpm build

Configure

cp .env.example .env
# edit .env: set NOSTR_NIP46_URI OR NOSTR_PRIVATE_KEY
#           set NOSTR_RELAYS (comma-separated wss://)
#           set SHOPSTR_CACHE_ENABLED=true (default) for shopstr.store visibility

The server auto-loads .env from this binary's own directory (next to dist/) — deliberately NOT from cwd, to avoid env-var collision when multiple MCP servers run in the same Claude Code session.

Required

Var	Purpose
`NOSTR_RELAYS`	Comma-separated `wss://` relays. Server refuses to start if empty.

Signer — provide AT MOST one (without a signer the server runs read-only)

Var	Purpose
`NOSTR_NIP46_URI`	`bunker://...` URI. Recommended. Pair with Amber (Android) or nsec.app (web).
`NOSTR_PRIVATE_KEY`	Raw `nsec1...`. Dev/legacy only. Server warns at startup.

Shopstr cache mirror (new in v0.2)

shopstr.store reads from its own Postgres DB, not from open relays. After kind:30019/30402 events publish to relays, the server POSTs them to the configured cache URL so the storefront surfaces them. Failures are logged in the audit log but never roll back the relay publish (a Nostr event already broadcast can't be rolled back anyway).

Var	Default	Purpose
`SHOPSTR_CACHE_ENABLED`	unset (`false`) — set `true` in `.env` to enable	Controls whether the cache POST runs at all.
`SHOPSTR_CACHE_URL`	`https://shopstr.store/api/db/cache-event`	Override to mirror to a self-hosted Shopstr deployment.

The NIP-15 tools (kind:30017/30018) ignore these — those kinds aren't on Shopstr's cacheable allowlist anyway.

Optional safety knobs

Var	Default	Purpose
`NOSTR_READ_ONLY`	`false`	Disables all publish tools (list_my_* still work).
`NOSTR_REQUIRE_CONFIRM`	`false`	Two-step confirm — create/update returns a token; `marketplace_confirm_publish` actually broadcasts.
`NOSTR_MAX_EVENTS_PER_MINUTE`	`10`	Rolling 60s rate limit on publishes.
`NOSTR_LOG_PATH`	`./marketplace-mcp.log`	Server log.
`NOSTR_AUDIT_PATH`	`./marketplace-mcp-audit.log`	Append-only JSON-line audit log.

Quickstart: publish your first storefront on shopstr.store

1. agent: shopstr_create_or_update_shop({
     name: "My Shop",
     about: "Hand-crafted MCP servers and other Lightning-priced goods.",
     picture: "https://example.com/avatar.png",
     banner: "https://example.com/banner.png"
   })
   → returns { event_id, kind: 30019, relays_accepted: [...],
                after_publish: { shopstr_cache: { ok: true, status: 200 } } }

2. agent: shopstr_create_or_update_product({
     id: "some-product",
     name: "Some Product",
     summary: "Long-form description goes here. Becomes the event `content`.",
     price: 50000,
     currency: "sat",
     location: "online",
     shipping_option: "Free",
     shipping_cost: 0,
     images: ["https://example.com/card.jpg"],   // REQUIRED — Shopstr drops cards with zero images
     categories: ["software", "lightning", "mcp"]
   })
   → returns { event_id, kind: 30402, relays_accepted: [...],
                after_publish: { shopstr_cache: { ok: true, status: 200 } } }

Visit https://shopstr.store/marketplace/<your-npub> to see your storefront. (If you've registered a Shopstr profile slug for your npub, the URL canonicalises to /marketplace/<your-slug>.) Browsers buy through Shopstr's invoice-generation flow → sats land in the Lightning wallet linked to your Shopstr profile.

NIP-15 alternative (for non-Shopstr clients)

If you're targeting NIP-15-native clients instead of (or in addition to) Shopstr, the legacy tools still work:

agent: marketplace_create_or_update_stall({
  id: "my-shop", name: "My Shop",
  shipping: [{ id: "digital", name: "Digital", cost: 0 }]
})
agent: marketplace_create_or_update_product({
  id: "p1", stall_id: "my-shop", name: "Some Product",
  price: 50000, currency: "sat",
  shipping: [{ id: "digital", cost: 0 }]
})

You can publish both dialects for the same product to maximise client coverage; they don't collide.

Wire into an MCP client

{
  "mcpServers": {
    "marketplace": {
      "command": "npx",
      "args": ["-y", "marketplace-mcp"],
      "env": {}
    }
  }
}

Same .env-via-binary-dir pattern as the rest of the substrate — leave the env block empty in client config; secrets stay in marketplace-mcp/.env.

Safety model

The publish pipeline runs in this order, for both NIP-15 and Shopstr-modern tools:

NOSTR_READ_ONLY gate.
Signer presence — refuse if no signer.
RateLimiter — rolling events bucket (NOSTR_MAX_EVENTS_PER_MINUTE).
Confirm gate — if NOSTR_REQUIRE_CONFIRM=true, returns a token; marketplace_confirm_publish executes. The confirm dispatcher routes by tool name so Shopstr-modern publishes re-attach their cache-POST hook automatically.
Sign + publish via NDK.
afterPublish hook (Shopstr-modern only) — POST the signed event to SHOPSTR_CACHE_URL. Failures logged in audit (after_publish.shopstr_cache.{ok, status, error}) but never roll back the relay publish.
Audit log entry.

KindAllowlist is omitted because the kinds (30017/30018/30019/30402) are hard-coded in the tool implementations — there's no agent-supplied kind to validate.

If you want stricter behavior, pair with nostr-ops-mcp and use its kind allowlist on the same npub — but most users find that overhead unnecessary for a single-purpose marketplace server.

Testing

pnpm typecheck
pnpm test        # 19 vitest cases (NIP-15 builders/parsers + Shopstr-modern builders/parsers + roundtrips)
pnpm build       # ~37 KB ESM bundle

Companion servers

nwc-mcp — Lightning wallet. The "payment" side of selling.
nostr-ops-mcp — General NOSTR primitives. The marketplace MCP is the specialized cousin; nostr-ops-mcp is the generalist.
albyhub-admin-mcp — Hub-level admin via Alby Hub's HTTP API. The other half of the wallet story (NWC handles payments, this handles node/channel/sub-wallet ops).

License

MIT — see LICENSE.

Contact / Issues

Built by LLMOps.Pro.

NOSTR: npub1hdg932jvwc3jdvkqywgqv0ue4nn60exrf92asy8mtazt3hjg7d2s2yw0nw — follow, DM, zap.
Lightning Address: sovereigncitizens@getalby.com — for support zaps and "this was useful" tips.
Bug reports / feature requests: open a GitHub issue (link forthcoming).
Security issues: please disclose privately via NOSTR DM before opening a public issue.

Available Tools

7 tools

marketplace_confirm_publishA

Execute a previously-prepared marketplace publish, identified by its one-time token. Only meaningful when NOSTR_REQUIRE_CONFIRM=true. Single-use token; the safety pipeline re-runs before signing. For Shopstr-modern tools (kind:30019/30402), the Shopstr cache POST hook is re-attached automatically.

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes	Confirmation token from a previous create_or_update_* call.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It reveals the safety pipeline re-runs before signing and automatic cache hook attachment for Shopstr-modern tools, giving good behavioral insight beyond the basic action.

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 sentences, no wasted words. The core action is front-loaded, and additional context follows naturally.

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?

Complete for a simple confirm action: explains what it does, when to use it, token handling, and special behavior for related tools. No missing information given the low complexity.

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?

Input schema has 100% coverage on the single 'token' parameter. Description reinforces it as one-time and single-use but does not add significantly beyond the schema. Baseline 3 is appropriate.

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 clearly states the tool executes a previously-prepared marketplace publish using a one-time token, distinguishing it from sibling tools that create/update or list items.

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?

Mentions the context when meaningful (NOSTR_REQUIRE_CONFIRM=true) and provides important usage notes (single-use token, safety pipeline re-runs). Could be more explicit about when not to use.

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

marketplace_create_or_update_productA

Create or update a NIP-15 product (kind:30018) within a stall. The stall_id must match an existing stall's id. The id is the product's parameterized-replaceable d-tag — republishing with the same id replaces it. categories are surfaced as t tags for discoverability. Runs the safety pipeline (read-only, signer, rate limit, optional confirm).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Stable product identifier — becomes the `d` tag. Republishing with the same id REPLACES the prior product.
`stall_id`	Yes	The `id` of the parent stall (kind:30017 d-tag). Establishes the product → stall relationship that Shopstr uses to group listings.
`name`	Yes	Product display name.
`description`	No
`images`	No	Product image URLs.
`currency`	No		sat
`price`	Yes	Price in the stall's currency.
`quantity`	No	Available units. Omit for unlimited (digital goods).
`specs`	No	Key/value spec pairs (e.g. `[["License", "MIT"], ["Format", "npm package"]]`).
`shipping`	No
`categories`	No	Free-form category tags (added as `t` tags on the event). Lowercase recommended (e.g. ["software", "lightning"]).

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It mentions safety pipeline (read-only, signer, rate limit, confirm) and upsert behavior (republishing replaces). It does not detail failure modes or permissions, but the upsert and safety pipeline disclosure is adequate.

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?

The description is four sentences, front-loaded with the core action, and every sentence adds meaningful information. No redundant or vague statements.

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?

Given the tool's complexity (11 params, 4 required, no output schema), the description covers the essential aspects: purpose, idempotency, relationship constraints, and safety pipeline. It does not explain return values or error handling, but those are not explicitly required without an output schema.

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 73%, many parameters have descriptions. The description adds value by explaining id's role as d-tag, stall_id's relationship, and categories as t tags with lowercase recommendation. This enhances understanding beyond the schema.

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 clearly states the action (create or update), the resource (NIP-15 product kind:30018), and the context (within a stall). It distinguishes from sibling tools by specifying the NIP-15 standard and stall relationship.

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?

The description provides usage guidance: stall must exist (stall_id must match existing stall's id) and explains that republishing with same id replaces. It doesn't explicitly state when not to use, but the context and sibling tools make it clear.

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

marketplace_create_or_update_stallA

Create or update a NIP-15 marketplace stall (kind:30017). The id field is the parameterized-replaceable identifier — publishing with the same id replaces the prior stall on relays that honor replaceability. Shopstr is the canonical UI for these events. Runs the safety pipeline (read-only, signer, rate limit, optional confirm).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Stable identifier for this stall. Becomes the `d` tag — republishing with the same id REPLACES the prior stall (parameterized-replaceable). Use a UUID, slug, or any stable string.
`name`	Yes	Display name of the stall.
`description`	No	Long-form description (Markdown is fine for Shopstr).
`currency`	No	Currency code. Default `sat`. Shopstr also accepts ISO 4217 codes (USD, EUR, …).	sat
`shipping`	No	Shipping zones available from this stall.

TDQS

A4.2/5.0

Behavior4/5

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

Describes replaceability behavior via parameterized-replaceable identifier and mentions the safety pipeline (read-only, signer, rate limit, optional confirm). With no annotations, this provides adequate transparency for a mutation tool.

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 concise sentences: core purpose, replaceability detail, and UI/safety pipeline. No wasted words, front-loaded with essential information.

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 5-parameter tool with full schema coverage, the description covers replaceability and safety. No output schema is needed, but return values or errors are not mentioned. Sibling tools are distinct, so no confusion.

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%, so baseline is 3. The description adds minor value (e.g., 'id replaces prior stall', 'Shopstr also accepts ISO 4217') but does not significantly enhance understanding beyond schema.

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?

Clearly states 'Create or update a NIP-15 marketplace stall (kind:30017)', using specific verb and resource. Distinguishes from sibling tools like marketplace_create_or_update_product by focusing on stalls.

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?

Mentions Shopstr as canonical UI, implying usage context, but does not explicitly state when to use this tool versus alternatives like creating a product or listing stalls.

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

marketplace_list_my_productsA

Fetch + parse the current signer's NIP-15 products (kind:30018). Returns each product's event id, created_at, d tag, category t tags, and parsed JSON (name, description, price, currency, stall_id, etc.). Optionally filter by stall_id (applied client-side after fetch — NOSTR relays don't index the JSON content). Products with non-JSON or schema-invalid content are returned with parsed: null.

ParametersJSON Schema

Name	Required	Description	Default
`stall_id`	No	Optional stall id (the parent stall's d-tag). When set, only returns products whose parsed `stall_id` matches.
`limit`	No	Max events to fetch. Hard cap 500.

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: client-side filtering, return of parsed JSON fields, handling of invalid content (non-JSON or schema-invalid products return parsed: null). Also mentions fetch limit and hard cap.

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?

Description is concise, with three sentences covering purpose, filter behavior, and error handling. No redundant information; every sentence adds value.

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?

Given the complexity (NIP-15, client-side filtering, no output schema), the description adequately explains what the tool returns and how it handles edge cases. Does not cover authentication or rate limits, but these may be implicit for the current signer.

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?

Schema coverage is 100% but description adds significant value: explains that stall_id filter is applied client-side due to relay limitations, and that limit has a hard cap of 500. Also clarifies the behavior when content is invalid, which goes beyond the schema 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?

Explicitly states it fetches and parses the current signer's NIP-15 products (kind:30018) and lists the returned fields. Clearly distinguishes from sibling tools like marketplace_create_or_update_product or marketplace_list_my_stalls by focusing on listing products.

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?

Provides context for when to use, including the optional stall_id filter and its client-side limitation. Does not explicitly state when not to use or name alternatives, but the purpose is clear and the sibling tools are different functions.

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

marketplace_list_my_stallsA

Fetch + parse the current signer's NIP-15 stalls (kind:30017). For each stall event found on the configured relays, returns the event id, created_at, d tag, and the parsed stall JSON (name, description, currency, shipping). Stalls that don't pass the NIP-15 schema are returned with parsed: null so you can see what's wrong.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description discloses key behaviors: fetching from configured relays, parsing, and returning parsed or null for schema failures. It omits details like authentication requirements or error handling.

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?

Two sentences, front-loaded with purpose, efficient and no fluff.

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?

Given no output schema or annotations, the description is fairly complete, covering purpose, returns, and edge case. Could explicitly state that it only lists stalls for the authenticated user.

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?

No parameters exist; schema coverage is 100%. The description explains the tool's action and output, adding meaning beyond the empty schema. Baseline for zero parameters is 4.

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 clearly states that the tool fetches and parses NIP-15 stalls (kind:30017) for the current signer, specifying the returned fields and handling of invalid stalls. This distinguishes it from sibling tools like marketplace_list_my_products.

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?

The description implies when to use (to list stalls) but does not explicitly state when not to use or provide alternatives. Sibling tools exist but no direct comparison is made.

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

shopstr_create_or_update_productA

Create or update a Shopstr-compatible product as a NIP-99 Classified Listing (kind:30402). All product data lives in tags; summary is the event content. The d tag is the supplied id — republishing replaces the prior listing. After relay publish, POSTs to Shopstr's cache (SHOPSTR_CACHE_URL) so the storefront UI surfaces the product. Runs the safety pipeline (read-only, signer, rate limit, optional confirm).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Stable product identifier — becomes the `d` tag. Republishing with the same id REPLACES the prior product.
`name`	Yes	Product display name (becomes the `title` tag).
`summary`	No	Long-form product description. Goes into the event `content` AND a duplicated `summary` tag (Shopstr surfaces both).
`price`	Yes	Price as a number.
`currency`	No	Currency code. `sat` or ISO 4217.	sat
`location`	No	Optional location string. Shopstr renders this as the seller's region/city.
`shipping_option`	Yes	Shipping mode required by Shopstr: N/A, Free, Pickup, Free/Pickup, or Added Cost.
`shipping_cost`	No	Shipping cost. Required when shipping_option is `Added Cost`; ignored for `Free` / `N/A`.
`images`	No	Product image URLs.
`categories`	No	Category tags (added as `t` tags, lowercased). A `t=shopstr` tag is auto-added for Shopstr feed visibility.
`quantity`	No
`condition`	No	Product condition (e.g. New, Used, Refurbished). Free-form.
`status`	No	Listing status (e.g. active, sold).
`valid_until`	No	Optional expiration as unix-seconds.

TDQS

A4.2/5.0

Behavior4/5

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

Discloses key behavioral traits: product data in tags, summary as content, d-tag replacement, cache posting, and safety pipeline. With no annotations, this is adequate, though the safety pipeline could be more detailed.

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?

Concise and well-structured: a few sentences covering purpose, format, behavior, and pipeline without redundancy. Every sentence adds essential context.

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?

Covers overall workflow and key behaviors for 14 parameters, but lacks return value description (no output schema). Still fairly complete given the tool's complexity.

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?

Adds value beyond schema by explaining that summary goes into content and a summary tag, and categories are lowercased. Schema coverage is 93%, so most parameters are already described; these extra details enhance understanding.

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?

Clearly states it creates or updates a Shopstr-compatible product as a NIP-99 classified listing (kind:30402), differentiating from sibling tools like marketplace_create_or_update_product which likely target a different marketplace.

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?

Implies usage for Shopstr products but lacks explicit guidance on when to use this versus sibling tools like marketplace_create_or_update_product or shopstr_create_or_update_shop. The description focuses on behavior (e.g., id replaces prior listing) but not context-based selection.

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

shopstr_create_or_update_shopA

Create or update the seller's Shopstr shop profile (kind:30019). The d tag is the seller's pubkey hex — one shop per pubkey. After relay publish, POSTs the event to Shopstr's cache (SHOPSTR_CACHE_URL) so the storefront UI surfaces it. Runs the safety pipeline (read-only, signer, rate limit, optional confirm).

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Shop display name (the storefront header).
`about`	No	Long-form 'about this shop' copy.
`picture`	No	Shop avatar/picture URL.
`banner`	No	Shop banner image URL.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description fully discloses side effects: posting to Shopstr's cache after relay publish, running a safety pipeline (read-only, signer, rate limit, optional confirm), and the uniqueness constraint (one shop per pubkey). This exceeds expectations for transparency.

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?

The description is only four sentences, each adding essential information: purpose, key constraint, side effect, and safety pipeline. It is front-loaded and efficient with no redundant text.

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 mutation tool with no output schema, the description explains the implicit d tag (pubkey) and the cache posting side effect. It lacks details on error handling or update behavior, but overall is adequate for the complexity.

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?

All 4 parameters are described in the input schema (100% coverage), so the description adds minimal extra meaning. The baseline of 3 applies; the description does not compensate further.

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?

Description clearly states 'Create or update the seller's Shopstr shop profile (kind:30019)', specifying both the verb and the resource. It distinguishes from sibling tools like marketplace_create_or_update_stall or shopstr_create_or_update_product by focusing specifically on the shop profile.

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?

The description provides clear context for when to use the tool (creating/updating a shop) but does not explicitly state when not to use it or name alternative tools. The mention of a per-pubkey limitation ('one shop per pubkey') adds useful guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.2.3Jun 14, 2026
- First observedmarketplace_confirm_publish
- First observedmarketplace_create_or_update_product
- First observedmarketplace_create_or_update_stall
- First observedmarketplace_list_my_products
- First observedmarketplace_list_my_stalls
- First observedshopstr_create_or_update_product
- First observedshopstr_create_or_update_shop

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct resource or action: marketplace vs shopstr domains, products vs stalls vs shops, and a dedicated confirmation tool. The purpose of each tool is clearly differentiated.

Naming Consistency5/5

All tool names follow the pattern '<domain>_<action>_<resource>', with consistent verbs like create_or_update, list, and confirm. The prefix cleanly separates the two domains.

Tool Count5/5

Seven tools cover the essential operations for a marketplace seller: managing stalls and products for two protocols, listing them, and a confirmation step. No tool feels redundant or missing.

Completeness4/5

The tool surface covers create/update and reading for stalls and products across two protocols, plus a confirmation step. Missing deletion or archival tools, but the core workflows are well-covered.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

Marea — Storefront Backend for AgentsOAuth
com.mareaalcalina
Hosted storefront backend for AI agents: products, cart, Stripe + PayPal, delivery, order tracking.
E-commerce & Retail Payments & Billing
2
instxnt
io.github.EricSpencer00
Create instxnt.xyz storefronts through Claude: add products, connect Stripe, go live.
E-commerce & Retail Payments & Billing
2
Kifly — Agentic Commerce & Payments A
ai.kifly
Multi-seller shopping for AI agents. Settle via Stripe MPP or x402 USDC on Base. Hosted.
E-commerce & Retail Payments & Billing Cryptocurrency
212
Kifly — Agentic Commerce & Payments A
io.kifly
Multi-seller shopping for AI agents. Settle via Stripe MPP or x402 USDC on Base. Hosted.
E-commerce & Retail Payments & Billing Cryptocurrency
213

Related MCP Servers

listbee-mcpofficial
E-commerce & Retail Payments & Billing
listbee-dev
A
license
A
quality
B
maintenance
Enables AI agents to create and manage sellable listings, handle orders, and integrate Stripe payments through natural language using ListBee's API.
Updated 5 months ago (2026-04-21 20:46 UTC)
2
58
Apache 2.0
agent-commerce
E-commerce & Retail Payments & Billing Cryptocurrency
Kubudak90
A
license
Not graded
quality
B
maintenance
Enables an AI agent to act as a merchant, selling catalog items and issuing USDC invoices with cross-chain payment support via Arcorapay.
Updated 3 months ago (2026-06-18 13:48 UTC)
3
MIT
InventPay MCP Server
Cryptocurrency Payments & Billing E-commerce & Retail
jams24
A
license
A
quality
C
maintenance
Enables AI agents to manage crypto payments, stores, products, and orders through the Model Context Protocol.
Updated 10 days ago (2026-08-27 14:34 UTC)
20
223
MIT
Agentry MCP Server
cthulhutoo
A
license
Not graded
quality
F
maintenance
Provides a trust layer for AI agents with identity, reputation, payments, and discovery via 92 API endpoints as MCP tools, leveraging Nostr-native infrastructure.
Updated 5 months ago (2026-04-03 13:18 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/llmops-pro/marketplace-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

marketplace-mcp

Why this server exists

What you can build with this

The seven tools

Shopstr-modern (new in v0.2) — required for shopstr.store visibility

NIP-15 legacy — for NIP-15-native clients (not Shopstr)

Common

Requirements

Install

Configure

Required

Signer — provide AT MOST one (without a signer the server runs read-only)

Shopstr cache mirror (new in v0.2)

Optional safety knobs

Quickstart: publish your first storefront on shopstr.store

NIP-15 alternative (for non-Shopstr clients)

Wire into an MCP client

Safety model

Testing

Companion servers

License

Contact / Issues

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

listbee-mcpofficial

Latest Blog Posts

MCP directory API