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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful context beyond those: the call is a cheap diagnostic preflight, it returns vendor numbers, and it returns no listening data. This helps the agent set expectations without contradicting 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.

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

Three concise sentences, with the core purpose first, the diagnostic guidance second, and the key limitation last. Every sentence adds value and the structure is easy for an agent to scan.

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 zero-parameter, read-only diagnostic tool with no output schema, the description is complete: it states what the tool does, what it returns, what it does not return, and when to invoke it. Nothing essential is missing for correct selection and invocation.

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?

The tool has zero parameters and the schema fully covers that fact, so the description bears little parameter burden. It still clarifies that the operation depends on already-stored credentials/token state, which is useful context for why no parameters are needed.

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 names a specific action (verify credentials) and a specific result (list vendor numbers readable by the token), then explicitly distinguishes itself from data-returning analytics tools by stating it returns no listening data. This makes its role unmistakable even among many analytics siblings.

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?

It gives explicit placement guidance: 'Call this first' because it is the cheapest way to diagnose whether a problem is a wrong token, a wrong vendor number, or a show with no data. This gives an agent a clear decision procedure rather than leaving the choice to inference.

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

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

Beyond the readOnly/idempotent annotations, the description discloses meaningful behavioral semantics: errors are Apple-documented required fields that get the feed rejected or silently degraded, while warnings are non-blocking issues with concrete consequences like stalling a claim or re-publishing the catalogue. This gives the agent a strong model of what the check will report and why it matters.

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 two sentences with no filler. The first sentence front-loads the core purpose, and the second provides the essential error/warning distinction with concrete examples. Every clause earns its place, and the structure makes the tool's behavior easy to parse.

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?

Given three well-documented parameters, rich safety annotations, and a detailed error/warning semantic in the description, an agent has enough to invoke the tool correctly and interpret its output. There is no output schema, but the description clearly defines the two classes of results. The tool is fully usable without needing additional context.

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?

The input schema already covers all three parameters at 100%, so the baseline is 3. The description adds value beyond the schema by explaining the effect of limit: 'More is a more thorough check and a larger download,' which helps an agent reason about cost/benefit when choosing a value. It does not add new semantics for show or storefront, but those are already well described in the schema.

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 opens with 'Check a podcast's RSS feed against what Apple actually requires,' giving a specific verb, resource, and objective. It clearly distinguishes this from sibling feed-retrieval tools like get_feed by focusing on validation against Apple requirements and surfacing costly issues.

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 establishes a clear context: use this tool to validate a feed before submission or to surface things that will hurt the show later, such as missing owner email or unstable guid. It does not explicitly name alternative tools or state when not to use it, but the purpose is clear enough for an agent to select it over raw feed-fetching siblings.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context beyond those annotations: the six-show cap exists because each show costs several requests against a rate-limited API. The schema further notes that reviews=0 makes the call much faster. No contradiction with annotations.

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?

Three sentences, each earning its place: the first states the core comparison, the second communicates the value proposition, and the third gives a hard constraint with its reason. The description is front-loaded with the most important information and contains no filler.

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 multi-show aggregation tool with no output schema, the description identifies the metrics being compared and the practical rate-limit constraints, which is enough for an agent to select and invoke it correctly. A precise statement of the response shape would be an improvement, but the described metrics and well-documented parameters make the tool reasonably complete.

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 description coverage is 100%, with all three parameters already documented with types, constraints, and defaults. The description adds useful context about comparison dimensions but does not meaningfully extend parameter semantics. This is the baseline 3 case where the schema carries the parameter documentation burden.

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 clearly states a specific verb and resource: it puts two or more shows side by side across concrete metrics like chart rank, review sentiment, catalogue size, and publishing cadence. This distinguishes it from single-show or single-metric siblings such as get_podcast, get_reviews, or find_chart_position. The 'competitive read' framing reinforces its aggregation role.

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 communicates when to use this tool: when a multi-show competitive comparison is needed, framing it as the alternative to 'a dozen calls plus the joining.' It also gives practical constraints: capped at six shows and rate-limit implications. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5.

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

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

While annotations already mark destructiveHint=true, the description goes further by specifying exactly what will happen: it 'needs confirm: true and will overwrite whatever is at the path.' This gives the agent the precise consequence of invoking the tool and the necessary guardrail, which is especially valuable for a file-writing operation.

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?

Three sentences each earn their place: purpose, behavioral hazard/confirmation, and realistic use cases. The most important safety information is front-loaded after the purpose, and there is no filler or repetition of structured metadata.

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 three-parameter export tool, the description covers what it does, when to use it, what path is for, and the overwrite risk. It does not describe the tool's return value, but for a side-effect-focused file export this is a minor gap rather than a blocking one.

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 description coverage is 100%, so the baseline is 3, but the description adds meaningful context beyond the schema: it warns that confirm must be true and explains the overwrite risk, which the schema's optional confirm field alone does not convey. It also clarifies the path's purpose by mentioning OPML compatibility with podcast apps.

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 ('Write'), names the resource ('shows you follow'), and states the output format ('OPML file'), so an agent immediately knows what the tool does. It also explicitly distinguishes it from sibling tools by noting 'This is the one tool here that writes anything.' This is clear and not a tautology.

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 gives concrete use cases: leaving Apple Podcasts and backing up a follow list that exists nowhere else. It also frames the tool as the only writer among the siblings, which helps an agent avoid selecting it for read-only tasks. It stops short of naming a particular alternative tool, so it is not a perfect 5.

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

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

