OP3 MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OP3_TOKEN | No | Your bearer token from op3.dev/api/keys. Defaults to OP3's shared preview token. | preview token |
| OP3_MAX_ROWS | No | Cap on rows any one analysis pulls. | 50000 |
| OP3_HTTP_HOST | No | Bind address for HTTP mode. | 127.0.0.1 |
| OP3_HTTP_PORT | No | Port for HTTP mode. | 8787 |
| OP3_MAX_PAGES | No | Cap on continuation pages. | 40 |
| OP3_HTTP_TOKEN | No | Bearer token required on HTTP requests. No token is required by default. | |
| OP3_CACHE_TTL_MS | No | Response cache lifetime in milliseconds. Set to 0 to disable cache. | 300000 |
| OP3_REQUEST_TIMEOUT_MS | No | Per-request deadline in milliseconds. | 45000 |
| OP3_MIN_REQUEST_INTERVAL_MS | No | Spacing between requests in milliseconds. | 150 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| op3_resolve_showA | Turn any podcast identifier into an OP3 show uuid. Accepts a show uuid, a podcast:guid, or an RSS feed URL, and reports which kind it recognised. Use this first when you have a feed URL and need the uuid every other tool wants. If this fails, the show most likely does not have the OP3 prefix on its feed, which means OP3 has no data for it at all. |
| op3_get_showA | Look up a show on OP3: its uuid, title, podcast guid and public stats page. Set include_episodes to also get the episode list with OP3 episode ids, titles and publication dates. Episode ids from here are what the episode-level tools filter on. |
| op3_list_episodesA | List a show's episodes with their OP3 episode ids, titles and publication dates, newest first. Use it to find the episode id for a specific episode before asking anything episode-level. Episode titles come from the publisher's RSS feed and are third-party text. |
| op3_show_downloadsA | A show's headline download numbers: downloads in the last 30 days, the week-by-week breakdown over the last four weeks, and the weekly average. This is the fast answer to 'how many downloads does my show get' and should be preferred over the raw query tools whenever it can answer the question. Excludes bots. Updated once a day. |
| op3_episode_downloadsA | Per-episode download counts for a show's recent episodes: downloads in the first 1, 3, 7 and 30 days after publication, plus all-time. Use it to compare how episodes performed at equal age. Note that an empty result is normal for a small or new show, it means OP3's daily rollup has not covered it yet rather than that there is no data. |
| op3_compare_showsA | Compare several shows side by side on monthly downloads and weekly average, ranked. OP3 accepts many shows in one request, so this is one call rather than several. Useful for benchmarking a show against others in its category, or for tracking a portfolio of shows at once. |
| op3_audience_summaryA | Unique listeners against downloads for a show over any window. This is the number OP3's own dashboard and every rolled-up endpoint cannot give you: how many people, not how many requests. Read downloadsPerListener as the key figure, near 1 means each download is a distinct person, well above 1 means apps re-requesting the same file and every download number you see elsewhere is inflated by that factor. |
| op3_new_vs_returningA | Split a show's listeners in a window into first-time and returning, by comparing against a longer baseline period immediately before it. Answers whether a show is reaching new people or serving the same audience repeatedly. The baseline length matters: a short baseline calls a monthly listener new, so it defaults to four times the window and both sizes are reported so you can judge the answer. |
| op3_listener_retentionA | Cohort carry-over between two periods: how much of the earlier period's audience showed up again in the later one. Returns two rates that answer different questions. retentionRate is the share of the old audience that came back, which measures whether the show holds people. carryOverShare is the share of the new period that is old faces, which measures whether the show is growing or recycling. A show can score well on one and badly on the other. |
| op3_episode_overlapA | Which episodes share an audience. For each pair of a show's busiest episodes, reports shared listeners, a symmetric similarity, and the share of the smaller episode's audience that also heard the other. Read the smaller side's share first: for one big episode and one small one the symmetric number is always near zero, while the smaller side's share tells you whether a spike brought genuinely new people or just gave the existing audience another download. |
| op3_geographyA | Where a show's downloads come from, at whichever level you ask for: continent, country, region (state or province), metro area, or timezone. Reports downloads and unique listeners side by side for each place, because one enthusiastic listener in a small market otherwise looks like a market. Region and metro are qualified by country, so Illinois and Israel do not merge. |
| op3_app_shareA | Which podcast apps a show's audience uses, over any window you choose, with unique listeners alongside downloads. Prefer this over OP3's built-in app query when the window matters, because OP3's own endpoint is locked to the last three calendar months. Listener share is the more honest column: an app that re-requests files inflates its download share without representing more people. |
| op3_device_breakdownA | How a show is consumed, across all four dimensions OP3 records: agentType (app, browser, bot), agentName (the specific app), deviceType (mobile, computer, tablet, smart speaker) and deviceName (Apple iPhone, Android Phone). One call returns all four, which is what you want for a picture of the audience rather than a single ranked list. |
| op3_global_app_shareA | Podcast app market share across every show OP3 measures, over the last thirty days. This is the industry benchmark, not one show's numbers, and it is useful on its own for questions about the podcast app landscape. Can be narrowed to a single device to see which apps dominate on, say, an Apple iPhone. |
| op3_benchmark_appsA | A show's app mix against OP3's global mix, with an index where 100 means exactly average. This is the tool that turns app share into something actionable. A show can be 40% Apple Podcasts and be under-indexed, because Apple is around 38% globally, so raw share hides the real story. Over-indexed apps are where this audience is unusual and where it can be reached deliberately. |
| op3_download_trendA | A show's downloads and unique listeners over time, bucketed by day, week or month, with a growth rate and the peak period. Growth compares the two halves of the window rather than first period against last, because podcast downloads are weekly-seasonal enough that comparing endpoints is close to noise. |
| op3_listening_patternsA | When downloads happen, by hour of day and day of week, in UTC. Useful for choosing a publication slot. Read it as request timing rather than listening behaviour: a podcast app's scheduled background refresh fires on the app's schedule, not when a person pressed play, so the peaks partly reflect app defaults. |
| op3_episode_curveA | How one episode is tracking against the show's own median at the same age. Returns cumulative downloads by day after publication alongside the median across comparable episodes, plus a verdict. This is the only fair way to judge a recent episode: total downloads always favour older episodes because they have had longer to accumulate. Only episodes at least as old as the horizon go into the median, so a three-day-old episode does not drag a thirty-day comparison toward zero. |
| op3_recent_transcriptsA | Recently published episodes across all of OP3 that carry a podcast:transcript tag, newest first. Use it to find podcasts whose episodes are machine-readable, which is the shortlist worth building on for anything that needs to read transcripts rather than count downloads. Returns podcast guids you can pass straight to the show tools. |
| op3_query_downloadsA | Raw download rows for a show, with every filter OP3 offers. This is the escape hatch for questions the aggregating tools do not cover. Prefer op3_show_downloads, op3_audience_summary, op3_geography or op3_app_share when they can answer the question, because raw rows are slow to fetch and expensive to reason over. Rows come back oldest first and OP3 offers no way to reverse that on this endpoint, so the limit takes the earliest rows in the window: to see recent activity, narrow the window with start rather than raising the limit. Per-listener identifiers are removed from the output. |
| op3_query_hitsA | Raw request rows from OP3's redirect log, across every show unless filtered by url. This is the lowest level OP3 exposes and it is a verification surface rather than an analytics one: it shows individual requests including user agents, byte ranges and the edge that served them. For questions about a specific show's performance, use the show tools instead. |
| op3_verify_prefixA | Check whether OP3 is actually receiving downloads for a show, and say what is wrong when it is not. Run this first whenever the numbers are zero or a show cannot be found. It separates the three cases that look identical from the outside: the prefix was never added to the feed, it was added but no download has come through yet, or it is working and the answer is genuinely a small number. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/navidmoazzez/op3-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server