Skip to main content
Glama
Bobjonesgood

x402nano

by Bobjonesgood
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

x402nano

Why x402nano

x402nano is machine-payable Polymarket market intelligence for AI agents and MCP clients. It provides free market discovery and pricing tools, plus paid read-only Market Brief and Market Delta tools for 0.05 USDC per call on Base mainnet.

It does not trade, place bets, custody funds, or provide financial advice. Buyer keys remain local to the caller and are never received or stored by x402nano.

Live service: https://x402nano.onrender.com

Public Market Watcher demo: https://x402nano-market-watcher.bobjonesgood.chatgpt.site

x402nano is an independent project and is not affiliated with x402nano.org or the Nano/XNO cryptocurrency. “nano” refers to the project’s small, pay-per-request intelligence scope. References to x402, Base, Polymarket, USDC, and MCP describe technical compatibility or public data sources and do not imply endorsement.

Related MCP server: polymarket-mcp

MCP Server

x402nano exposes a public, stateless MCP endpoint using the production Streamable HTTP transport:

https://x402nano.onrender.com/mcp

The remote server exposes free market discovery and pricing tools plus x402-protected 0.05 USDC Market Brief and Market Delta tools. Paid MCP calls use the official x402 MCP payment flow: the caller signs locally, the facilitator verifies and settles on Base, and x402nano never receives or stores a buyer private key.

The repository also retains the proven local stdio MCP server with conservative payment budgets. See mcp-server/README.md for both connection paths, unpaid verification, and client requirements. The standards-compliant remote server manifest is server.json.

Agent Quickstart

For a new MCP client or autonomous agent:

  1. Find io.github.Bobjonesgood/x402nano in the official MCP Registry.

  2. Connect to the Streamable HTTP remote: https://x402nano.onrender.com/mcp.

  3. List tools and confirm list_trending_markets, get_market_pricing, get_market_brief, and get_market_delta.

  4. Call list_trending_markets to choose a market slug.

  5. Call get_market_pricing to confirm Base mainnet pricing.

  6. Use an x402-aware MCP client for get_market_brief or get_market_delta.

Pricing and payment boundaries:

  • Free tools: list_trending_markets, get_market_pricing.

  • Paid tools: get_market_brief, get_market_delta.

  • Price: 0.05 USDC per paid tool call, 50000 atomic units.

  • Network: Base mainnet, eip155:8453.

  • Seller: 0x4cc3831eB479aCFb6D44631d4a30814508Cf52d3.

  • Buyer keys stay local to the caller. x402nano never receives or stores buyer private keys.

  • Outputs are read-only market intelligence, not trading, betting, or financial advice.

What You Are Buying

x402nano does not sell raw Polymarket data. It sells packaged, agent-ready market intelligence objects that save an agent from stitching together market metadata, current prices, movement history, scoring, receipt handling, and safety boundaries itself.

A paid market brief includes:

  • market identity, question, category, status, end date, and source URL

  • current leading outcome and implied probability

  • outcome pricing summary and top outcomes

  • volume, 24h volume, 7d volume, liquidity, and change context when available

  • 24h movement summary from public price history when available

  • resolution/source context and data-quality notes

  • descriptive scores for movement, attention, and data completeness

  • watch points for future agent checks

  • receipt metadata proving the paid unlock

  • no-advice boundaries

A paid market delta includes:

  • what changed since the caller-supplied since timestamp

  • leading outcome start/end probabilities when public history is available

  • absolute and relative probability change

  • direction, changed flag, repeat-check priority, and unusual-movement flag

  • current volume/liquidity context

  • trajectory points when available

  • data-quality notes explaining missing or nearest-point history

  • receipt metadata proving the paid unlock

  • no-advice boundaries

Representative paid brief response:

