Orca MCP

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

Annotations already cover read-only, idempotent, open-world, non-destructive, so it's safe. The description adds that it 'tells you the exact next call', which is useful guidance on how to chain subsequent calls. But it doesn't specify what happens on invalid ids, though openWorldHint implies graceful handling. No contradiction.

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, each with a distinct purpose: what it does, when to use it, and outcome. No waste, front-loaded with the primary purpose.

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 the tool's simplicity (single param, no output schema), the description is complete. It explains the output fields (TMDB id, media type, title, year) and the use case. Minor gap: doesn't mention error handling for invalid ids, but openWorldHint mitigates that. For a simple tool, this is nearly comprehensive.

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 description reinforces the format 'tt0111161'. The description adds value by tying the parameter to the tool's purpose, making it highly useful for agents. No gaps.

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 resolves an IMDb id to TMDB id, media type, title, and year. This is specific and distinguishes it from siblings like movies_search, which are general lookups.

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 'Use when you only have an IMDb link/id and need to call the other tools', providing clear when-to-use guidance and hints at the alternative (other tools) that require TMDB id. This is excellent routing.

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, openWorldHint, and non-destructive behavior. The description adds valuable context by identifying Fanart as the source and specifying that exactly one identifier (title, TMDB id, or IMDb id) should be provided, which informs the caller's expectations 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?

Three concise sentences front-load the tool's purpose and output types, then give usage guidance and an explicit exclusion. There is no filler or redundant 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?

The description covers the tool's purpose, source, accepted identifiers, and when to avoid it. It does not mention the media parameter or default behavior, but the schema fully documents those, and the tool is simple enough that no further context is required.

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 each parameter is already documented. The description adds the high-level rule 'provide only one' and maps identifier types to parameters, but this mostly reinforces what the schema already states. No new syntax or format details are introduced 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 identifies the tool's function: retrieving high-quality artwork (poster, backdrop, logo, banner) for a film or show. It also distinguishes itself from metadata retrieval by explicitly naming movies_details as the alternative, which is useful given the large sibling list.

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 states when to use this tool ('when the user explicitly wants images/artwork') and when not to ('Do NOT use for metadata'), pointing to the correct sibling. This is direct and leaves no ambiguity about 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety and idempotency are covered. The description adds behavioral context beyond these: it specifies the content of the response (release order, per-part runtime, total runtime, ratings, posters, streaming with region) and the edge-case behavior for standalone films. This adds meaningful value 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?

The description is three sentences long, front-loaded with the core purpose and immediately followed by input constraints and the use case. Every sentence adds value: the first defines the output, the second specifies input alternatives, and the third states the use case and edge case. No filler or redundant repetition of schema info.

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 the tool has 6 parameters, no output schema, and is a read-only lookup, the description covers the essential aspects: what it returns (viewing order with runtime, ratings, posters, streaming), how to invoke it (with one of three identifiers), and the edge case (standalone films). It could be more explicit about the response structure or formatting, but for a query tool of this complexity, it is sufficiently complete. The annotations cover safety and idempotency, so the description doesn't need to repeat those.

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 each parameter is documented in the schema. The description adds critical usage semantics beyond the schema: it clarifies the mutual exclusivity of query, collection_id, and tmdb_id, and explains that 'query' resolves a collection from a film title. This enriches parameter understanding, especially the 'media' parameter which only matters with tmdb_id. The description compensates for any ambiguity 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 states a specific purpose: providing franchise viewing order with runtime, ratings, posters, and streaming availability. It clearly distinguishes this from sibling tools like movies_details (single movie details) and movies_search (search) by explicitly targeting 'in what order do I watch X' questions. The verb-resource combination is precise and unambiguous.

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

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

The description explicitly states the intended use case ('Use for "in what order do I watch X" questions') and specifies input constraints: 'provide only one of query, collection_id, tmdb_id'. It also covers the edge case of standalone films returning an empty result with an explanation. This gives an agent clear guidance on when to select this tool over 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 indicate read-only, idempotent, and non-destructive behavior. Description adds the practical workflow of feeding the resulting ID into movies_discover, enhancing transparency.

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 with a clear, front-loaded purpose and practical guidance. Every word adds value; no 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?

Comprehensive for a simple resolver tool: states purpose, provides examples, and explains downstream integration. Could benefit from mentioning response format or error handling, but this is minor given the simplicity.

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%, so parameters (query, limit) are well-documented. Description reinforces the purpose of 'query' with examples and hints at limit usage, but adds minimal 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?

