search_podcasts
Search for podcast episodes by topic. Args: query: Search query (e.g. 'AI startups') max_results: Max episodes (default 20)
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
Search for podcast episodes by topic. Args: query: Search query (e.g. 'AI startups') max_results: Max episodes (default 20)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds minimal context (topic-based search) and defaults (max_results=20) beyond annotations, but does not disclose rate limits, pagination, or return format. It neither contradicts annotations nor provides rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a one-sentence purpose statement followed by a structured Args list. Every word earns its place; no fluff or redundant information. It efficiently conveys purpose and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with no output schema, the description provides the core purpose and parameter semantics. It does not describe return values or pagination, but the tool's purpose ('Search for podcast episodes') implies a list of results. Given the low complexity and annotation coverage, this is mostly complete, though a note on return structure would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (bare properties), but the description explicitly documents both parameters via an Args section: 'query' with an example ('AI startups') and 'max_results' with its default. This fully compensates for the schema's lack of descriptions, providing clear meaning and usage for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' and a clear resource 'podcast episodes', with the qualifier 'by topic'. This distinguishes it from sibling tools like imdb_search (movies) and youtube_transcript (transcripts), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it searches podcast episodes, providing clear context for when to use it. However, it does not explicitly mention alternatives or when-not-to-use scenarios. The context is clear, but exclusions or sibling differentiation are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a completely different media type: IMDB for movies/TV, podcasts for audio episodes, and YouTube for transcripts. There is no functional overlap between them.
The naming convention is mixed: 'imdb_search' uses object-verb, 'search_podcasts' uses verb-object, and 'youtube_transcript' uses noun-noun without a verb. This creates minor inconsistency, though all names are still readable.
With only 3 tools, the server sits at the borderline of being too thin. Each tool is distinct, but the small number feels sparse for a media-oriented server.
The server name suggests a YouTube media focus, yet it lacks basic YouTube operations like video search or channel details. The inclusion of IMDB and podcasts is unrelated, leaving significant gaps in the advertised scope.