{
  "status": "unlocked",
  "receipt": {
    "id": "receipt-id-after-payment",
    "amount": "0.05",
    "asset": "USDC",
    "network": "eip155:8453"
  },
  "data": {
    "briefType": "read-only-market-intelligence",
    "market": {
      "slug": "example-polymarket-slug",
      "question": "Will example event happen in 2026?",
      "status": "active",
      "url": "https://polymarket.com/event/example"
    },
    "snapshot": {
      "generatedAt": "2026-06-29T12:00:00.000Z",
      "source": "polymarket:gamma",
      "leadingOutcome": "Yes",
      "leadingOutcomeImpliedProbability": "42.0%"
    },
    "metrics": {
      "volume24h": "17,260.91",
      "liquidity": "81,697.04"
    },
    "movement": {
      "window": "24h",
      "direction": "up",
      "absoluteChange": "0.032"
    },
    "scores": {
      "marketMovementScore": 61,
      "attentionScore": 72,
      "dataCompletenessScore": 100,
      "unusualMovementFlag": false
    },
    "watchPoints": [
      "Watch whether the leading outcome changes, flattens, or reverses over the next observation window."
    ],
    "boundaries": [
      "Read-only public market data summary.",
      "No trading execution.",
      "No custody of user funds.",
      "No buy/sell/bet recommendation."
    ]
  }
}

Representative paid delta response:

{
  "status": "unlocked",
  "receipt": {
    "id": "receipt-id-after-payment",
    "amount": "0.05",
    "asset": "USDC",
    "network": "eip155:8453"
  },
  "data": {
    "briefType": "read-only-market-delta",
    "market": {
      "slug": "example-polymarket-slug",
      "question": "Will example event happen in 2026?"
    },
    "window": {
      "since": "2026-06-29T11:00:00.000Z",
      "until": "2026-06-29T12:00:00.000Z"
    },
    "change": {
      "source": "polymarket:clob",
      "outcome": "Yes",
      "startProbability": 0.388,
      "endProbability": 0.42,
      "absoluteChange": "0.032",
      "relativeChange": "+8.2%",
      "direction": "up",
      "changed": true
    },
    "significance": {
      "repeatCheckPriority": "medium",
      "unusualMovementFlag": false,
      "summary": "The leading outcome moved up by 0.032 over the requested window."
    },
    "dataQuality": {
      "priceHistoryAvailable": true,
      "usedNearestHistoryPoint": false,
      "notes": [
        "Delta is computed from available public market data.",
        "This endpoint does not store caller state; clients provide the since timestamp."
      ]
    }
  }
}

Freshness and methodology:

  • Paid briefs and deltas are generated on request after a valid payment.

  • Public freshness metadata advertises an expected max age of 90 seconds, with paid content kept behind 402 until payment.

  • Brief movement uses the most recent public Polymarket data and 24h leading-outcome history when available.

  • Delta movement is computed from public Polymarket CLOB price history for the leading outcome token between the caller's since timestamp and the latest available point.

  • If exact history is unavailable, the response says so in dataQuality rather than pretending precision.

  • Scores are descriptive heuristics from movement size, volume, liquidity, and data availability. They are not predictions or recommendations.

Machine-payable market intelligence API for AI agents and bots.

x402nano serves read-only Polymarket market briefs behind an HTTP 402 payment flow. An agent requests a market brief, receives a payment challenge, retries with X-PAYMENT, and receives unlocked JSON plus a receipt.

This is market intelligence infrastructure, not trading advice.

Paid briefs include 24h market movement, volume/liquidity context, resolution context, watch points, and safe descriptive scores. They do not include trading execution, custody, betting advice, or buy/sell recommendations.

Live Endpoint

https://x402nano.onrender.com

Free discovery/trending endpoint:

GET https://x402nano.onrender.com/api/markets/trending

Paid market brief endpoint:

GET https://x402nano.onrender.com/api/markets/brief?slug=will-gideon-saar-be-the-next-prime-minister-of-israel

Paid market delta endpoint:

GET https://x402nano.onrender.com/api/markets/delta?slug=will-gideon-saar-be-the-next-prime-minister-of-israel&since=2026-06-15T12:00:00Z

Historical Mainnet Proofs

These are separate, owner-approved historical tests on Base mainnet. They demonstrate past paid unlocks; they are not instructions to make a payment.

Proof

Initiated by

Purchased resource

Price and network

Transaction

Current behavior

Direct core Market Brief

x402nano's dedicated local buyer script

GET /api/markets/brief?slug=...