Annotations already establish read-only/idempotent behavior. The description adds non-obvious operational facts: Apple has no rank endpoint so the tool fetches charts, and unranked means outside the top 100, not unpopular. It does not describe the return format, but the added context goes 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.

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

Four sentences, each earning its place: the first front-loads the core purpose, the second explains the method, the third justifies sweeping storefronts, and the fourth defines a potentially confusing term. There is no filler or redundancy.

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 read-only lookup with four well-documented parameters and no output schema, the description supplies the operational context an agent needs: the absence of a rank endpoint, the chart sweep mechanism, cross-market divergence, and the top-100 definition of unranked. Nothing about when or how to call it is left ambiguous.

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 description coverage is 100%, and the schema already explains the show id/URL distinction, storefront codes, the default storefront, and rate-limit implications of storefronts. The description reinforces why storefronts matter but contributes no new parameter-level syntax or format details, so the baseline 3 applies.

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 opening sentence names a concrete verb and resource: 'Find where one show sits in Apple's Top Shows chart.' It also differentiates the inverted lookup from chart-listing siblings by explaining it 'fetches each chart and looks the show up in it by id.'

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 gives clear context for when this tool is appropriate: when you need a show's rank rather than chart contents, and when storefront sweep matters because 'ranking diverges sharply between countries.' It does not explicitly name sibling alternatives such as get_top_shows, so it stops short of a 5.

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

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

Annotations already establish a safe, read-only, idempotent operation. The description adds meaningful behavioral detail: it searches both genre and subject matter, removes the seed show from results, and honestly discloses the limitation that Apple exposes no listener-subscription data. This goes beyond the structured metadata.

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?

Three front-loaded sentences carry high information density: what it does, how it works, what it is not, and when to use it. The caveat about Apple's data earns its place because it prevents a misleading interpretation of 'similar', and no filler is present.

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 similarity-recommendation tool with no output schema, the description explains the matching logic, the self-removal behavior, and the tool's limitations, which is sufficient for correct invocation. It does not describe result shape or ordering, but the input schema and 'candidates to return' wording cover most practical invocation needs.

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 description coverage is 100%, so the baseline is 3. The description alludes to the 'show' parameter ('given one', 'its own subject matter') but does not add meaning beyond the schema. The limit and storefront parameters are fully documented in the schema, and the description does not need to repeat them.

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 opens with a specific verb and resource ('Find shows adjacent to a given one') and explains the exact mechanism: searching by genre and subject matter, then removing the input show from results. This clearly differentiates it from sibling search/list tools like search_podcasts or get_top_shows because it is seed-based and adjacency-focused.

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?

It provides a clear use case ('mapping a niche before deciding where a new show fits') and explicitly warns that this is genre/topic adjacency rather than true audience overlap. It does not name sibling alternatives or state 'use X instead', so it falls just short of full routing guidance.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behavioral traits: transcripts are show-chosen, publicly fetchable, often absent, and the tool returns nothing rather than erroring. The 'unlike Apple's own transcripts' distinction adds real beyond-schema context, and nothing contradicts 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.

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

The description is compact and front-loaded with the core purpose, then enriches with essential distinctions and edge-case behavior. Every sentence contributes meaning without redundancy.

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 read-only tool with a small, well-documented schema and no output schema, the description covers what an agent needs: the output fields (URL, format, language), the source context, and the no-transcripts edge case. Combined with the schema, nothing important is missing.

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?

The input schema already describes both parameters well: 'show' accepts an RSS URL, Apple Podcasts id, or Apple Podcasts URL, and 'limit' specifies count and scan order. The description adds output details but not additional parameter semantics, so a baseline 3 is appropriate given 100% schema coverage.

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 begins with a specific action and resource: 'List episodes of a show that publish a transcript in their feed, with the URL, format and language of each.' It clearly differentiates these from Apple's own transcripts, so an agent understands exactly what the tool returns and how it differs from related concepts.

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 provides useful context for when to call this tool: it covers publicly fetchable Podcasting 2.0 transcripts, not Apple's private transcripts, and warns that most shows publish none and that the tool returns nothing rather than failing. It does not name sibling tools as alternatives, but the intended use case is clear enough.

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

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

Goes beyond the readOnly/idempotent/non-destructive annotations by revealing that the tool returns raw, unmodified rows and columns, that it requires Apple Podcasts Connect credentials, and that Apple's publication lag affects data availability. These are operationally useful details not present in 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.

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

Three sentences, each earning its place: the first defines the verb and output shape, the second gives differentiation and use cases, the third covers authentication. The key contrast is front-loaded before the alternative explanation.

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?

Even without an output schema, the description tells the agent what the tool returns ('columns and rows unchanged') and why it exists. Credentials, lag, and escape-hatch use are all present, making this complete for a raw report-fetching tool with rich schema descriptions.

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 description coverage is 100%, so the parameters (date, limit, date_type, report_type) are already fully documented with types, defaults, enum options, and behavioral notes. The description adds context by mentioning 'by name' and the raw nature of the output, but it does not need to restate parameters.

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?