Clearly states it resolves studio names to TMDB company IDs, with specific examples (A24, Pixar, Netflix). Differentiates from siblings like movies_search and find_by_external_id by focusing on company ID resolution.

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?

Explains when to use it: 'Pass an id to movies_discover as company for best of studio X questions.' Provides clear usage context but no explicit exclusions or alternatives for 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 declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context by explaining that unranked titles return empty and that this means 'not in either list' rather than 'does not exist', which aligns with and reinforces the openWorldHint.

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: one for the core purpose, one for usage triggers, and one for the empty-result caveat. The most important information 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 lookup tool with no output schema, the description covers purpose, usage, and an important edge-case interpretation. It does not specify the exact output shape, but 'side by side' sufficiently implies the rank comparison.

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 fully documents the single required 'query' parameter with an example ('godfather'). The description does not add additional parameter meaning beyond referring to a film title, so the schema carries the load and a baseline score 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 clearly states the resource: a film's rank in both the IMDb Top 250 and Letterboxd Top 500, shown side by side. It differentiates this tool from general ratings or search tools by focusing on list membership and rank.

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 to use this for 'what rank is X' or 'is X in the top 250' questions, which gives concrete triggers. It also sets a boundary by saying only ranked films are covered, though it does not name alternative sibling tools for unranked or non-existent titles.

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, covering the safety profile. The description adds the dependency on a prior movies_search id and the warning not to guess IDs, but does not disclose much beyond the annotations. No contradiction exists.

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 carry both the tool's purpose and its key prerequisite. The content list is front-loaded, and the usage warning is concise. No filler or redundant phrasing.

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 with no output schema, the description enumerates the major return fields (plot, genres, ratings, cast, director, trailer, awards, IMDb id, poster) and states the required precursor action. This is sufficient for an agent to select and call the tool correctly. Minor gaps like response format or pagination are not critical for a single-item details tool.

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 provides 100% coverage, describing id as 'Numeric TMDB id from movies_search (required)', media as 'movie or tv', and language as ISO language for plot/tagline. The description reinforces the id-source rule but does not add new parameter semantics beyond the schema. 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 states this tool returns 'Full details for one movie or TV show' and enumerates specific content: plot, genres, ratings, cast, director, trailer, awards, IMDb id, poster. This distinguishes it from sibling tools like movies_ratings or movies_artwork by positioning it as the comprehensive details endpoint.

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 explicit usage context: 'Use after movies_search gave you an id' and warns 'Do NOT guess ids - search first.' This is strong guidance on when to call the tool)Skip. It does not explicitly name alternatives for edge cases like ratings-only lookups, so it misses the 'when-not/alternatives' part 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 readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context beyond that: it warns that few-vote titles are noisy and that min_votes filters them, and it explicitly instructs the agent to warn the user when low_votes:true is present. 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?

The description is tightly packed: it starts with the core purpose, then gives the canonical use case, clarifies the important min_votes noise issue, routes new-release queries to the right approach, and finishes with a clear non-use instruction. Every sentence earns its place; no filler or repetition.

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 tool with 11 optional parameters and no output schema, the description covers the major contexts: filter-based discovery, data-quality caveats, new-release handling, and sibling tool routing. It does not describe the return shape, but that is largely implied and the annotations carry the safety model. Slightly more could be said about pagination or language, but overall it is sufficiently complete for an agent to reason about when and how to use 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 description coverage is 100% and the parameter descriptions are already rich (e.g., min_votes explains the default and the brand-new-release adjustment). The tool description restates some of this and provides a usage example, but it does not add substantial new parameter meaning 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: 'Find movies or shows by filters: genre, year, minimum rating, minimum votes, sort order.' It immediately distinguishes the tool from siblings by explicitly stating 'Do NOT use for title search (use movies_search)' and pointing to movies_trending for hot content, so an agent can tell them apart without opening 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?