0.05 USDC on Base mainnet (eip155:8453)

BaseScan · receipt f1ffa2f5cabf94c3

The core paid brief endpoint remains live; this transaction is historical.

Direct core Market Delta

x402nano's dedicated local buyer script

GET /api/markets/delta?slug=...&since=...

0.05 USDC on Base mainnet (eip155:8453)

BaseScan · receipt 75fe7c800fed47d4

The core paid delta endpoint remains live; this transaction is historical. See the proof note.

Market Watcher companion-client proof

An owner-approved controlled Market Watcher client

One x402nano Market Brief through the companion purchase flow

0.05 USDC on Base mainnet (eip155:8453)

BaseScan

Historical companion-client proof only. The public Market Watcher deployment remains mock-first, has real payments disabled, and has no buyer key.

The direct core proof runs verified the HTTP 402 challenge, locally signed payment retry, on-chain USDC settlement, receipt generation, and read-only JSON unlock. The seller wallet was 0x4cc3831eB479aCFb6D44631d4a30814508Cf52d3.

Proof references:

Direct core Market Brief transaction:
https://basescan.org/tx/0x54ba49a288a56d20046c25f4496bec405f2eefc05fe413cd511caf96227911b1

In-repo proof notes:
TRUST.md
ARCHITECTURE.md
LISTING_METADATA.md
DIRECT_DELTA_X402_PRODUCTION_UNLOCK_PROOF.md

Note: the local buyer script exited nonzero after the real unlock because the immediate post-payment buyer balance read was stale. Seller balance updated, receipt/events were recorded, and a later no-payment balance check confirmed the buyer moved from 1.00 to 0.95 USDC.

Buyer Flow

  1. Discover the API.

GET https://x402nano.onrender.com/.well-known/x402.json

  1. Request a paid market brief.

Invoke-WebRequest `
  -Uri "https://x402nano.onrender.com/api/markets/brief?slug=will-gideon-saar-be-the-next-prime-minister-of-israel" `
  -UseBasicParsing

  1. Expect 402 Payment Required.

The response includes payment requirements similar to:

{
  "error": "payment_required",
  "paymentRequirements": {
    "network": "eip155:8453",
    "asset": "USDC",
    "amount": "0.05",
    "payTo": "0x4cc3831eB479aCFb6D44631d4a30814508Cf52d3",
    "resource": "/api/markets/brief?slug=will-gideon-saar-be-the-next-prime-minister-of-israel"
  }
}

  1. Sign and send the x402 payment.

Use an x402-compatible client to sign the Base mainnet USDC payment, then retry the same request with:

X-PAYMENT: <signed-x402-payment>

  1. Receive the unlocked JSON.

Successful paid responses include a receipt and the market brief payload:

{
  "receipt": {
    "id": "f1ffa2f5cabf94c3",
    "network": "eip155:8453",
    "amount": "0.05",
    "asset": "USDC"
  },
  "data": {
    "briefType": "read-only-market-intelligence",
    "status": "ok",
    "market": {
      "slug": "will-gideon-saar-be-the-next-prime-minister-of-israel"
    },
    "movement": {
      "window": "24h",
      "direction": "flat",
      "trajectory": []
    },
    "metrics": {
      "volume24h": "17,260.91",
      "liquidity": "81,697.04"
    },
    "resolution": {
      "endDate": "2026-12-31T00:00:00Z"
    },
    "scores": {
      "marketMovementScore": 45,
      "attentionScore": 70,
      "dataCompletenessScore": 100,
      "unusualMovementFlag": false
    }
  }
}

Delta Briefs

Delta briefs are the repeat-use paid object for agent polling loops. A brief answers "what is this market right now?" A delta answers "what changed since the agent last checked?"

GET https://x402nano.onrender.com/api/markets/delta?slug=will-gideon-saar-be-the-next-prime-minister-of-israel&since=2026-06-15T12:00:00Z

Without payment, the route returns 402 Payment Required. With a valid X-PAYMENT retry, the response includes a receipt and read-only delta JSON:

