Creator MCP
Connect your own AI agent to your channels — every episode status, drafts included — by signing in or with your API key.
The audience MCP serves listeners' agents: anonymous, one channel, published episodes only. The creator MCP is the other side of that coin — it serves you. One endpoint at the platform apex, reading every channel you're a member of the way your Studio does: all episode statuses, drafts included.
https://podhood.com/mcpOne rule platform-wide: every host's /mcp is its MCP. A channel host answers for that channel's published content; the apex answers for whoever authenticated.
Connected, an agent sees exactly what your Studio does — every channel you're a member of, drafts and unpublished cuts included. That full reach is the value, and the reason to hand it only to agents you trust. An OAuth connection ends when you disconnect the client; an API key is revoked instantly in Studio → Settings → API keys.
Connect by signing in (OAuth)
In Claude, ChatGPT, or any MCP client that supports remote servers, add https://podhood.com/mcp as a connector — no key, no configuration. The client discovers PodHood's OAuth flow on its first request, opens a browser window, and you sign in and approve the access (creator:read — your channels, drafts included). Approval is per client, and tokens renew on their own while the connection stays active.
The guided version of this lives in your Studio: Studio → MCP has per-client recipes — Claude, ChatGPT, Claude Code, Cursor, and more — with the connector deep links and config blocks filled in.
Connect with an API key
For clients configured by file — or scripts wearing an MCP client hat — use your API key instead, in the x-api-key header or as a Bearer token:
{
"mcpServers": {
"podhood": {
"type": "http",
"url": "https://podhood.com/mcp",
"headers": { "x-api-key": "podhood_…" }
}
}
}Both credentials resolve to the same identity and the same rules — pick whichever your client speaks. The transport is remote Streamable HTTP, exactly like the audience servers — not a local stdio command, not legacy SSE.
The five tools
| Tool | What it returns |
|---|---|
list_channels | The channels your connection reads, with slugs and a per-channel apiAccess verdict |
list_episodes | A page of a channel's catalog — every status; each row carries mediaUrl for source deep links |
search | The Studio's hybrid search, drafts included, with quoted timestamped segments |
get_chapters | Chapters with typed key moments — titles are self-contained, citable claims |
get_transcript | Speaker-attributed, timestamped segments, windowed by startMs/endMs |
Payloads are bounded by design: list_episodes pages, and get_transcript caps at 200 segments per call — read a long episode one chapter at a time by passing a chapter's startMs/endMs from get_chapters. An agent digs by narrowing, not by pulling megabytes into context.
A typical session
list_channels— learn the slugs, skip anything markedapiAccess: false(that channel's owner is on the Free plan).list_episodeswith a slug — pick an episode, keep itsidandmediaUrl.get_chapters— the editorial skeleton; each moment title is a ready-made pull quote.get_transcriptwith one chapter's time window — verbatim, speaker-attributed quotes.- Build the output: quote text + speaker + a source deep link (
mediaUrl+&t=<seconds>s).
The same membership and plan rules as the REST API apply on every call — the two transports share one authorization core and can never disagree. Denials come back as readable tool errors, never transport faults.