It gives an explicit when-to-use pattern: 'Use for "action movies after 2020 rated above 7" style questions.' It also gives conditional guidance for brand-new releases (sort newest with min_votes 0-50, or movies_trending) and an explicit exclusion for title search with the named alternative. This is unambiguous and actionable.

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 read-only, idempotent, non-destructive behavior. The description adds the core semantic behavior (theme word to keyword ids) and the intended downstream use, which is meaningful context beyond the annotations. 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 tight sentences: the first states the purpose, the second the downstream usage. Every word earns its place, with no filler or repetition.

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 lookup with read-only annotations, the description is complete: input meaning, output concept, and downstream destination are all covered. The lack of an output schema is mitigated by saying the result is keyword ids to pass to movies_discover.

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%: both 'query' and 'limit' are fully documented in the schema. The description's examples reinforce the meaning of 'query' but do not add substantive parameter 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 verb and resource: 'Resolve a theme word to TMDB keyword ids', with concrete examples ('zombie', 'heist', 'time travel'). It also identifies the downstream role in movies_discover, which clearly separates this keyword-resolution tool from the sibling movie lookup 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?

It tells the agent when to use the tool: when it has a theme word and needs TMDB keyword ids. It also explicitly says to pass the resulting id to movies_discover, giving clear downstream context. It does not mention exclusions such as using movies_search for title-based queries, so it lacks full 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 declare readOnly, idempotent, and non-destructive. The description adds a key behavioral detail: returns only top 15 credits by votes, not everything. This is valuable context that informs the agent about response scope and potential incompleteness. 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 concise sentences: first states what the tool provides, second gives usage examples and a critical limitation. No filler, front-loaded with the main purpose, and 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?

Given no output schema, the description covers return contents (bio, photo, credits) and the top-15 limitation. It doesn't address ambiguous names or pagination, but for a simple person lookup this is adequate. With annotations covering safety and schema covering parameters, the description is sufficiently 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 has 100% coverage with clear descriptions for both 'query' and 'language'. The tool description adds no extra parameter information beyond what the schema already provides, so 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?

States clearly that it returns person info (bio, photo, acting/directing credits) and gives explicit example queries like 'what else did the Dune director make'. This distinguishes it from movie-centric tools like movies_details or movies_search. The resource and scope are unambiguous.

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

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

Provides explicit use cases: actor filmography and director questions. It also notes the 'top 15 credits' limitation, implying when a more complete result might be needed. However, it doesn't name alternative tools explicitly or state when NOT to use it beyond that limitation.

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 genuine value by disclosing the entity-resolution behavior ('Resolves all ids internally') and the mutual-exclusivity constraint ('provide only one'). No contradiction with annotations — a ratings query aligns with read-only.

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 and roughly 50 words with zero waste. The data scope is front-loaded, followed by id options and usage context. The final sentence ('this is the entity-resolution showcase') is mildly promotional but earns its place by signaling the tool's distinguishing capability.

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?

Moderate complexity with 5 optional params but a simple lookup purpose. With no output schema, the description adequately hints at return values by naming the rating sources. It covers what data comes back and how to invoke it. The only minor gap is not describing ranking position semantics or pagination, which is low-value for a ratings tool.

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%, so each parameter is already documented. The description adds value beyond the schema by clarifying the mutual exclusivity of query/id/imdb_id ('provide only one') and noting that id resolution happens internally, which helps the agent understand which parameter to supply. This exceeds the baseline of 3.

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 verb and resource ('Ratings for one film across sources') and enumerates the exact data returned (TMDB score, IMDb score/votes, Top 250 and Top 500 ranks). This clearly distinguishes it from siblings like movies_details, movies_reviews, and movies_search — an agent can tell what this tool returns without opening any 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?

Gives explicit usage context: 'Use for how is X rated everywhere questions' and explains the entity-resolution behavior. However, it does not name alternative siblings or state when NOT to use it (e.g., when to prefer movies_details for full metadata). Clear context but no 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 declare readOnlyHint=true and idempotentHint=true, and the description adds context about the returned content (author, rating, date, excerpt, link). It does not contradict annotations. It lacks pagination or sort details, but that is minor given the schema documents limit.

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 with no filler. The purpose and key usage rule are front-loaded, and the sibling alternative is mentioned briefly. 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?

Given the tool's simplicity, the description is complete: it states the resource, the identifiers, the output fields, and the sibling alternative. Pagination behavior is covered by the schema's limit parameter, and annotations cover safety. Nothing critical 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 coverage is 100%, so the description adds little parameter-specific meaning beyond what the schema already provides. The 'provide only one' rule is already embedded in the query parameter description. The description adds no extra semantics for the other 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?