{
  "status": "unlocked",
  "receipt": {
    "id": "receipt-id-after-payment",
    "network": "eip155:8453",
    "amount": "0.05",
    "asset": "USDC"
  },
  "data": {
    "briefType": "read-only-market-delta",
    "market": {
      "slug": "will-gideon-saar-be-the-next-prime-minister-of-israel"
    },
    "window": {
      "since": "2026-06-15T12:00:00.000Z",
      "until": "2026-06-15T18:30:00.000Z"
    },
    "change": {
      "available": true,
      "outcome": "Yes",
      "absoluteChange": "0.050",
      "relativeChange": "+11.9%",
      "direction": "up",
      "changed": true
    },
    "significance": {
      "repeatCheckPriority": "high",
      "unusualMovementFlag": true,
      "summary": "The leading outcome moved up by 0.050 over the requested window."
    }
  }
}

Delta briefs are descriptive market context for agents. They do not include trading execution, custody, betting advice, predictions, or buy/sell recommendations.

Example polling clients:

examples/delta-polling.js
examples/delta-polling.py

Both examples show the intended agent loop: inspect freshness metadata, request a delta, handle the 402, retry with an x402 payment from a caller-provided signing hook, parse the receipt and delta payload, then update since after a successful response.

Local Proof Command

Run these commands from the repository root after a normal clone.

Preflight only; this does not sign or send a payment:

$env:MAINNET_PAID_PATH="/api/markets/brief?slug=will-gideon-saar-be-the-next-prime-minister-of-israel"
$env:MAINNET_MAX_USDC="0.05"
$env:MAINNET_PAYMENT_ACK="PREFLIGHT_ONLY"
npm.cmd run agent:mainnet

Real payment example, only for a separately owner-approved test that intentionally sends one 0.05 USDC unlock:

$env:MAINNET_PAID_PATH="/api/markets/brief?slug=will-gideon-saar-be-the-next-prime-minister-of-israel"
$env:MAINNET_MAX_USDC="0.05"
$env:MAINNET_PAYMENT_ACK="PAY_REAL_0.05_USDC"
npm.cmd run agent:mainnet

Launch Ask

x402nano is looking for feedback from 20 AI agent, trading bot, and market-data builders.

What to check:

Would a machine-readable market brief be useful to your agent?
Is 0.05 USDC per brief the right shape for testing?
What fields would your bot need before paying for a brief?
Would you rather call this directly, through an SDK, or through another agent framework?

Positioning:

Stop scraping. Use a machine-payable API for market briefs.
0.05 USDC per read-only market brief on Base.
No account. No API key. HTTP 402 and X-PAYMENT.

Current Scope

In scope:

Polymarket public data
read-only market intelligence
free trending endpoint
paid market brief endpoint
paid market delta endpoint
HTTP 402 challenge
Base mainnet USDC unlock
receipt and proof

Out of scope for this launch:

trading advice
trade execution
Telegram bot
lead generation
x402 consulting
new product features before feedback

Development

npm.cmd install
npm.cmd run build

Core scripts:

npm.cmd run agent:mainnet
npm.cmd run wallet:mainnet:create
npm.cmd run build

License

This project is licensed under the MIT License.

Available Tools

4 tools
get_market_briefPurchase a market briefAInspect

Purchases one 0.05 USDC read-only structured prediction-market intelligence brief on Base.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesExact Polymarket market slug.

TDQS

A3.7/5.0
Behavior3/5

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

The description discloses the cost and read-only nature, but the term 'purchases' suggests a write transaction, potentially contradicting 'read-only'. It does not explain authentication requirements or return behavior. Without annotations, more clarity on side effects would improve 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 a single sentence of 11 words, conveying essential information (cost, platform, type) without superfluous content. It is well-structured and front-loaded.

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

Completeness3/5

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

Given one parameter and no output schema, the description explains the action and cost but lacks details on what is returned (the brief content), authentication needs, and post-purchase behavior. More context would improve completeness.

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?

The input schema provides 100% coverage for the single 'slug' parameter, including pattern and description. The tool description adds no additional meaning beyond the schema, so baseline score 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 it purchases a market brief, specifies the cost (0.05 USDC), indicates it is read-only and structured, and names the platform (Base). This distinguishes it from sibling tools like get_market_delta, get_market_pricing, and list_trending_markets.

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 use when a structured intelligence brief is needed for a specific slug, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites beyond the slug parameter.

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

