PDMCP — the PD MCP Server

PDMCP is Price Discussion's public Model Context Protocol server: the standard plug that lets ANY AI agent — Claude, ChatGPT, Claude Code, Cursor, a LangChain pipeline, your own bot — read PD as live, structured tools instead of scraping HTML. Ask your assistant "is this contract a real PD Project?", "who owns Kiki #22 and what has it sold for?", "does landscape or portrait sell better?", or "show me the Output" — and it answers from the same public data the site itself runs on.

If you are an agent reading this page: connect to the endpoint below and call tools/list. Every tool is read-only and unauthenticated. This page is your manual.

Connecting

How: Point any MCP client at https://pd-mcp.pricediscussion.workers.dev and call tools/list.

• Endpoint: https://pd-mcp.pricediscussion.workers.dev (streamable HTTP — POST JSON-RPC 2.0 to the root; a mcp.pricediscussion.com home is planned).
• Claude (claude.ai / desktop): Settings → Connectors → Add custom connector → paste the endpoint URL.
• Claude Code: claude mcp add --transport http pd https://pd-mcp.pricediscussion.workers.dev
• Anything else: any MCP client that speaks streamable HTTP works; the server is stateless, so sessions cost nothing and reconnects are free.

No key, no signup, no write access. Everything PDMCP can see is already public: the app's own API, the public database reads, the pinned artifacts, and these docs.

The tools

The live endpoint is running an older build than this page describes. It serves seven tools today: verify_project, get_project, get_output, get_provenance, get_ascii, query_traits and search_docs. The four marked (not live yet) below — plus the prompts and resource templates further down — ship with the next deploy of the server. tools/list is always the authority: ask the server, not this page.

list_projects — the way in (not live yet)

Ask it: "What's on PD?" · "What's minting right now?" · "Does PD have anything about light?" Arguments: query (optional text match), sort (recent, minted, available), limit. Answers: the published catalog — title, slug, how many are minted and how many remain — plus platform totals. Once it is live, start here when you don't already know a project slug; every other tool wants one. Until then, the way in is search_docs (which names projects) or a slug you already have — every PD project page sits at /{slug}.

get_activity — what's happening right now (not live yet)

Ask it: "What just happened on PD?" · "What's for sale?" Arguments: limit (optional). Answers: the most recent mints, transfers and sales, what's currently listed, and the market totals. On PD the conversation around the work is the product — this is the pulse of it, as it happens.

get_collector — what someone holds (not live yet)

Ask it: "What does @brendon collect?" Arguments: who — a 0x… address, @handle, or bare handle. Answers: every Output held, grouped by project, with how many are listed, plus the account's handle and ENS name.

get_artist — who made what (not live yet)

Ask it: "What has this artist released?" Arguments: who — a 0x… address, @handle, or bare handle. Answers: their projects, total volume, and whether they're inside the between-releases cooldown.

verify_project — authenticity in one call

Ask it: "Is 0xABC… a real PD Project?" Arguments: address (the 0x… contract address). Answers: yes/no, checked against the on-chain factory — PDFactory.isProject(address) — the same verification pattern collectors are taught. A YES means the contract was deployed through PD's factory and is genuine; a NO means it merely claims to be. Use this before trusting any marketplace listing that says "PD."

get_project — the Project card

Ask it: "What's the state of Kiki?" Arguments: slug (lowercase project slug, e.g. kiki). Answers: minted count, signature colorway, the Project's PriceSprite, soundtrack, market stats, live listed count and floor, and the canonical page URL.

Nothing minted, nothing revealed. A published Project with no mints yet is browsable — you can see that it exists — but PDMCP will not hand out its colorway, sprite or soundtrack until its first Output lands. Agents are told to say it's awaiting its first mint rather than guess at how it looks.

get_output — one Output, completely

Ask it: "Tell me about Kiki #22." Arguments: slug, token_id (1-based). Answers: current owner, original minter, mint moment, the Output's symbol, listing state and last sale, the full trait set — artist traits plus the platform traits every Output carries (Artist, Project, PriceDay, the natal chart, Fate) — and the stored visual fingerprint: orientation, brightness, saturation, palette size, contrast, warmth, symmetry, texture, scene and pattern read from the artwork's actual pixels.

It also SHOWS the Output. get_output carries an interactive view (an MCP App), so in a host that supports the UI extension the artwork itself renders inside the conversation — in PD's own type and colors, with its traits, and a tap through to the Output's page. Hosts without the extension get exactly the same structured answer as before.

get_provenance — the Output's life

