Skip to main content
Glama
thenavidm

OP3 MCP

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Which episodes share an audience

op3_episode_overlap
Read-onlyIdempotent

Compare a podcast's busiest episodes to report shared listeners and audience overlap, showing whether a spike reached new people or only the existing audience.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
endNoWindow end, same formats as start. Defaults to now.
botsNoInclude downloads from known bots. Off by default, which matches how OP3's own download counts are computed.
startNoWindow start. A relative value like -30d, -8w or -3m, a date like 2026-08-01, or an ISO timestamp. Defaults to -30d. Wider windows are slower: this reads raw rows, not a rollup.
identifierYesAn OP3 show uuid, a podcast:guid, or the show's RSS feed URL.
top_episodesNoHow many of the busiest episodes to compare. Pairs grow quadratically, so 6 gives 15 pairs and 15 gives 105.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv1.1.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely non-obvious analytical behavior: that the symmetric similarity is misleading for skewed pairs and the smaller side's share is the decisive read. That interpretation context is real value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose in one sentence, then a second sentence covering returns and interpretation. It is longer than minimal but each clause (shared listeners, symmetric similarity, smaller-side share, spike interpretation) carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description competently documents the three returned values and how to interpret them. It does not mention default window or bot handling, but those are fully covered by the schema, so the remaining gap is small.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so window, bots, identifier and top_episodes are fully documented in the schema itself. The description only alludes to 'busiest episodes', which maps loosely to top_episodes, adding no format or syntax detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific analysis (pairwise audience overlap among a show's busiest episodes) and enumerates the three metrics returned: shared listeners, symmetric similarity, and smaller-side share. This is clearly distinguishable from siblings like op3_episode_downloads (single-episode volume) and op3_compare_shows (cross-show comparison).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the guidance about 'one big episode and one small one' tells the agent the tool fits asymmetric episode pairs, but nothing says when to prefer this over op3_listener_retention, op3_new_vs_returning, or op3_episode_downloads. No explicit alternatives or exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools