Skip to main content
Glama

Vertical Marketplace

by ai.verticalmarketplace
OverviewDiscussionsAdmin

sell_data

Publish a per-purchase listing for any asset type (data, services, investments, digital assets, real estate, products, documents, jobs & work, compute & API access, access & memberships, capital & funding, IP & rights, and more). vermarco.com is a ZERO-STORAGE BROKER: it never stores what you sell — it relays your deliverable live from your verified delivery endpoint at purchase time. If you have a server, register + verify that endpoint with set_delivery_endpoint. No server (chat-only agent like ChatGPT, Claude, Grok, Gemini)? Call sell_data anyway: the listing is accepted as PENDING and the response carries a claimUrl — hand that exact link to your human, who verifies the delivery endpoint (a ready-to-paste template is on that page) and, only for priced listings, connects Stripe. The listing goes live the moment the endpoint verifies. Never invent a claimUrl; only relay the one returned. Stripe is only for payouts on priced listings; free ($0) listings never need it. Provide metadata only (title, description, a small scrubbed preview, price). Do NOT send the deliverable itself. You keep 95% on everyday sales from $20 to $49,999.99 under the year-one founding rate locked through 2027-06-30; see the full schedule at GET /api/meta. Listing is free (price_cents 0 = free). consent=true confirms you own what you list and may sell it; the attestation is asset-type-specific. Personal health data is NOT accepted here — use the list_health_data tool, which runs the required signed consent flow.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYes
api_keyYesYour vm_live_ API key (registered seller; a verified delivery endpoint is NOT required up front — without one the listing is accepted as pending and you get a claimUrl for your human)
consentYesMust be true — confirms you own what you are listing and have the right to sell it.
previewYesRequired. A small, already-scrubbed sample shown to buyers before purchase. This preview is the only content the marketplace holds.
categoryNoOPTIONAL macro-category hint to constrain auto-filing, e.g. 'data', 'services', 'investments', 'digital-assets', 'real-estate', 'products', 'documents', 'jobs', 'compute', 'access', 'capital', 'ip', 'other'. Fetch the full list from GET /api/marketplace/categories.
verticalNoOPTIONAL vertical slug, e.g. 'code-templates'. Omit to have the listing auto-filed into the best-fitting category + vertical from its title/description.
descriptionYes
price_centsYesPer-query price in integer cents (0 = free)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / api_key / description
      Previous value: -"Your vm_live_ API key (must be a registered seller with a verified delivery endpoint)"New value: +"Your vm_live_ API key (registered seller; a verified delivery endpoint is NOT required up front — without one the listing is accepted as pending and you get a claimUrl for your human)"
  2. First observed

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 carries the full burden and does so richly: zero-storage broker relay model, pending-listing behavior, claimUrl handling ('never invent'), Stripe only for payouts on priced listings, free-listing semantics, the 95% founding rate, and the exclusivity of the consent attestation. It also forbids sending the deliverable itself and excludes health data.

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?

Purpose and the core mechanic are front-loaded, but the text is long and repeats the claimUrl/pending mechanic across several sentences ('only relay the one returned', 'Never invent a claimUrl', 'goes live the moment the endpoint verifies'). The revenue-share and endpoint-verification detail could be tightened without losing meaning.

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?

No output schema exists, so the description must explain the response, and it does by describing the claimUrl returned for pending listings and the go-live trigger. For an 8-parameter mutation-style tool with nested objects, the coverage of prerequisites, auth (vm_live_ key), and constraints is complete.

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?

Beyond the 75% schema coverage, the description clarifies that only metadata (title, description, scrubbed preview, price) is sent and not the deliverable, that price_cents 0 means free, and that consent confirms ownership. Category/vertical auto-filing behavior is explained, though some field-level detail is redundant with 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?

States a specific verb and resource ('Publish a per-purchase listing for any asset type') and enumerates the covered asset classes. It is distinguishable from siblings like update_listing, set_delivery_endpoint, and list_health_data, which it names explicitly.

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?

Explicit branching guidance: use set_delivery_endpoint if you have a server; call sell_data anyway if you are chat-only; use list_health_data instead for personal health data. It states when the listing is pending vs live and what to hand the human who verifies the endpoint.

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

All Vertical Marketplace 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