Skip to main content
Glama
jblaz6335

AI Data Marketplace

by jblaz6335
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

DopamineDesk x402 Marketplace MCP Server

Base Mainnet x402 Protocol x402scan Model Context Protocol npm Tests

Decision-ready machine-to-machine reports paid per request with the x402 Payment Protocol on Base Mainnet.

No API key. No account. No subscription. Buy one current answer in USDC when a workflow needs it. The catalog includes agent-readiness audits, vendor onboarding risk, transaction preflight, live x402 opportunity research, company intelligence, endpoint verification, website due diligence, VIN safety, market checks, security research, and atomic EVM reads.

Every billable route accepts ?preview=true. The preview is a live contract proof showing the source, freshness, required inputs, and response shape. It deliberately withholds the decision-ready values delivered by the paid call.

Start with the free find_marketplace_products MCP tool. Give it the buyer's task in plain language and it returns three ranked live products plus one recommended_purchase containing the exact price, required inputs, and ready preview and paid-call payloads. Replace the example inputs with the buyer's real values, preview when available, and only use the paid call after the user authorizes the listed price and payment method.

Buyer-ready outcomes

Product

What the paid call delivers

Price (USDC)

agent_readiness_audit

Scored evidence and prioritized repairs for the discovery files agents use to find, understand, and buy from a site

0.025

evm_receipt

Live transaction status, gas use, contract creation details, and normalized event logs across Base, Ethereum, or Arbitrum

0.003

evm_block_number

Current block height from a supported EVM network without maintaining an RPC integration

0.001

vendor_risk_report

Vendor onboarding decision with current identity, sanctions, domain, TLS, hosting, and website evidence

0.020

x402_market_opportunity_report

Live x402 demand, competition, health, pricing, and build recommendation

0.010

transaction_preflight

Read-only transaction simulation evidence before signing

0.005

company_intelligence

Company enrichment and vendor research brief

0.010

x402_endpoint_preflight

x402 endpoint verification, challenge linting, and buyer compatibility evidence

0.003

website_due_diligence

Website trust, security, metadata, and risk evidence in one report

0.040

vehicle_safety_report

VIN decode, recall, complaint, and buyer safety evidence

0.008

crypto_market_snapshot

Current multi-asset pricing and market context

0.004

These are complete paid deliverables, not teaser text. The lower-level catalog remains available for workflows that need a single chain read, filing, sanctions check, quote, or verification result.

If this open-source buyer adapter saves you integration work, you can support its maintenance on Ko-fi.

Related MCP server: hyperd-mcp

Install

npx -y dopaminedesk-ai-data-marketplace-mcp

Use it from any stdio-compatible MCP client:

{
  "mcpServers": {
    "dopaminedesk-data-marketplace": {
      "command": "npx",
      "args": ["-y", "dopaminedesk-ai-data-marketplace-mcp"]
    }
  }
}

Official MCP Registry name: io.github.jblaz6335/ai-data-marketplace.

Small tool list for existing agents

Set X402_TOOL_MODE=compact to expose just find_marketplace_products and purchase_marketplace_product. All live products remain available through those two tools. The default full mode keeps the product-specific tools for existing integrations.

No environment variable or wallet key is required to start the default server. A wallet is needed only if the buyer chooses locally signed auto-pay. The remote /mcp URL is a separate authenticated publisher integration, not the public stdio install URL.

Ready-to-copy configurations and a free end-to-end client check are in examples/README.md. The check discovers a real product and requests its free preview. It never signs or submits a payment.

Buy with credits instead of configuring a wallet

The service is already indexed in APIHub's external x402 catalog. Buyers with APIHub credits can ask its proxy to sign and settle a marketplace call without keeping a Base wallet or gas in the calling process:

npx @apihubio/cli register
npx @apihubio/cli topup 5
npx @apihubio/cli call https://ai-data-marketplace-1042299154756.us-central1.run.app/api/v1/evm_block_number