States a specific action ('Fetch any Apple Podcasts Connect listening report by name') and a clear output behavior ('return its columns and rows unchanged'). It also distinguishes itself from sibling analytics tools by identifying this as the raw 'escape hatch' tool, so an agent can tell it apart from shaped report views.

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?

Explicitly says when to use this tool: for reports not covered by the other analytics tools and for inspecting columns after Apple changes a report format. It contrasts this with 'the other analytics tools are shaped views over specific reports', giving the agent a clear routing rule.

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

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

Annotations already establish read-only and non-destructive behavior, and the description adds meaningful behavioral context beyond those annotations: it requires Apple Podcasts Connect credentials, listener counts are devices rather than people, and results are ranked for one reporting period. This is a useful and non-obvious disclosure.

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 three sentences with no filler. The first sentence is the functional definition, the second gives the tool's value in deciding which episode worked, and the third states a required credential. Every sentence earns its place.

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?

With no output schema, the description still conveys the essential return content ('plays and listener counts per episode'), the ordering ('ranked'), the reporting scope, and the auth prerequisite. Combined with a fully described input schema and strong annotations, this is sufficient for an agent to select and invoke the tool correctly.

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 description coverage is 100%, so the schema already documents all four parameters thoroughly, including date formats, defaults, and the meaning of limit and date_type. The description's 'one reporting period' and 'ranked' lightly reinforce the schema but do not add practical parameter-level meaning beyond it, so the baseline 3 applies.

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 clearly states a specific resource ('per episode') and the data returned ('plays and listener counts') for one reporting period, ranked, so an agent knows exactly what kind of analytics this is. The phrase 'which episode actually worked' adds a purpose that separates it from public catalog lookups and from show-level analytics tools like get_show_analytics.

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 gives clear context for when to use this tool: when you need episode-level listening performance that public data cannot provide. It also states a prerequisite ('Needs Apple Podcasts Connect credentials'), which helps an agent avoid calling it in the wrong auth context. It does not explicitly name alternatives or exclusions, so it misses a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds useful behavioral context beyond annotations: the feed can be slow or unreachable, it parses the feed, and it returns the complete record unlike Apple's catalog. This adds real value about failure modes and data completeness.

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?

