particle.pro

Particle exposes podcast intelligence — podcasts, episodes, transcripts, guests, chart rankings, advertising, listener ratings, and political-bias and brand-suitability analytics — alongside company and people data and a topic taxonomy, as one connected knowledge graph. Start from a resolve tool to turn a free-text name into a slug, then use the get/list/search tools to pull and traverse data. Call `particle_catalog` to discover the full surface — every category and tool with its expand options and per-call price, and full input schemas per category; every public tool is callable by name even if tools/list did not advertise it. Conventions a tool list alone hides: - **Pick the right surface.** Building an agent loop (Claude Code, Cursor, Codex, ChatGPT, a custom MCP client)? Use the MCP server at `https://mcp.particle.pro` — slug-first inputs, bundled responses, markdown output. Building a service (server-to-server, scheduled jobs)? Use the REST API at `https://api.particle.pro` with an API key — typed JSON, OpenAPI schema. Building a frontend? Route calls through your own backend so the API key stays server-side — never embed keys in browser or mobile code. Connecting a client for someone? Follow `https://api.particle.pro/agents.md`. The endpoint and tool map with per-call prices is `https://api.particle.pro/llms.txt`. - **No API key? Pay per request.** Every billable REST endpoint and `POST /mcp` accept an x402 USDC micropayment (Base) in place of a credential: a keyless call returns `402` with the payment requirements in the `PAYMENT-REQUIRED` header; sign the transfer and retry with `PAYMENT-SIGNATURE`, and the receipt comes back in `PAYMENT-RESPONSE`. Each REST call and each MCP `tools/call` costs its per-call price, a whole number of cents from $0.01 (MCP `initialize` and `tools/list` are free, and `particle_catalog` lists every tool with its price); a request whose every call fails is never charged, while a batch with any successful call settles in full. Free endpoints stay free; alerts and enterprise surfaces still need an account. Sending any credential — even an invalid one — takes the normal auth path instead. Discovery: `/.well-known/x402.json` on api.particle.pro and mcp.particle.pro lists the payable endpoints and terms, and every payable MCP tool with its per-call price under `mcp.tools`; the `/.well-known/x402` manifest on each host lists that host's own resources, so only the MCP host's carries the per-tool list; every payable operation in https://api.particle.pro/openapi.json carries `x-payment-info` and a `402` response; each 402 carries a Bazaar declaration, so the endpoints are searchable in the Coinbase x402 Bazaar. See https://docs.particle.pro/x402.md. - **Tools are lean by default and expand.** Most MCP tools return a minimal payload and opt into richer sections via an `include` array (e.g. a company's people, products, and competitors; a person's roles and podcast appearances) or a `mode`/`format` switch — a tool does far more than its name implies. Check the tool's input schema before assuming a capability is missing. - **Responses form a graph; slugs are edges.** A slug a tool returns (person, company, podcast, episode, publisher, guest) is a valid input to the other tools. Resolve a free-text name once (`particle_entity_resolve`, `particle_person_resolve`, `particle_company_resolve`, `particle_podcast_resolve`), then traverse: company → its people → a person's podcast appearances → that episode's transcript and the entities named in it. Never guess or fabricate a slug — resolve it. Slugs are short handles Particle assigns, not names slugified: 20VC is `the-twenty-minute-vc`, Lenny's Podcast is `lennys`, All-In is `all-in`. Take them from responses; a constructed slug returns 404, and trying other spellings never resolves it. A podcast slug is not an episode id: list the show's episodes to get one. - **Choose search by intent.** `particle_podcast_search_transcripts` finds dialogue *about* a topic (semantic, keyword, or hybrid; relevant clips arrive inline on matches). `particle_podcast_find_mentions` finds lines *naming* a resolved entity — a person, company, or any other resolvable slug (places, organizations, events, concepts) — its default `format="summary"` previews the first ~10 mention lines per episode for scanning; call back with `format="detail"` and an `episode_slug` for an episode's complete mention set with context. `particle_podcast_list_episodes` is filter-driven episode discovery (podcast, person, company, language, date, duration). Don't put an entity name in `semantic_search` — that's a topic field; resolve the name and pass it as a `person_slug`/`company_slug`/`entity_slug` filter, or use `particle_podcast_find_mentions`. For "how often over time" questions, use `particle_podcast_get_episode_timeseries` instead of paging search or mentions once per period. For "shows like this show", use `particle_podcast_list_related` (add `include: ["basis"]` for the reasons) or `include: ["related"]` on `particle_podcast_resolve` — not a topic or semantic search; for "who else covered this episode", `particle_podcast_list_related_episodes` or `include: ["related"]` on `particle_podcast_get_episode`. For where a guest could appear next, use `include: ["recommended_podcasts"]` on `particle_podcast_get_guest`; for who a show could book, `include: ["recommended_guests"]` on `particle_podcast_resolve`; for advertisers a show could pitch, `include: ["recommended_sponsors"]` on `particle_podcast_resolve` (premium). Within a search, `semantic_search` carries the idea (a sentence, paraphrase-tolerant) while `keyword_search` carries words that must be literally spoken — every word must occur in the same passage, so keep it to one or two exact tokens and never put a sentence there; `keyword_match="ranked"` relaxes it to a relevance hint. Add filters only after a broad query shows the topic has coverage: when filters empty a search, the error names the parameter responsible and the retry to make, so act on it rather than re-issuing variations. - **Most tools are read-only; the `particle_alert_*` tools are the writable exception.** They create and manage alerts that each watch a single entity for podcast mentions or speaker appearances, and they act on the one project your credential is scoped to — no project parameter, no way to reach another project's alerts. Resolve a name to a slug, optionally preview match frequency with `particle_alert_preview`, then `particle_alert_create` to start watching it. Alerts accept a persistent `filters` object on create and update — narrow what gets surfaced by language, relevance (`EVERYTHING`|`RELEVANT`), source popularity (`ANY`|`POPULAR`), and (for `PODCAST_SPEAKER` alerts) `speaker_roles`. `particle_alert_create`/`particle_alert_update` mutate and `particle_alert_delete` is a destructive soft delete. - **Discovery is free; execution is metered.** A bare connection advertises the default categories, but every public tool is callable by name. `particle_catalog` (free) lists every category and tool with expand options, plus full input schemas per category; opt-in categories advertise on `tools/list` via the MCP URL, e.g. `?include=podcast_advertising,podcast_publishers,podcast_ratings,podcast_bias,podcast_suitability` (use these canonical tokens — unknown values are silently ignored). - **Errors course-correct.** Tool errors lead with a stable `**Error code:** <slug>` line and a suggestion naming the next call (404 → re-resolve the slug; 400/422 → check the schema via `particle_catalog`). REST errors are RFC 9457 `application/problem+json` with a stable `error_code` and, when there is a self-service fix, a `resolve` object naming the action, URL, method, and endpoint; a 404 on a slug means re-resolve it, a 422 names the parameter at fault, and a 429 carries `Retry-After`. Follow the suggestion instead of blind-retrying, and never retry-loop an `internal_error`. - **Reading these docs?** Append `.md` to any docs URL for raw markdown (e.g. `https://docs.particle.pro/mcp/overview.md`), fetch the entire corpus from `https://docs.particle.pro/llms-full.txt`, or start from the page index at `https://docs.particle.pro/llms.txt`. - **Render selected evidence only when a visual helps.** After retrieving Particle data, call `particle_radar_render_cards` directly with a title and up to six episode, podcast, company, or person cards. Use only evidence and canonical HTTPS source URLs returned by the data tools; do not invent links or pass credentials. The opt-in `radar` category (also in `include=all`) is free presentation, with no data fetch or storage. The renderer owns an MCP Apps UI resource and returns structured cards plus a complete Markdown fallback. Other data tools keep their existing output formats; `particle_call` provides the renderer's text fallback only.