APIHub is an independent third party with its own account, credit, markup, and terms. Direct x402 remains the self-custody path. Both routes settle the protected endpoint before its paid result is delivered.

Inspect a live contract

curl "https://ai-data-marketplace-1042299154756.us-central1.run.app/api/v1/company_intelligence?preview=true&domain=example.com"

The proof includes source, freshness, request parameters, top-level fields, response shape, and a purchase block. Decision-ready values remain in the paid result.

Optional one-call purchasing

The current npm release can complete the x402 challenge, authorization, retry, and settlement automatically. Install the public package directly:

npx -y dopaminedesk-ai-data-marketplace-mcp

The buyer key stays inside the local MCP process and is never sent to the marketplace. Use a dedicated low-balance Base wallet, not a primary wallet.

{
  "mcpServers": {
    "dopaminedesk-data-marketplace": {
      "command": "npx",
      "args": ["-y", "dopaminedesk-ai-data-marketplace-mcp@2.11.3"],
      "env": {
        "X402_AUTO_PAY": "true",
        "X402_EVM_PRIVATE_KEY": "YOUR_DEDICATED_BUYER_WALLET_KEY",
        "X402_MAX_PAYMENT_USDC": "0.25"
      }
    }
  }
}

Call a product with auto_pay: true. The adapter refuses disabled, conflicting, invalid, or over-cap purchases. It never falls back to an uncapped payment.

For automated client installation, see llms-install.md. Its default configuration exposes free discovery and previews without collecting a wallet key or enabling automatic payment.

Verification and engineering scope

The public verification hub and machine verification record expose the production evidence.

I built this adapter around these constraints:

  • the production OpenAPI contract is the source of truth for tool discovery;

  • live contract proofs verify the source and schema without replacing the paid product;

  • automatic purchasing is opt-in, locally signed, and protected by a hard per-call cap;

  • conflicting, malformed, disabled, and over-cap payment attempts fail closed;

  • settlement details stay attached to the delivered result for reconciliation.

Run the verification suite locally:

npm ci
npm test

Production contracts

The MCP adapter builds its tool list from the production OpenAPI document. Counts, prices, availability, data mode, and source declarations come from the live contract instead of a hand-written endpoint list.

Every billable product uses x402 v2 exact payments on Base mainnet through the Coinbase CDP facilitator:

  1. Call the endpoint and read the base64 PAYMENT-REQUIRED response header.

  2. Sign the exact authorization with a compatible x402 buyer client.

  3. Retry with PAYMENT-SIGNATURE.

  4. Read settlement details from PAYMENT-RESPONSE.

See PAYMENT_FLOW.md for the manual and legacy confirmed-transaction paths.

Published distribution

License

MIT License. Open-source MCP buyer adapter and marketplace client.

Available Tools

2 tools
find_marketplace_productsA

Free discovery tool. Rank the live DopamineDesk x402 catalog against a plain-language buyer task before choosing or paying for a product.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesPlain-language task or desired outcome, such as "verify a vendor before onboarding" or "check a Base transaction receipt".

TDQS

A4.8/5.0
Behavior4/5

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

Since no annotations are provided, the description must convey behavioral traits. It states 'Free discovery tool' and 'before choosing or paying,' which strongly implies a read-only, non-destructive operation. However, it does not detail what happens after ranking or any potential side effects, leaving a slight gap.

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 a single, compact sentence that front-loads the key information ('Free discovery tool') and states the action and purpose without any redundant wording. It is efficient and easy to parse.

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?

Given the simplicity of the tool (one parameter, no output schema) and the presence of a sibling purchase tool, the description provides all necessary context. It explains what the tool does, when to use it, and what input is required, fully covering the use case.

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?

The single required parameter 'query' is well-defined with a clear description: 'Plain-language task or desired outcome, such as ...' This directly aligns with the tool's purpose and gives concrete examples, making the input unambiguous.

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's function: to rank the live DopamineDesk x402 catalog against a plain-language buyer task. It specifies the action (rank), resource (catalog), and context (before choosing or paying). This distinctly separates it from the sibling purchase tool.

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?

