---
title: "PDMCP — the PD MCP Server"
description: "Connect any AI agent to Price Discussion: the PDMCP server's endpoint, every tool with its exact arguments and answer shapes, how to render PD artwork inline in a chat, trait × market analytics, and the guarantees behind the data."
category: "building"
keywords: ["mcp", "agents", "ai", "claude", "chatgpt", "model context protocol", "pdmcp", "tools", "prompts", "resources"]
last_updated: "2026-09-20"
---

# PDMCP — the PD MCP Server

PDMCP is Price Discussion's public [Model Context Protocol](https://modelcontextprotocol.io)
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](/docs/for-collectors/the-secondary-market)
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](/docs/app/projects-and-minting), 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](/docs/app/outputs)) — 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](https://modelcontextprotocol.io/docs/extensions/apps)), 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](/docs/app/outputs)
— 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](/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](/docs/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](/docs/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](https://discord.gg/mJteKZmg28) and it may simply get added.