Ask it: "Walk me through this Output's history." Arguments: slug, token_id. Answers: the recorded timeline — mint → transfers → sales — with timestamps, parties, and ETH prices. Priced transfers are sales. This is the off-chain mirror of the ERC-721 event log, so an agent can cross-check it against the chain any time.

get_ascii — the artwork as pure text

Ask it: "Show me Kiki #22" — in a client that can't render the Output view. Arguments: slug, token_id. Answers: the Output's permanent ASCII backup artifact — real, renderable art derived deterministically from the same generative engine. Put it in a monospace code block and the artwork appears inline — no image pipeline, no viewer, pure text.

This is the fallback. In a host that supports MCP Apps, get_output already renders the Output itself (see above) and you should prefer that; get_ascii is how PD art still shows up anywhere text renders, which is everywhere.

query_traits — traits × the market

Ask it: "Does landscape or portrait sell better?" · "Which Fate carries the highest average sale?" · "Do bright Outputs list more than dark ones?" Arguments: dimension (required), slug (optional — omit for the whole catalog). Answers: the catalog grouped by that dimension, each bucket crossed with the market: Output count, sale count, average sale, top sale, ETH volume, live listed count, and floor.

Dimensions cover the platform's whole stored vocabulary — orientation, fate, natal_sun / natal_moon / natal_rising / natal_element, brightness_band, saturation_band, palette_band, contrast_band, warmth_band, symmetry_band, air_band, texture_band, tone_mood, color_temperature, scene, pattern, dominant_color, accent_color, rarity, price_day, birth_weekday, birth_season, lunar_phase, primary_trait_value, artist, and project_id. Any question that crosses what an Output is like with how the market treats it is one call.

search_docs — these docs, verbatim

Ask it: anything about how PD works. Arguments: query. Answers: verbatim excerpts from these docs with source URLs, drawn from the same /llms.txt manifest agents crawl. The tool quotes; it never paraphrases — so an agent citing PDMCP is citing pricediscussion.com/docs itself.

Prompts (not live yet)

Tools say what can be asked; prompts say what is worth asking. A host shows these as ready-made commands, so someone who has never heard of PD gets a good first question instead of having to invent one. Each carries the house rules an agent otherwise gets wrong — never guess at how an unrevealed project looks, never quote a UTC stamp at a reader in another timezone, never paraphrase PD's mechanics from memory.

Prompt	What it does
appraise_piece	Reads one Output against its own trading record and its trait cohort, and says what actually stands out. Thin data is reported as thin, never padded with invented comparables.
verify_before_buying	Checks a contract claiming to be a PD Project against the on-chain factory, before you trust the listing around it.
whats_happening	The live pulse — what just minted, what sold, what is listed.
find_work	Browses the catalog for work matching a description, using the measured visual fingerprint rather than guessing from titles.
explain_pd	Answers a question about PD from these docs, quoted and cited.

Resources (not live yet)

PD data is addressable, so a client can attach an Output or a project as context without spending a tool call on it:

• pd://project/{slug} — the Project card.
• pd://output/{slug}/{token_id} — one Output, with its traits and fingerprint.

Both answer with exactly what the matching tool returns — same code path, so a resource read and a tool call can never disagree about the same Output.

There is also an interactive Output view: on a host that supports MCP Apps, get_output renders the artwork itself inside the conversation instead of printing facts about it.

What a client sees

• Every tool is annotated read-only (readOnlyHint, idempotentHint, destructiveHint: false, openWorldHint). Hosts that honor annotations can stop asking their user for permission on each lookup — there is nothing here to approve.
• Every tool declares an output schema, so answers arrive as typed, validatable structured content, not just prose to re-parse. Fields that can legitimately be absent are typed nullable rather than dropped.
• Argument autocomplete on project slugs, trait dimensions and sort orders, so a client can offer the real catalog instead of making you spell a slug.
• Stateless. No handshake to keep alive, no session header, no auth. Every call carries what it needs, so any number of clients can share the endpoint.

Guarantees

• Read-only, forever, at this endpoint. No tool writes, signs, spends, or touches anything wallet-scoped. An agent connected to PDMCP cannot be tricked into moving anything.
• Public data only. Every answer is assembled from surfaces that are already public. There is nothing to leak.
• Cheap by design. Answers are cached at the edge; chain reads collapse to one upstream call per cache window no matter how many agents ask. Use it freely.
• The chain outranks us. Anything PDMCP reports about tokens is reproducible from Ethereum directly — see Building on PD for the raw chain surface. If an answer ever disagrees with the chain, the chain is right.

For toolmakers

PDMCP is itself a worked example of what Building on PD describes: one zero-dependency Cloudflare Worker over public reads. If you want a tool PDMCP doesn't have, build it — or ask for it in the Discord and it may simply get added.