The description explicitly indicates when to use this tool: 'before choosing or paying for a product.' This implies it should precede the purchase_marketplace_product tool. The phrase 'Free discovery tool' also signals it is a low-risk, preliminary step.

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

purchase_marketplace_productA

Use after find_marketplace_products. Preview or purchase the selected paid product by its operation_id, without searching through the full dynamic tool list.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputsYesProduct-specific inputs returned in input_parameters or example_request by find_marketplace_products.
previewNoInspect the live contract proof before paying.
tx_hashNoBase transaction hash after paying an x402 invoice.
auto_payNoPay automatically with the locally configured, explicitly enabled buyer wallet.
payment_idNopayment_id returned by the x402 invoice.
agent_tokenNoOptional pre-funded marketplace bearer token.
operation_idYesExact operation_id returned by find_marketplace_products, such as evm_receipt or vendor_risk_report.
payment_signatureNoBase64 x402 v2 PAYMENT-SIGNATURE from a compatible buyer client.

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions previewing or purchasing and using operation_id, but it does not disclose the payment workflow, the requirement for a buyer wallet, the x402 invoice steps, or the fact that this tool may trigger a financial transaction. The schema hints at these behaviors (auto_pay, tx_hash, payment_signature), but the description itself is silent on the most consequential behavior: charging money.

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 the critical usage context ('Use after find_marketplace_products'). Every clause earns its place: the action, the resource, the key parameter, and the contrast with the sibling. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a payment-related tool with 8 parameters, nested inputs, and no output schema, yet the description provides almost no guidance on the overall flow: how preview differs from purchase, what inputs are expected, how to obtain tx_hash/payment_id, or what happens after payment. An agent would need to infer the payment protocol entirely from parameter names. The description is too sparse for the tool's 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning only to operation_id by explaining it comes from find_marketplace_products. It does not elaborate on the payment-related parameters (preview, auto_pay, tx_hash, payment_id, payment_signature) or how they interrelate, but the schema already documents each parameter individually.

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 ('Preview or purchase'), a clear resource ('selected paid product'), and the exact mechanism ('by its operation_id'). It also distinguishes itself from the sibling by noting it avoids searching the full dynamic tool list, so an agent can immediately tell this is the follow-up action after find_marketplace_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?

The description explicitly says 'Use after find_marketplace_products', which establishes the intended sequence and context. It also implies the alternative (find_marketplace_products) and clarifies that this tool is for the already-selected product. However, it does not explicitly state when NOT to use it, such as when the product has not been selected or when a different payment method is required.

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.

  1. 2 tool updatesv2.11.3
    • First observedfind_marketplace_products
    • First observedpurchase_marketplace_product
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one for discovery/search and one for purchasing. No overlap or confusion.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern ('find_marketplace_products' and 'purchase_marketplace_product'), with only a minor plural/singular difference that is contextually appropriate.

Tool Count3/5

With only two tools, the set feels minimal for a marketplace. While it covers the core discovery and purchase flow, it may be slightly thin for a full-featured marketplace, but it is not unreasonably sparse.

Completeness3/5

The tools cover the basic buyer journey (find and purchase), but lack other expected marketplace operations such as viewing product details, managing orders, or handling refunds. This leaves notable gaps for a complete marketplace experience.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Omni Service Node

    Luckkyyy23
    F
    license
    Not graded
    quality
    D
    maintenance
    56 pay-per-call MCP endpoints for AI agents. Market signals, macro economics, crypto/DeFi, geopolitical intelligence, SEC filings, GitHub velocity, sanctions screening. USDC on Base Mainnet via x402.
    -

  • CorteX402

    Ooak21
    A
    license
    A
    quality
    D
    maintenance
    Pay-per-call x402 data products on Base mainnet — sanctions screening, aviation weather, mortgage rates, US property dossier, title chain, wallet balance, and agent session auth. Every call settles in USDC with an on-chain receipt, no accounts or API keys.
    7
    34
    MIT