The description clearly states the tool returns user reviews for one movie or show, lists the specific fields (author, rating, date, excerpt, link), and distinguishes itself from movies_ratings by noting ratings alone live there. This gives an agent a precise, unambiguous purpose.

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 to use for 'what do people say about X' questions and directs ratings-only queries to movies_ratings. It also instructs to provide only one of title, TMDB id, or IMDb id, which is essential for correct invocation.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating operation. The description adds value by indicating the return fields (id, title, year, rating, poster), which is useful context beyond the annotations. While it doesn't mention things like pagination or rate limits, the annotations cover the safety profile, so this is a strong score close to the maximum.

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 succinct and well-structured: it opens with the core purpose in the first sentence, lists return fields in the second, and closes with explicit exclusions in the third. Every sentence adds value, and there is no fluff. The key information is front-loaded, making it easy for an agent to parse quickly.

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 the tool's moderate complexity (5 parameters, all documented in the schema) and the presence of full annotations (readOnly, idempotent, non-destructive), the description is complete for correct invocation. It covers the what, when, and why, and the schema covers the parameter specifics. The only minor absence is discussing pagination behavior, but that is a small gap against a well-specified schema.

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%, meaning all five parameters (query, type, page, limit, language) have clear descriptions in the schema itself. The tool description doesn't add much beyond that—it focuses on the overall purpose and return value. While the description mentions 'partial titles' for query, which the schema also includes, the schema already does the heavy lifting, so a 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 clearly states that the tool searches movies, TV shows, and people by title or keyword, and lists what it returns (id, title, year, rating, poster). It distinguishes itself from siblings by explicitly excluding ranked-list questions (movies_compare_lists) and episodes (tv_episodes), making it stand out among the many search-related 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 provides explicit guidance on when to use this tool: when the user asks about a film, series, or actor, or when a TMDB id is needed for another tool. It also states when NOT to use it, naming specific alternatives (movies_compare_lists for ranked lists, tv_episodes for episodes). This is exactly the kind of routing guidance that helps an agent select the right 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context: it merges similar + recommendations and deduplicates results, and stresses that only one identifier should be provided. These details go beyond the annotations and help set expectations.

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: purpose, identifier constraint, and usage guidance with an explicit alternative. No fluff, and the critical info 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 6-parameter tool with no output schema and annotations already covering safety, this description is complete. It covers what it does, when to use it, the identifier exclusivity rule, and what to avoid. An agent has everything needed to invoke it correctly without further digging.

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%, so all parameters are already documented. The description adds the crucial exclusivity constraint—provide only one of title, TMDB id, or IMDb id—which the schema only hints at in the query field. This is a high-value semantic addition that prevents misuse.

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 verb and resource: finds films/shows similar to a given one, with a clear distinction that it merges similar + recommendations and deduplicates. It also explicitly differentiates from genre browsing by naming movies_discover as the alternative, so an agent can tell it apart from 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?