get_market_deltaPurchase a market deltaAInspect

Purchases one 0.05 USDC read-only probability-change report for a market since an ISO 8601 UTC timestamp.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesExact Polymarket market slug.
sinceYesPrevious successful check time in ISO 8601 UTC format ending in Z.

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the tool involves a purchase (cost of 0.05 USDC) and is read-only. However, it does not elaborate on side effects (e.g., if purchase is refundable, rate limits, or whether multiple calls incur multiple charges).

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 concise sentence that front-loads the key action and resource. No unnecessary words.

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

Completeness3/5

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

Given no output schema and no annotations, the description explains the action and required inputs adequately but omits important context such as the format of the returned report, any limits on usage, and whether the cost is deducted from a balance. More detail would improve completeness.

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 coverage is 100%, so baseline is 3. The description does not add meaning beyond what the schema already provides for both parameters ('slug' and 'since'). The schema descriptions are already clear.

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 it purchases a read-only probability-change report for a market, specifying the cost (0.05 USDC) and the time filter (since an ISO 8601 UTC timestamp). This distinguishes it from siblings like get_market_brief (brief info) and get_market_pricing (pricing).

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 usage when a probability-change report since a timestamp is needed, but does not explicitly state when to use this tool versus alternatives or provide exclusions. No guidance on scenarios where this tool should not be used.

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

get_market_pricingGet x402nano pricingBInspect

Returns public pricing, network, freshness, and payment metadata without making a payment.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the tool is safe (no payment required) and returns data without side effects. However, it does not mention rate limits, caching, or whether the data is real-time.

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?

A single sentence that front-loads the key information. Every word adds value; no redundancy.

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

Completeness3/5

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

The description adequately covers what the tool returns for a no-input tool. However, it lacks details on the output format, error behavior, or rate limits. Given no output schema, more context would improve completeness.

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?

There are zero parameters, so the description does not need to add parameter semantics. Baseline 4 is appropriate since schema coverage is 100% and no parameters require explanation.

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?

The description clearly states the tool returns 'public pricing, network, freshness, and payment metadata,' specifying the output categories. It does not explicitly distinguish from siblings but the verb 'Returns' is specific enough for a tool with no inputs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs siblings like get_market_brief or get_market_delta. The phrase 'without making a payment' hints at a free use case but lacks explicit context or exclusions.

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.

  1. 4 tool updatesv1.0.0
    • First observedget_market_brief
    • First observedget_market_delta
    • First observedget_market_pricing
    • First observedlist_trending_markets
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool targets a distinct operation: market brief, probability delta, pricing metadata, and trending market listing. No ambiguity between tools.

Naming Consistency4/5

Mostly snake_case with verb_noun pattern, but mix of 'get_' and 'list_' prefix. Consistent within tool group except one deviation.

Tool Count5/5

4 tools are well-scoped for a read-only intelligence server, covering essential functions without redundancy.

Completeness4/5

Covers core read operations for prediction markets, but lacks search or individual market detail beyond brief. Minor gap.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Polymarket MCP Server

    traderalvin1
    A
    license
    B
    quality
    Not graded
    maintenance
    Enables AI agents to interact with the Polymarket prediction market platform to discover markets, analyze real-time pricing, and monitor public portfolio data. It provides comprehensive access to market analytics, implied probabilities, and order books through the Model Context Protocol.
    59
    37
    -

  • polymarket-mcp

    BrainDAO
    A
    license
    A
    quality
    B
    maintenance
    Enables AI agents to discover and analyze prediction markets, execute trades, and manage positions on Polymarket via the Model Context Protocol.
    7
    43
    19
    MIT

  • MCP Prediction Markets

    huntbuilds
    A
    license
    A
    quality
    D
    maintenance
    Provides search, trending, odds, arbitrage, and category browsing for prediction markets (Polymarket & Kalshi) via the Model Context Protocol, enabling AI agents to access live market data without API keys.
    5
    1
    MIT

Latest Blog Posts

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/Bobjonesgood/x402nano'

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