Four sentences with no wasted words: the tool's action, its advantage over the alternative, accepted input types, and a performance caveat. The most important distinguishing information is front-loaded before the input types.

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 read-only, idempotent tool with 100% schema coverage and no output schema, the description covers the key operational concerns: what it returns, how it differs from catalog-based lookups, and the reliability caveat. It could mention whether non-Apple URLs need storefront, but the schema already covers that.

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 description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds the semantic context that the feed is the show's own server and that Apple IDs resolve via storefront, but it doesn't need to compensate for schema gaps. Baseline 3 is appropriate here.

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 states a specific verb ('Fetch and parse'), a precise resource ('a show's RSS feed'), and the key distinction from Apple's catalog. It clearly differentiates the tool from siblings like get_podcast or get_feed_episode by emphasizing the complete record including Podcasting 2.0 fields.

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 explicitly contrasts with Apple's catalog and notes the feed is the show's own server. It names the alternative (Apple's catalog) but doesn't name a specific sibling tool; still, the context of when to use this tool versus catalog-based tools is clearly implied and sufficient. The 'Takes an RSS URL, an Apple id, or an Apple Podcasts link' line gives immediate input guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral detail beyond those annotations by specifying the returned content (complete show notes, audio URL, chapters, transcripts) and explaining why the full notes matter. No contradiction with annotations.

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?

Two sentences, no filler. The first sentence front-loads the action and result; the second adds usage context and supporting rationale. Every phrase earns its place.

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?

Despite no output schema, the description explicitly states the return contents, and the input schema documents all four parameters with constraints and formats. Combined with safety annotations, this is sufficient for an agent to select and invoke the tool correctly.

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 description coverage is 100%, so parameters are already fully documented in the schema. The description's mention of 'by title, guid or episode number' restates the episode property description without adding new meaning. Baseline 3 is appropriate because the schema carries the parameter semantics.

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 ('Find one episode') with a clear resource and scope, enumerates lookup keys (title, guid, episode number), and specifies the full payload (show notes, audio URL, chapters, transcripts). It clearly differentiates from listing-like siblings by emphasizing single-episode retrieval with complete content.

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?

Explicitly states when to use: 'Use this when a listing gave a truncated description and the full notes matter.' It gives a concrete decision rule, though it does not name alternative sibling tools or state when not to use it. This is clear context without explicit exclusions.

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

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

Annotations already cover safety (read-only, idempotent, non-destructive), and the description adds useful non-annotation behavior: it requires Apple Podcasts Connect credentials and identifies the data source. It does not disclose output format or pagination, but for a safe read operation this is a reasonable level of disclosure. No contradiction with annotations.

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?

Three sentences, each earning its place: what the tool returns, why the metric matters, and what credentials are needed. The core definition is front-loaded and there is no repeated schema or annotation information.

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, optional-parameter read with rich schema coverage and read-only annotations, the description provides the source, the metric, and the auth prerequisite. It could be slightly more explicit about the expected response shape (e.g., a series of counts per reporting period) since there is no output schema, but the description covers what an agent needs to call it correctly.

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 description coverage is 100%, so the schema already documents date and date_type formatting, enums, and defaults. The description only adds the generic 'reporting period' context, which does not materially improve parameter understanding. This matches the baseline for high schema coverage.

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 states a clear resource ('follower numbers for your show') and scope ('across a reporting period') sourced from Apple's content performance report. It is unambiguous, but unlike a 5 it does not explicitly name sibling tools or exclusion conditions to differentiate it from get_top_shows or get_show_analytics.

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 implies a monitoring use case by calling followers a leading indicator for rank changes, and it states the credential requirement. It does not explicitly specify when to choose this tool over alternatives such as get_top_shows, find_chart_position, or get_show_analytics, nor any when-not-to-use conditions.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond that: episodes are locally identified, return complete show notes, and return the whole cached transcript excerpt rather than a trimmed version. This gives the agent meaningful expectations about scope and data source.

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?

Two concise sentences fully carry the purpose, the key behavioral distinction, and the source of the required id. There is no redundant or filler content, and the important 'in full' distinction is front-loaded.

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 one-parameter read-only getter with rich annotations and no output schema, the description is complete enough. It tells the agent what the tool returns, how to obtain the id, and how this tool differs from trimmed variants, so the agent can correctly select and invoke 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 100%: the id parameter is already described as the local episode id returned by other library tools. The description reinforces this by naming search_library, but does not add materially new meaning beyond the schema.

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 clearly states the resource (one library episode), the lookup method (local id), and the distinguishing full-content behavior (complete show notes and whole cached transcript excerpt rather than a trimmed one). This differentiates it from other library and episode tools without needing to inspect schemas.

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 gives clear context on when to use this tool: when you already have a local episode id from search_library or other library tools and want the full episode content. It does not explicitly name alternative tools for trimming or for non-library episodes, so it stops short of full when/when-not guidance.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior; the description adds context beyond them by listing the returned fields and explaining that the RSS feed URL is the route to the full episode backlog. This gives the agent a clear model of what the call returns and how it connects to another tool.

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 compact and front-loaded: it states what the tool returns, then gives the input forms, then closes with the useful next-step pointer. Every sentence earns its place with no repetition or fluff.

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 read-only lookup with two well-documented parameters and no output schema, the description is complete: it explains what is returned, what input is accepted, and how to continue to episode data. The storefront nuance is already handled by the schema, and annotations cover the safety profile.

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?

The schema already covers both parameters at 100%, including the show id/URL formats and storefront behavior. The description's mention of an Apple id or pasted URL reinforces the schema but does not add meaningfully new parameter-level detail, so the baseline 3 is appropriate.

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 clearly identifies the resource ('one show') and gives a specific verb frame ('Get one show from the catalog'), then enumerates exactly what the full catalog record contains. It differentiates itself from episode-level siblings like get_feed by explicitly positioning this tool as the entry point for the episode backlog.

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 the concrete precondition for use: the caller must have an Apple id or a pasted Apple Podcasts URL. It also recommends get_feed for the episode backlog. It does not explicitly name search_podcasts or get_show_profile as alternatives, so it stops short of full when-not-to-use guidance.

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

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

Annotations already mark this as read-only, idempotent and non-destructive, so the description adds real value by explaining Apple's moving recent-window behavior and the limit caveat. It discloses data-source quirks rather than merely restating the operation. No contradiction with annotations.

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?

Three sentences with no filler: purpose, behavior caveat, and alternative are each front-loaded and distinct. Every sentence earns its place and the most important scoping information comes first.

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 list tool with fully documented parameters and a rich behavioral caveat, the description covers what the tool returns, how to request it, and when to choose a different tool. No output schema exists, but the 'recent episodes... newest first' statement gives sufficient return-context for invocation.

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 100% and the parameter descriptions already explain show formats, limit range, and storefront behavior. The description adds context about the feed URL for the alternative but no parameter-level detail beyond the schema, so the baseline 3 is appropriate.

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 opens with a specific verb and resource: recent episodes for a show from Apple's catalog, newest first. It also distinguishes the tool from get_feed by clarifying this is the recent-window view, not the full back catalogue. The 'one show' framing separates it from cross-show siblings like list_recent_episodes.

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?

Explicitly states when to use this tool (recent window for one show) and when not to: 'For every episode a show has ever published, use get_feed with the feed URL from get_podcast.' It also warns that a short list is Apple's limit, not the show's history, which is actionable guidance for interpreting results.

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

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

Annotations already mark the tool read-only and idempotent, and the description adds substantial behavioral detail: no cross-storefront aggregation, Apple's 50-per-page and page-10 ceilings, per-storefront request cost, and a prompt-injection warning about other people's review text. This goes far beyond what annotations or the schema provide.

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?

Three sentences, no filler: return contents, key constraints, and a safety warning are all included and front-loaded. Every sentence earns its place.

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?

Despite no output schema, the description tells the agent what fields to expect, how pagination behaves, what per-storefront scope means, and how to treat untrusted review text. That is enough for correct invocation and result handling.

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?

The input schema already has 100% descriptive coverage, so the baseline is 3. The description adds useful operational nuance beyond the schema, especially that storefronts are separate passes and hit a rate-limited API, plus the hard 500 ceiling that applies per storefront.

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 names the resource — listener reviews for a show — and the returned fields (rating, title, full text), which clearly separates it from get_review_summary and other show-level tools. The tool name and title reinforce this as a targeted retrieval action.

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 gives clear context: reviews are per storefront, non-aggregated, capped at 500, and should be summarised rather than obeyed. It doesn't explicitly name alternatives like get_review_summary, but the 'do not aggregate' and 'full text' framing implies when raw reviews are needed.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructiveness. The description adds valuable behavioral context beyond annotations: the average is over recent reviews rather than the lifetime rating Apple displays, and these two values can differ. This warns the agent about an important semantic quirk.

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?

Three sentences, each earning its place: the core output, the use case, and a crucial caveat. The most identifying information is front-loaded, and there is no repetition of schema details or generic filler.

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?

Given no output schema, the description adequately explains what the tool returns (counts and averages, per storefront and combined, no review text) and highlights the recent-reviews caveat. It is complete enough for an agent to select and invoke the tool correctly, though it does not enumerate exact response fields.

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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description reinforces the notion of counts and averages and the per-storefront grouping, but it does not add meaning beyond what the schema already states. Baseline 3 is appropriate.

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 states a specific verb and resource ('Rating counts and averages for a show') and clearly distinguishes the tool from sibling review tools by emphasizing 'without returning the review text.' It also explains the per-storefront and combined breakdown, leaving no ambiguity about what the tool produces.

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 gives clear when-to-use guidance: use this to assess where a show is loved before spending a larger call on review bodies. It implies the alternative (get_reviews) and the advantage of this tool, though it does not name the sibling explicitly or state when not to use it.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuine value beyond the annotations: listener counts are device-based, not unique people, and credentials are required — a material caveat that changes how an agent should interpret results. No contradiction with 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.

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

Three sentences, each earning its place: return value and source, a critical data-interpretation caveat, and a prerequisite. The purpose is front-loaded. The caveat sentence is slightly long but contains high-value information that justifies its length.

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?

With no output schema, the prose must convey what the agent will receive, and it does — plays and listener counts, scoped to one reporting period. The date-lag and default behavior live in the schema, safety in the annotations, and credentials in the description. For a read-ony analytics query with simple parameters, this is complete enough; only a structured return-shape description is missing.

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 description coverage is 100%, and the date parameter already carries rich semantics (YYYYMMDD/YYYYMM formats, the three-day default, and Apple's publishing-lag rationale). The description adds only the 'one reporting period' framing and nothing new about constraints or formats, so the schema does the heavy lifting. Baseline 3 is appropriate.

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 states a specific resource and scope: 'Plays and listener counts for your show over one reporting period, from Apple Podcasts Connect.' The title 'Show-level listening' and the phrase 'your show' distinguish this from episode-level analytics tools like get_episode_analytics. It doesn't explicitly name a sibling or state what it is not, so it stops short of a 5.

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 context for when to use it is implied: show-level listening metrics from Apple Podcasts Connect, with the prerequisite spelled out ('Needs Apple Podcasts Connect credentials'). However, with 24 siblings including easily confused tools like get_episode_analytics and get_analytics_report, there is no explicit routing guidance or mention of alternatives.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds a meaningful behavioral trait beyond that: 'Each part fails independently, so a missing piece is reported rather than losing the rest.' This tells the agent how partial failures are handled. No contradictions.

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?

Three sentences with no redundancy: first enumerates scope, second tells when to reach for it, third discloses failure behavior. The title reinforces the value propisition. Every sentence earns is place.

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?

Even without an output schema, the descrition lists the bundled result categories and the partial-failure contract, which is sufficient for an agent to understand what the call returns. The remaining gap—exact return shape and parameter interations—is minor given full schema coverage and read-only annotations.

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 description coverage is 100%; the schema already documents show, reviews, storefront, and storefronts with types, defaults, and effects. The description itself adds no param-specific semantics, so it earns the baseline for high schema coverage.

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 names the exact resource ('one show') and the specific data dimensions returned: catalog record, storefront ranks, listener ratings, publishing frequency, and transcripts. It also explicitly frames the tool as the composite answer for 'tell me about this show', distinguishing it from single-purpose siblings.

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?

It provides a clear trigger condition: use when the question is 'tell me about this show' or 'how is this show doing' and the answer needs all these dimensions. It lacks explicit when-not-to-use wording or named alternatives, but the context is unambiguous enough for an agent to select it.

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

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

Annotations already signal readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral detail beyond that: the chart is Apple's own weighted ordering, moves slowly, is capped at 100, and genre filtering is applied to the overall chart rather than requesting a different chart. This genuinely helps an agent predict behavior.

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 compact and front-loaded. The first sentence states the core purpose, and each subsequent sentence adds a distinct relevant fact: weighting, slow movement, cap, and genre behavior. There is no repetition or filler.

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 read-only chart tool with three documented parameters and no output schema, the description covers all the key non-obvious aspects an agent needs: ordering method, cap, per-storefront behavior, genre-filter semantics, and the absence of genre charts. Nothing important seems missing.

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 description coverage is 100%, so the schema already documents each parameter. The description adds meaningful context: Apple caps results at 100, storefronts are country-specific and can change the answer, and genre filtering filters the overall list rather than selecting a separate chart. This enriches the schema's parameter explanations.

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 states exactly what the tool does: returns Apple's live Top Shows chart for one storefront, ranked. It goes beyond a generic statement by explaining Apple's own ordering, weighting, the 100-show cap, and the per-country nature, which distinguishes it from any chart-like siblings.

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 gives clear context on when this chart is appropriate: it is Apple's single overall per-country chart, and there is no separate genre chart. It explicitly warns that genre filtering only filters this list. It does not name alternative sibling tools, but the caveat about genre charts provides useful when-not guidance.

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

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

Annotations already cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the bar for added value is context beyond safety. The description adds that the chart is 'live' and 'moves far faster,' signaling volatile results across calls, and discloses the entry shape (episode id plus owning show). This enriches the annotations without contradicting them.

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?

Three sentences, each earning its place: the first names the resource, the second explains differentiation and usage value, the third states the return payload. The core purpose is front-loaded before the comparative context. No filler or repetition of schema content.

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 read-only tool with rich annotations and fully covered schema, the description is nearly complete. It even compensates for the missing output schema by stating that entries carry episode id and show. The only minor gap is that the temporal window of 'trending' is unspecified, but 'live' largely covers this. An agent has enough to select and call the tool correctly.

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 description coverage is 100%, so the baseline of 3 applies; limit and storefront are already fully documented in the schema. The description adds marginal reinforcement by noting the chart is per-storefront, which aligns with the storefront parameter, but adds no new syntax or format details. It does not need to compensate for any coverage gap.

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 states a specific verb and resource: it retrieves Apple's live Trending Episodes chart for one storefront. It actively differentiates from a sibling by contrasting with Top Shows, and clarifies the granularity (episode-level rather than show-level). An agent can tell this apart from get_top_shows, find_chart_position, and list_recent_episodes without opening the schema.

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 gives clear context for when to choose this tool: it is the better signal for what a topic or guest is doing right now because a single episode can chart without its show ranking. It names the alternative (Top Shows) and explains why it differs. However, it stops short of an explicit when-not or explicit routing to other siblings such as find_chart_position, so it earns a 4 rather than a 5.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond those hints: on Mac, play data often is absent because listening progress does not sync, so the tool may report unusable data. This is exactly the kind of caveat an agent needs.

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?

Two sentences with no filler. The first sentence front-loads what is counted; the second explains when to call it and warns about a platform-specific limitation. Every sentence carries meaningful guidance.

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 zero-parameter, read-only statistics tool, the description fully covers what it returns, when to use it, and a critical data-quality caveat. No output schema is present, but the description lists the counts sufficiently for an agent to interpret results.

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?

The tool has zero parameters, so there is no parameter semantics burden. The description still clarifies what the output counts represent, which is useful since there is no output schema.

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 clearly states the tool counts specific metrics for the local library (shows, episodes, saved/bookmarked/downloaded items), and the title reinforces the distinct purpose. This distinguishes it from sibling tools like search_library or list_recent_episodes that list or search rather than summarize.

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?

Explicit guidance is given: 'Call this before drawing any conclusion about listening habits,' and the Mac-specific caveat helps agents decide when the data may be unreliable. It does not explicitly name alternative tools, but the context is clear enough for selection.

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

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

Annotations already declare readOnly and idempotent, so the safety profile is covered. The description adds genuinely useful behavioral context beyond those hints: the data is fetched live rather than hardcoded, and the returned categories are Apple's filing categories, not chart categories. This helps an agent avoid stale or wrong assumptions.

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 compact and every sentence earns its place: what the resource is, how it is fetched, how the ids connect to another tool, and a crucial limitation. It is front-loaded with the core purpose and does not waste tokens.

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 read-only list endpoint with two well-documented optional parameters, the description is largely complete: it states what is returned, that it is live, and how the values relate to search. It doesn't describe the exact response envelope or whether subcategories are included by default, but the input schema covers the top_level_only toggle and no output schema is required to infer basic shape.

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 description coverage is 100%, so the schema already fully documents storefront and top_level_only, including default behavior and country-dependence. The description adds no extra parameter-level meaning; it only relates the returned ids to search_podcasts, which is useful but not about a specific 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 identifies the exact resource ('Apple's podcast categories and their numeric ids') and the action implied by the tool name: listing the genre tree. It also distinguishes the tool from chart-oriented endpoints by explicitly stating these are not charts and no chart can be requested for a genre.

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 gives clear context for when this tool matters: the returned ids are exactly what search_podcasts uses as genre_id. It also provides a firm when-not boundary: genres are not charts and cannot be used to request charts. It doesn't name an alternative sibling for chart data, but the exclusion is explicit.

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

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

Annotations already declare safe read-only idempotent behavior. The description adds meaningful context beyond annotations by noting results come from a cached local database view reflecting the last Podcasts-app refresh, and that ordering is newest first. This helps an agent understand the tool's freshness limitations.

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 two sentences with no waste: the first states the core behavior and ordering, the second adds a crucial staleness caveat. It is front-loaded and easy to parse.

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 read-only listing tool with four optional params and no output schema, the description covers what is returned, in which order, and from which data source. The local-cache caveat is especally valuable because it prevents relying on this tool for live-feed data, and annotations already cover safety and idempotency.

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?

All four parameters have concise descriptions in the input schema, so the schema carries the full parameter-documentation burden. The tool description reinforces the overall concept but does not add parameter-specific detail beyond what the schema already provides.

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 states a specific action and resource: listing the most recently published episodes across shows you follow, newest first. It also differentiates from sibling tools like list_saved_episodes by emphasizing followed shows rather than saved episodes.

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 provides useful context: it returns the local database's view and may lag live feeds, implying it is for library-state queries rather than realtime checks. However, it never explicitly names alternatives such as get_feed or says when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Beyond that, the description usefully explains that the results come from the Podcasts app's own shortlist and that the data is not derived from synced play-position, which is meaningful behavioral context. It does not contradict 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.

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

Two focused sentences with no filler. The first sentence states the resource, and the second adds the crucial why-to-use-it context. Every sentence earns its place.

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, read-only list tool with fully documented parameters and annotations covering idempotency and safety, the description is complete enough. It provides source context, a reason to prefer it over play-position-based lists, and no critical gaps for an agent to invoke it correctly.

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 description coverage is 100% and the parameter descriptions already explain kind, full, and limit well. The description's mention of saved/bookmarked/downloaded overlaps with the kind enum without adding new per-parameter semantics, so the schema carries the parameter-documentation burden.

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 identifies the resource precisely—episodes flagged as saved, bookmarked, or downloaded in the Podcasts app—and adds a useful distinguishing nuance: this is the app's own shortlist and an explicit interest signal. However, it is expressed as a noun phrase rather than a direct verb phrase like 'List...' or 'Returns...', so the action is implied by the tool name rather than stated in the description.

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 gives a clear usage context: use this when you want the app's explicit interest signal rather than inferred play-position data, and it explicitly notes that play-position data does not sync to a Mac. It implies a contrast with siblings like list_recent_episodes, though it does not name alternatives or state when not to use the tool.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds configurable behavior tied to an environment variable and clarifies that results are a subset of all possible Apple storefronts, going beyond what annotations express.

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 short and front-loaded with the core meaning. The note about Apple operating storefronts for most countries is slightly general but still helps explain why any two-letter code may be passed elsewhere. No wasted sentences.

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 zero-parameter, read-only configuration listing tool with rich annotations, the description is sufficient to select and invoke it. It explains the source, the scope, and the configuration knob. A return-format example would be nice but is not essential.

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?

There are zero parameters and schema coverage is 100%, so the baseline is 4. The description adds useful context about what the returned values represent (two-letter storefront codes) even though no parameters need explanation.

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 clearly identifies the resource (storefronts) and the specific scope (the working set this server sweeps by default, plus the configured default). This distinguishes it from the long sibling list, none of which cover storefronts.

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?

It tells the agent this is the working set, not the full list, which prevents over-generalizing. It also explains the set is configurable via APPLE_PODCASTS_STOREFRONTS. It lacks an explicit alternative tool reference, but no sibling tool offers the same capability.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond those hints: the sort order (followed shows first), the scope limited to this Mac, and the guarantee that each result carries both a local id and Apple's catalog id. These are return-behavior details the annotations cannot convey.

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?

Three sentences, each earning its place: scope and ordering, the id pairing, and the bridge to public tools. The core capability is front-loaded in sentence one. Slightly verbose in the middle sentence with repeating 'which the other library tools take' / 'which every public tool here takes', but no wasted words overall.

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-optional-param read-only listing tool, the description is largely complete: scope, ordering, result contents, and the cross-tool usage pattern are all present. There is no output schema, and the description gives only a minimal account of each item's fields, leaving the agent to guess at additional metadata. This minor gap prevents a 5.

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 description coverage is 100% — limit and followed_only are already documented with their ranges and defaults. The description adds no parameter-specific guidance beyond the 'followed shows first' ordering, which relates to sort behavior rather than to the followed_only filter. Baseline 3 is appropriate since the schema carries the param semantics fully.

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 identifies the resource (every podcast in the Apple Podcasts library on this Mac) and the behavior (listing, with followed shows first), which distinguishes it from the public-catalog sibling tools. It explains the two id types the results carry, though the verb is implied rather than stated and no sibling is named explicitly, so it stops short of full disambiguation.

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 implies a workflow — obtain the local id from this tool, then hand it to the other library tools, and use the catalog id to cross over to charts, reviews, and feed. However, it never names alternatives like search_library or list_saved_episodes, and states no exclusion conditions, so an agent must infer when this tool is the right choice versus its library siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint: false, so no contradiction exists. The description adds useful behavioral context beyond annotations: the episode id is optional, the storefront is returned, and Apple share URLs hide the episode id in a query parameter. This helps set expectations without overpromising.

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?

Two sentences, no filler. The first sentence states the action and outputs; the second explains why this tool exists relative to the rest of the API. Every sentence earns its place.

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 single-parameter, read-only resolver with no output schema, the description is complete enough. It covers the input, the various return values, the optional nature of the episode id, and the storefront, and gives enough rationale for an agent to know when to call it. No critical missing context for correct invocation.

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 description coverage is 100%, and the input schema already documents that 'url' may be an Apple Podcasts URL or a bare numeric id that passes through. The description reinforces the URL-to-id bridge but adds little parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.

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 ('Take ... and return') and clearly names the resource (an Apple Podcasts URL) and the outputs (show id, episode id, storefront). It also distinguishes this tool from every sibling by noting that all other tools are keyed by id, making its unique role unmistakable.

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 clearly states when to use the tool: when someone pastes an Apple Podcasts URL, and explains why this step is needed before using the id-keyed sibling tools. It does not name specific alternatives or exclusions, but the context is strong enough that an agent would know this is the bridge for link-to-id conversion.

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

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

Beyond the readOnly/idempotent annotations, the description discloses meaningful behavioral traits: Apple's episode index is shallower than its show index, skews recent, and may miss indexed shows' older episodes. This helps the agent set expectations and choose alternatives.

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?

Three purposeful sentences: the action, the use case, and the limitation/alternative. The description is front-loaded and every sentence earns its place without redundancy.

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 read-only search tool with full parameter documentation and no complex output schema, the description is complete enough. It covers what the tool does, when to use it, and the key caveat about indexing depth, leaving no critical information missing.

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?

The schema already documents all three parameters completely, so the baseline is 3. The description adds real value for the query parameter by advising that including the show name narrows results because Apple ranks episode matches loosely. It does not add meaning for limit or storefront, but those are already well covered by the schema.

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 states a specific verb and resource: searching Apple's catalog for individual episodes across all shows. It clearly distinguishes itself from related tools like search_podcasts and get_feed by focusing on episodes rather than shows or feeds.

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?

It explicitly says when the tool is useful (finding topic coverage or guest appearances) and gives a concrete exclusion: older episodes may not surface because the episode index is shallow, and the complete record is available via get_feed. This routes the agent to the right alternative.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral details: results distinguish title, notes, or transcript matches, and the transcript results are excerpts, not full transcripts. This helps set expectations about coverage and interpretation of results.

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 four focused sentences that all add value: it states the scope, explains the intended use case, clarifies what match types mean, and warns about excerpt limitations. It is front-loaded and lacks fluff.

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?

The schema covers all parameters and the annotations cover safety characteristics. The description covers the key behavioral expectations, such as match-type reporting and excerpt-only transcripts. Without an output schema, it could specify the exact response structure a bit more, but it gives enough for an agent to select and invoke the tool correctly.

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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not discuss parameters directly, but it does add context about transcript excerpts being cached and partial, which is relevant to understanding the results. No additional parameter semantics are needed.

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 states a spécific verb ressource and scope: keyword search across every episode and show in the library, including titles, show notes, and transcript excerpts. It clearly answers the user's typical query, 'which episode was that in', and its emphasis on library-wide transcript search differentiates it from sibling search tools.

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 gives clear context for when to use the tool: when the user wants full-text search over everything they follow and needs to locate an episode by keyword. It does not explicitly name alternatives or state when not to use it, but the intended usage is unambiguous.

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

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

Beyond the read-only/idempotent annotations, it discloses that no account is needed, results are storefront-specific, and the tool returns Apple id plus RSS feed URL. This adds meaningful behavioral context and does not contradict any annotation.

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?

Three sentences, each earning its place: search scope, provenance/account requirement, and return-value significance. It is front-loaded with the action and avoids redundant restatement of the title.

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 search tool with no output schema, it tells the agent exactly what comes back and why that matters downstream. With rich annotations and a fully documented schema, nothing critical for selecting or invoking this tool is missing.

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 description coverage is 100%, so the schema already documents all five parameters, including the storefront default, enum meanings, and range. The description adds only a tiny bit of behavioral context, so the baseline 3 is appropriate.

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 states a specific verb and resource: 'Search Apple's podcast catalog for shows by name, topic, host or keyword.' It also clarifies what the tool returns (Apple id and RSS feed URL), making it clearly distinct from episode-focused and library-focused siblings.

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 gives useful context: same index as the Podcasts app, no account needed, results differ by storefront, and returned IDs/feed URLs are what other tools consume. It does not explicitly say 'use search_episodes for episodes' or list exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: 'Contacts nothing and costs nothing,' reassuring the agent that calling it is side-effect-free and cheap. It also clarifies the availability check is current ('right now').

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?

Three sentences with no wasted words. The core reporting function is front-loaded, followed by concrete usage guidance and a cost/contact note. Every sentence earns its place.

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, zero-parameter status tool, the description is complete: it states what is reported, when to use it, and what side effects to expect. Even without an output schema, an agent can infer that the result will indicate availability of the four named sources.

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?

The tool has zero parameters and 100% schema description coverage, so there is nothing to explain beyond the baseline. The description's enumeration of the four checked sources adds semantic context about what the status result will relate to.

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 ('Report') and a precise resource ('which of the four Apple Podcasts sources are available right now'), enumerating each source. It clearly distinguishes itself from the sibling tools by being the only status/diagnostic tool.

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?

Provides explicit when-to-use guidance: call first if a tool has failed, or before planning work that depends on the library or owner analytics. This gives an agent a clear decision rule for invoking it.

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