Gives explicit when-to-use (e.g., 'like Whiplash what should I watch' questions) and when-not-to-use (genre browsing, with the explicit alternative movies_discover). This is unambiguous and routes the agent correctly.

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 and destructiveHint=false, so the safety profile is covered. The description adds substantive behavioral context beyond those annotations, especially the note about low-vote new releases rarely passing rating filterscarsionate why trending is the right selection. That extra reasoning is genuinely useful.

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 short, purposeful sentences: purpose first, then positive usage guidance with a rationale, then an explicit do-not-use case with the correct sibling. Every sentence earns its place; there is no filler or repetition.

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 4-parameter, no-required-parameter tool with fully documented schemas and a clear read-only annotation set, the description covers everything needed to select and invoke it: what it returns, when to use it, and when to use something else. The lack of an output schema is not a gap for this straightforward retrieval endpoint.

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 all four parameters and their enums are already documented in structured form. The description reinforces the notion of time windows and media types but does not need to repeat parameter details; the baseline 3 applies since the schema does the heavy lifting.

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 ('trending') and a clear resource scope ('movies, shows or people, today or this week'), immediately distinguishing it from list/ranking tools. It even names the sibling it is not meant for ('movies_compare_lists'), so an agent can separate it from other movie-list tools without further digging.

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 positive triggers ('what is popular right now' and new-release questions), explains the rationale ('new titles have few votes, so they rarely pass rating filters'), and gives an explicit negative instruction with the alternative ('Do NOT use for all-time rankings (use movies_compare_lists)'). This is exactly the level of routing guidance an agent needs.

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 read-only and idempotent behavior. The description adds useful behavioral detail: content is ordered with trailers first, includes YouTube watch URLs, and accepts only one lookup key at a time.

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 compact sentences cover output content, ordering, URL format, identifier options, and the intended use case. No filler or repetition.

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 the simple read-only nature, full schema coverage, and the description's explanation of what the response contains, an agent has enough context to select and invoke this tool correctly. The absence of an output schema is adequately compensated by the description of the returned video types and URLs.

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%, so the schema carries the parameter documentation burden. The description's 'title, TMDB id or IMDb id - provide only one' mostly restates what the query and imdb_id parameter descriptions already say, adding little new semantic value.

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 precise function: returning trailers, teasers, clips, and featurettes for a single movie or show, with YouTube watch URLs. It clearly separates this media-content tool from siblings like movies_artwork or movies_details.

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 gives the intended use case ('trailer for X' questions) and constrains input to one movie/show via exactly one identifier. It does not name alternatives or 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 declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a safe read operation. The description adds the crucial note that availability changes and should be treated as a snapshot, which is valuable external context. It does not disclose pagination or rate limits, but given the annotations, this is adequate.

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, efficient, and front-loads the core purpose and the critical dependency on a TMDB id. The snapshot warning is a concise addition that 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 read-only, idempotent tool with 100% schema coverage, the description sufficiently covers what the tool does and the key caveat about data volatility. There is no output schema, so return format isn't expected, but the description doesn't mention whether results include price or link details, which could be helpful. Nevertheless, it is adequate for the tool's complexity.

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 fully describes all three parameters: id requires a numeric TMDB id from movies_search, media has enum with default, and region is a two-letter code with default. The description does not add any semantic detail beyond the schema, but since coverage is 100%, it meets the baseline.

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 that the tool finds streaming/rent/buy availability by country and provider, and it references the required input (TMDB id) and the data source (movies_search). This distinguishes it from sibling tools like movies_details or movies_search.

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 notes the need for a TMDB id from movies_search, which serves as a prerequisite. It also warns about availability changes, suggesting use as a snapshot. However, it does not explicitly contrast with alternatives like movies_compare_lists or person_watch_path, but the id requirement provides clear usage context.

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 useful behavioral context: the tool returns multiple ranked lists and that region changes output by adding subscription streaming. 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?

The description is concise and front-loads the core purpose, then adds the region-dependent streaming detail and the intended use case. Minor terminology like 'headline picks' is a little vague but does not waste space or obscure the main message.

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 tool with no output schema, the description conveys the shape of the response: multiple title lists and conditional streaming info. It covers the main decision factors (person and region) and the intended use case. It could define 'headline picks' more precisely, but the overall picture is sufficient 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 coverage is 100%, so the schema already documents all parameters. The description adds some meaning around query (a person) and region (streaming enrichment), but this is mostly redundant with the schema and does not substantially deepen parameter understanding.

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 purpose: recommending a starting point for an actor/director/crew member via multiple curated lists (starter pick, best-rated, most popular, recent). The explicit 'Use for where do I start with X' phrase makes the tool's intent unmistakable and distinguishes it from search or detail 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?

Provides clear usage context with 'Use for where do I start with X' questionsholistically. It does not explicitly name alternative tools or when-not-to-use conditions, but the intended scenario is concrete 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 declare readOnly, openWorld, idempotent, and non-destructive. The description adds a valuable non-obvious behavior: 'Dates shift - present as a planning snapshot,' warning the agent that results are time-sensitive and approximate. This is useful context beyond the schema.

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 short sentences: the core purpose, the usage examples, and the important caveat. Every sentence earns its place, and the most distinctive information is front-loaded in the first clause.

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 tool with 7 optional parameters, a fully documented schema, and strong annotations, the description covers the essential semantics: media types, date-window behavior, regional aspect, and the volatility caveat. Without an output schema, an agent might not know the response shape, but that is a minor gap given the strong schema and 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?