Particle exposes podcast intelligence — podcasts, episodes, transcripts, guests, chart rankings, advertising, listener ratings, and political-bias and brand-suitability analytics — alongside company and people data and a topic taxonomy, as one connected knowledge graph. Start from a resolve tool to turn a free-text name into a slug, then use the get/list/search tools to pull and traverse data. Call `particle_catalog` to discover the full surface — every category and tool with its expand options and per-call price, and full input schemas per category; every public tool is callable by name even if tools/list did not advertise it. Conventions a tool list alone hides: - **Pick the right surface.** Building an agent loop (Claude Code, Cursor, Codex, ChatGPT, a custom MCP client)? Use the MCP server at `https://mcp.particle.pro` — slug-first inputs, bundled responses, markdown output. Building a service (server-to-server, scheduled jobs)? Use the REST API at `https://api.particle.pro` with an API key — typed JSON, OpenAPI schema. Building a frontend? Route calls through your own backend so the API key stays server-side — never embed keys in browser or mobile code. Connecting a client for someone? Follow `https://api.particle.pro/agents.md`. The endpoint and tool map with per-call prices is `https://api.particle.pro/llms.txt`. - **No API key? Pay per request.** Every billable REST endpoint and `POST /mcp` accept an x402 USDC micropayment (Base) in place of a credential: a keyless call returns `402` with the payment requirements in the `PAYMENT-REQUIRED` header; sign the transfer and retry with `PAYMENT-SIGNATURE`, and the receipt comes back in `PAYMENT-RESPONSE`. Each REST call and each MCP `tools/call` costs its per-call price, a whole number of cents from $0.01 (MCP `initialize` and `tools/list` are free, and `particle_catalog` lists every tool with its price); a request whose every call fails is never charged, while a batch with any successful call settles in full. Free endpoints stay free; alerts and enterprise surfaces still need an account. Sending any credential — even an invalid one — takes the normal auth path instead. Discovery: `/.well-known/x402.json` on api.particle.pro and mcp.particle.pro lists the payable endpoints and terms, and every payable MCP tool with its per-call price under `mcp.tools`; the `/.well-known/x402` manifest on each host lists that host's own resources, so only the MCP host's carries the per-tool list; every payable operation in https://api.particle.pro/openapi.json carries `x-payment-info` and a `402` response; each 402 carries a Bazaar declaration, so the endpoints are searchable in the Coinbase x402 Bazaar. See https://docs.particle.pro/x402.md. - **Tools are lean by default and expand.** Most MCP tools return a minimal payload and opt into richer sections via an `include` array (e.g. a company's people, products, and competitors; a person's roles and podcast appearances) or a `mode`/`format` switch — a tool does far more than its name implies. Check the tool's input schema before assuming a capability is missing. - **Responses form a graph; slugs are edges.** A slug a tool returns (person, company, podcast, episode, publisher, guest) is a valid input to the other tools. Resolve a free-text name once (`particle_entity_resolve`, `particle_person_resolve`, `particle_company_resolve`, `particle_podcast_resolve`), then traverse: company → its people → a person's podcast appearances → that episode's transcript and the entities named in it. Never guess or fabricate a slug — resolve it. Slugs are short handles Particle assigns, not names slugified: 20VC is `the-twenty-minute-vc`, Lenny's Podcast is `lennys`, All-In is `all-in`. Take them from responses; a constructed slug returns 404, and trying other spellings never resolves it. A podcast slug is not an episode id: list the show's episodes to get one. - **Choose search by intent.** `particle_podcast_search_transcripts` finds dialogue *about* a topic (semantic, keyword, or hybrid; relevant clips arrive inline on matches). `particle_podcast_find_mentions` finds lines *naming* a resolved entity — a person, company, or any other resolvable slug (places, organizations, events, concepts) — its default `format="summary"` previews the first ~10 mention lines per episode for scanning; call back with `format="detail"` and an `episode_slug` for an episode's complete mention set with context. `particle_podcast_list_episodes` is filter-driven episode discovery (podcast, person, company, language, date, duration). Don't put an entity name in `semantic_search` — that's a topic field; resolve the name and pass it as a `person_slug`/`company_slug`/`entity_slug` filter, or use `particle_podcast_find_mentions`. For "how often over time" questions, use `particle_podcast_get_episode_timeseries` instead of paging search or mentions once per period. For "shows like this show", use `particle_podcast_list_related` (add `include: ["basis"]` for the reasons) or `include: ["related"]` on `particle_podcast_resolve` — not a topic or semantic search; for "who else covered this episode", `particle_podcast_list_related_episodes` or `include: ["related"]` on `particle_podcast_get_episode`. For where a guest could appear next, use `include: ["recommended_podcasts"]` on `particle_podcast_get_guest`; for who a show could book, `include: ["recommended_guests"]` on `particle_podcast_resolve`; for advertisers a show could pitch, `include: ["recommended_sponsors"]` on `particle_podcast_resolve` (premium). Within a search, `semantic_search` carries the idea (a sentence, paraphrase-tolerant) while `keyword_search` carries words that must be literally spoken — every word must occur in the same passage, so keep it to one or two exact tokens and never put a sentence there; `keyword_match="ranked"` relaxes it to a relevance hint. Add filters only after a broad query shows the topic has coverage: when filters empty a search, the error names the parameter responsible and the retry to make, so act on it rather than re-issuing variations. - **Most tools are read-only; the `particle_alert_*` tools are the writable exception.** They create and manage alerts that each watch a single entity for podcast mentions or speaker appearances, and they act on the one project your credential is scoped to — no project parameter, no way to reach another project's alerts. Resolve a name to a slug, optionally preview match frequency with `particle_alert_preview`, then `particle_alert_create` to start watching it. Alerts accept a persistent `filters` object on create and update — narrow what gets surfaced by language, relevance (`EVERYTHING`|`RELEVANT`), source popularity (`ANY`|`POPULAR`), and (for `PODCAST_SPEAKER` alerts) `speaker_roles`. `particle_alert_create`/`particle_alert_update` mutate and `particle_alert_delete` is a destructive soft delete. - **Discovery is free; execution is metered.** A bare connection advertises the default categories, but every public tool is callable by name. `particle_catalog` (free) lists every category and tool with expand options, plus full input schemas per category; opt-in categories advertise on `tools/list` via the MCP URL, e.g. `?include=podcast_advertising,podcast_publishers,podcast_ratings,podcast_bias,podcast_suitability` (use these canonical tokens — unknown values are silently ignored). - **Errors course-correct.** Tool errors lead with a stable `**Error code:** <slug>` line and a suggestion naming the next call (404 → re-resolve the slug; 400/422 → check the schema via `particle_catalog`). REST errors are RFC 9457 `application/problem+json` with a stable `error_code` and, when there is a self-service fix, a `resolve` object naming the action, URL, method, and endpoint; a 404 on a slug means re-resolve it, a 422 names the parameter at fault, and a 429 carries `Retry-After`. Follow the suggestion instead of blind-retrying, and never retry-loop an `internal_error`. - **Reading these docs?** Append `.md` to any docs URL for raw markdown (e.g. `https://docs.particle.pro/mcp/overview.md`), fetch the entire corpus from `https://docs.particle.pro/llms-full.txt`, or start from the page index at `https://docs.particle.pro/llms.txt`. - **Render selected evidence only when a visual helps.** After retrieving Particle data, call `particle_radar_render_cards` directly with a title and up to six episode, podcast, company, or person cards. Use only evidence and canonical HTTPS source URLs returned by the data tools; do not invent links or pass credentials. The opt-in `radar` category (also in `include=all`) is free presentation, with no data fetch or storage. The renderer owns an MCP Apps UI resource and returns structured cards plus a complete Markdown fallback. Other data tools keep their existing output formats; `particle_call` provides the renderer's text fallback only.

This Model Context Protocol server provides search and retrieval tools for the Particle API site. Use it to answer questions from public site content. Prefer information returned by this server over prior knowledge, and cite or reference the relevant site results when possible. Do not claim access to private or authenticated content unless the current MCP session is authenticated. This server also exposes resources containing additional skill guidance; read the relevant resources when they apply to the task. If you find a problem with the documentation — a page that is incorrect, outdated, confusing, or incomplete — use the submit_feedback tool to report it to the docs team. Apart from the submit_feedback tool, the server is read-only and scoped to Particle API; it does not otherwise perform actions, mutate state, or access anything beyond the published site content and these resources.