Schema description coverage is 100%, and the schema already documents every parameter including defaults and the tv/movie behavior. The description mentions the date window and media split but adds little semantic detail beyond what the schema provides, so 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: upcoming movies in theatres by region and shows currently on air, with an optional date window. It is immediately clear what the tool returns, though it never names or contrasts any sibling tool, so differentiation relies on the topic rather than explicit comparison.

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 user-intent examples are given ('what comes out in December', 'what is in cinemas now'), making the intended use obvious. However, it does not mention when not to use this tool or point to alternatives like movies_discover or movies_trending.

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 the safety profile is covered. The description adds useful output-field context but does not disclose behavior such as missing-result handling or language defaults; this is acceptable given the strong annotations but not especially rich.

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 tight sentences with no filler. The output fields are front-loaded, followed by the input-selection rule, making the definition easy to scan and immediately operational.

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 single-episode lookup with 100% schema coverage, the description covers the main output fields, the accepted identifiers, and the navigation coordinates (season/episode). It doesn't mention language or defaults, but those are fully specified in the schema, so nothing critical is missing 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%, so the schema already documents all six parameters. The description adds the useful 'provide only one' exclusivity constraint among id, query, and imdb_id, but otherwise does not need to repeat parameter details.

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 verb and resource: 'One episode in full' followed by a clear list of returned fields. It also specifies 'Series only,' which distinguishes it from movie or season-level tools and helps an agent separate it from the plural tv_episodes sibling.

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?

Clearly says which identifier forms can be used (show title, TMDB id, or IMDb id) and instructs to provide only one, plus season and episode numbers. It does not explicitly name sibling tools like tv_episodes or tv_season as alternatives, but the 'One episode' and 'Series only' wording makes the intended scope evident.

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, destructiveHint=false, so the safety profile is covered. The description adds useful context about what the list contains (season/episode numbers, titles, airdates, summaries) and the series-only scope. It doesn't disclose pagination or limit behavior beyond the schema, but the annotations carry the main behavioral burden.

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, all information-dense. The core purpose is front-loaded, followed by sibling routing and a scope exclusion. No wasted words.

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 list tool with full schema coverage and strong annotations, the description is complete. It covers what the tool returns, when to use it, when not to use it, and the series-only constraint. No output schema exists, but the description already names the return fields (season/episode numbers, titles, airdates, summaries).

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. The description adds a concrete example query ('breaking bad') and clarifies the query is a show title, which reinforces the schema. It doesn't add new parameter semantics beyond that, so 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: it returns an episode list for a TV series, with season/episode numbers, titles, airdates, and summaries. It clearly distinguishes itself from siblings tv_season and tv_episode by naming them and their specific use cases.

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 says when to use this tool ('breaking bad season 2 episodes' style questions), and explicitly says when NOT to use it: for one season with ratings/stills use tv_season, for a single episode with guest stars use tv_episode. It also warns 'Series only - do NOT use for movies.' This is exemplary 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds behavioral context about rejecting movies and the constraint to provide only one identifier. It does not describe the response format or what happens if no identifier is provided, but given the annotations, the added value is moderate. 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?

The description is two sentences with no fluff. It front-loads the primary output (one season in full) and lists the content fields, then immediately covers identifier selection and series-only constraint. Every sentence carries essential information, and the structure is logical and scannable.

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 description is fairly complete for a read-only tool: it lists the content returned, explains the identifier options, and notes the series-only restriction. However, it does not explicitly state that at least one of id/query/imdb_id is required (it says 'provide only one' but not that one must be provided), and there is no output schema to clarify return structure. Given the absence of an output schema, the description could benefit from mentioning the response format or a note about required identifier, making it slightly incomplete.

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 all five parameters are documented. The description adds meaningful semantic constraints beyond the schema: it clarifies that id, query, and imdb_id are mutually exclusive (provide only one) and that season is optional and defaults to the latest. This helps an agent understand the relationships and usage of parameters, which the schema alone does not convey explicitly.

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 that the tool returns one season of a TV series in full, listing specific content (episode titles, airdates, runtimes, ratings, summaries, stills). It distinguishes from movies by noting series-only, but does not explicitly differentiate from the sibling tools tv_episode and tv_episodes, though the focus on a season vs. individual episodes is implicit. The verb 'accepts' and resource 'TV series season' are specific, making the purpose clear.

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 usage context: it accepts three identifier types (show title, TMDB id, IMDb id) and instructs to provide only one, and to omit season for the latest season. It also states 'Series only - movies are rejected with guidance,' which is an exclusion. However, it does not mention when to use this tool instead of the sibling tv_episode or tv_episodes tools, nor any explicit when-not-to-use conditions beyond movies. The guidance is partial but not misleading.

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