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

Annotations already indicate readOnlyHint=false, so the mutating nature is known. The description adds the configuration requirement, which is useful context beyond the annotations, but lacks details about side effects or behavior if the flag is false. With annotations present, a 3 is fair.

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?

Single sentence, front-loaded with the core action, no waste. Perfectly concise.

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 mutative tool with 2 parameters and no output schema, the description covers the action and prerequisite. It could mention return values or error behavior, but the provided context is largely sufficient.

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% with both parameters described (media rating key, playlist rating key). The description does not add further parameter details, so the baseline of 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 'Add a media item to a playlist' uses a specific verb and resource, clearly distinguishing it from siblings like remove_from_playlist and create_playlist. The action is immediately understandable.

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 includes an explicit prerequisite (PLEX_ENABLE_MUTATIVE_OPS=true), which tells the agent when the tool can be used. However, it does not mention alternatives or when not to use it, so a 4 is appropriate.

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 convey readOnlyHint=false and destructiveHint=false, so the mutation is expected; the description usefully adds that the operation is gated behind PLEX_ENABLE_MUTATIVE_OPS=true, which is a beyond-schema operational constraint. It does not disclose what happens when the flag is off, whether the operation is idempotent for items already on the watchlist, or any side effects, so it contains only modest enrichment on top of 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 whole definition is a single sentence that is action-first and does not waste a word: verb + resource + destination + the one enabling requirement in a parenthetical. Every element carries meaning, with no paraphrase of the schema available.

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 one-parameter tool with no output schema, the description covers what the operation does, where it writes, and the necessary environment gate, which is enough to select and invoke it. The remaining gaps — what happens if PLEX_ENABLE_MUTATIVE_OPS is false or if the item is already in the watchlist — are minor for a simple, non-destructive mutation with a fully documented 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%, and the schema already explains ratingKey as a 'local Plex rating key for a matched movie or show' with a clear description. The tool description echo (the 'local' term) matches the schema but doesn't add new meaning, such as how to obtain the ratingKey or what 'matched' means, 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 names a specific verb ('Add'), a specific resource ('a local Plex movie or show'), and a specific target ('the account watchlist'), so an agent knows immediately what the tool does. The 'local' qualifier and the watchlist target distinguish it from siblings such as remove_from_watchlist, get_watchlist, and add_to_playlist without needing to open other 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 states an explicit precondition ('requires PLEX_ENABLE_MUTATIVE_OPS=true'), which is a reasonable gateway for deciding whether invocation is even possible. It does not, however, name the alternatives for the same intent (e.g., get_watchlist to read, remove_from_watchlist to undo, trakt_sync_to_trakt for the Trakt watchlist) or give any 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 declare readOnlyHint=true and destructiveHint=false, so the description adds no new behavioral context. It doesn't mention what happens if a service is unreachable or what the response contains, but the read-only nature is covered by 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 a single sentence that is clear and direct, containing no unnecessary words 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 status-check tool with no parameters and no output schema, the description is adequate. It covers what the tool does, though it could mention return format or typical use cases, but these are 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?

The tool has no parameters, and schema coverage is 100% (empty schema). The description does not need to elaborate on parameters, so a baseline of 4 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 tool checks connection status of Sonarr and Radarr services, using a specific verb (check) and resource (connection status). This distinguishes it from sibling tools that manage library items or trigger searches.

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?

No guidance is provided on when to use this tool versus alternatives, such as verifying connectivity before performing other operations. It only states the action without 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 indicate destructive and non-read-only behavior. The description adds meaningful context: the preview/confirm flow and the environment variable gate that must be enabled for mutations. This goes beyond what annotations and schema provide, helping the agent understand operational requirements and safety.

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 a single, efficient sentence with a parenthetical for the two key execution details. It is front-loaded with the core action and contains no filler. Every part 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 two-parameter destructive tool, the description covers the action, the preview/confirm safety mechanism, and the environment prerequisite. It doesn't describe return values or preview output, but the absence of an output schema and the simplicity of the operation make this acceptable. The destructive nature is well-handled with the gate mention.

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%, with both parameters described. The description reiterates the confirm behavior ('preview unless confirm=true') but adds no new parameter-specific meaning. The playlistId is straightforward as 'rating key' in the schema. Since the schema carries the parameter semantics, 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 uses a specific verb ('Clear') with a clear resource ('all items from a playlist'), which precisely distinguishes it from siblings like remove_from_playlist (removes specific items) and delete_playlist (deletes the whole playlist). The parenthetical adds key execution details (preview/confirm, env var) without muddying the core 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?

The description clearly implies when to use it (to empty a playlist entirely) and provides critical usage context: the preview mode unless confirm=true and the required environment variable PLEX_ENABLE_MUTATIVE_OPS=true. It doesn't explicitly name alternatives, but the sibling names and the phrase 'clear all items' make the distinction obvious.

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 description adds valuable behavioral context beyond the annotations: it discloses the PLEX_ENABLE_MUTATIVE_OPS requirement and notes that Plex does not support creating empty playlists. These are not captured by the readOnlyHint/destructiveHint flags and help the agent understand true preconditions.

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 only two sentences, front-loaded with the primary action, and efficiently packs all critical usage constraints without redundancy. 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 7-parameter schema with full descriptions and non-mutative annotations, the description covers the core usage patterns and prerequisites. It does not mention return values, but since no output schema exists, this is a minor gap for a creation tool where the primary outcome is self-evident.

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 provides 100% description coverage for all 7 parameters, including required conditions and mutual exclusivity. The description restates key patterns (e.g., ratingKeys required for regular, librarySectionId for smart) but does not add new semantic information beyond what the schema offers. 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 'Create a new Plex playlist', using a specific verb and resource. It clearly distinguishes this from sibling tools like get_playlists, add_to_playlist, and delete_playlist by focusing on the creation 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 provides clear context on when to use this tool: it requires PLEX_ENABLE_MUTATIVE_OPS=true, and it explains the two distinct usage paths (regular vs. smart playlists) with their required parameters. It does not explicitly name alternatives, but the context 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds valuable behavioral context by specifying that the underlying media is not deleted and the environment variable requirement, which is beyond what annotations provide. It does not mention reversibility, but the deletion implication is clear.

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 a single sentence that front-loads the main action and includes the critical safety and configuration notes. Every phrase earns its place, with no redundant or filler content. It is concise and well-structured for quick parsing by an agent.

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 mutation tool with no output schema, the description covers the essential context: what it does, that it preserves media, and the required environment variable. It does not mention permanence or potential side effects, but given the simplicity and the destructive annotation, the provided information is largely sufficient. It could be more complete with an explicit 'permanent' note, but it is above the minimum viable level.

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 single parameter playlistId is described as 'Playlist rating key'. The description itself adds no extra meaning for the parameter beyond the schema, which already clearly identifies it. With full schema coverage, a baseline score of 3 is appropriate, and the description does not need to compensate.

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 action: 'Delete a Plex playlist' with a specific resource and verb. It also adds the important distinction that it does not delete underlying media, which differentiates it from related tools like clear_playlist or remove_from_playlist. This is a specific and 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?

The description gives clear context for when to use this tool (deleting a playlist) and includes a critical prerequisite (requires PLEX_ENABLE_MUTATIVE_OPS=true). However, it does not explicitly name alternative tools or state when not to use it, such as when you only want to clear or remove items rather than delete the entire playlist. The exclusion is implied by the safety note but not spelled out.

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 description adds the useful context that output is written to './exports'. Annotations already indicate non-read-only and non-destructive behavior, which is consistent with the description. However, it doesn't mention return values, overwrite behavior, or naming conventions, so transparency is partial.

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 a single sentence that is front-loaded and contains zero filler. It efficiently conveys the core purpose and output location without unnecessary detail.

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 four parameters and no output schema, the description is too terse to be complete. It doesn't clarify the relationship between 'full library' and the 'type' or 'libraryKey' parameters, what the tool returns, or the default filename pattern. This leaves significant gaps for the agent to use 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?

All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description itself adds no extra meaning beyond the schema, leaving parameter semantics entirely to the schema definitions.

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 exports a full library to a JSON file in './exports'. The verb 'export' is specific, and the resource (library) and output format are unambiguous. This distinguishes it from sibling tools that retrieve, search, or manage media.

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 the tool is used when you need to export a library to a JSON file. Although it doesn't explicitly list alternatives or exclusions, the context is clear because no sibling tool offers export functionality. This provides sufficient guidance for when 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds value by disclosing the specific behavioral aspects of the return data: player state, session location, transcode decisions, and media quality. This goes beyond 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?

The description is a single, well-structured sentence. It front-loads the core action and then lists specific included data elements. No filler or redundancy; every word contributes.

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?

This is a simple read-only tool with no parameters and no output schema. The description adequately conveys what the tool does, the scope (currently active), and the kind of information returned. Given the low complexity and rich annotations, the description is 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?

The tool has zero parameters, and the input schema is empty with 100% coverage (vacuously). Per the rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter details because none exist, and none 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 clearly states the tool's purpose with a specific verb ('Get'), resource ('active Plex streams'), and further elaborates with 'who is watching what right now'. It distinguishes itself from sibling tools like get_watch_history or get_libraries by focusing on current real-time streams.

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 the usage context: use this tool when you need to know what is currently playing, as opposed to historical or library-wide tools. However, it does not explicitly name alternatives or provide exclusion criteria, so it falls 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 readOnlyHint=true and destructiveHint=false, and the description simply restates the tool's purpose without adding behavioral context. It does not disclose return format, pagination, permissions, or what 'available tags' means beyond the basic read-only nature.

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 a single, concise sentence with no filler. It front-loads the action ('Get') and the resource ('editable fields and available tags'), making it easy 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 simplicity (one param, no output schema) and presence of annotations, the description is minimally acceptable. However, it leaves ambiguity about what 'editable fields' refers to (field definitions vs. current values) and whether 'available tags' are library-level or item-specific, which could affect correct invocation and output interpretation.

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 ratingKey described as 'The rating key of the media item.' The tool description adds no further parameter details, so it relies fully on 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 the tool gets 'editable fields and available tags' for a media item, which is a specific resource and action. It distinguishes from siblings like get_media_details by specifying 'editable fields' rather than general details, though it does not explicitly name alternative 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?

No guidance is provided on when to use this tool versus related tools like update_metadata or get_media_details. There are no stated exclusions, prerequisites, or typical scenarios, leaving the agent to infer usage.

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, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond the purpose, such as pagination behavior, return format, or the meaning of the 'all' word given the default 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?

The description is a single concise sentence, front-loaded with the action and object, with 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?

Given the simple read-only nature, full schema documentation, and annotations, the description is adequate. It misses a note about the default limit potentially truncating 'all', which would be useful, but the schema covers it, so it's not a major gap.

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 clear descriptions for limit, mediaType, and libraryKey. The description slightly correlates with mediaType and libraryKey but adds no new meaning beyond what the schema already provides, so 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 uses the specific verb 'Get' with the resource 'fully watched movies and shows' and scopes it to 'a library'. This clearly distinguishes it from sibling tools like get_recently_added, get_on_deck, and get_watch_history, which address different filters.

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?

Usage is implied by the description: use when you need fully watched items. However, it does not explicitly state when to prefer this over alternatives like get_watch_history or get_library_items, nor mention exclusions or prerequisites.

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, covering the safety profile. The description adds no additional behavioral details beyond the core operation, such as the return format or any external access implications. This is adequate but not 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?

The description is a single, direct sentence with no filler. Every word serves to communicate the tool's 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?

For a no-parameter, read-only list operation, the description is minimally sufficient. However, it does not specify what the return payload contains (e.g., library names, IDs, metadata) or provide any guidance relative to sibling tools, so it is not fully complete for an agent unfamiliar with Plex's structure.

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 the baseline is 4 per the rubric. The empty schema fully covers the input surface, and the description does not need to explain any 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 'get' and clearly identifies the resource as 'all Plex libraries', which distinguishes it from sibling tools like get_library_items or get_recently_added. It unambiguously states the tool's scope.

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 no usage context, exclusions, or references to alternative tools. It does not say when to use get_libraries versus get_library_items or export_library, leaving the agent to infer from the name alone.

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 the pagination behavior ('with pagination') and its relevance to large libraries, but no other behavioral details like rate limits or response format. With annotations present, this is adequate but not 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?

The description is a single sentence that is front-loaded with the action ('List items in a library') and efficiently conveys the key behavioral aspect (pagination) and a practical use case (large libraries). No waste 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 list tool with 5 parameters and no output schema, the description is mostly complete. It states the primary action and the pagination feature. However, it does not explicitly describe the return format or list any alternatives, leaving a small gap for a brand-new agent.

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 all 5 parameters with descriptions (100% coverage). The description only reinforces the concept of pagination, which the schema already details via limit/offset. No additional semantics are provided, so the 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 verb 'List' and the resource 'items in a library', with pagination as a distinguishing behavior. While it does not explicitly differentiate from siblings like get_playlist_items, the resource is specific enough. Lacks explicit sibling contrast, hence not 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 phrase 'useful for large libraries' provides a clear context for when to use this tool, implying it handles large result sets efficiently. However, it does not mention when not to use it or name any alternative tools, so it stops short of full 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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only a scope qualifier ('library-specific') but no additional behavioral context such as return format, aggregations, or behavior when libraryKey is omitted. This falls short of enriching the agent's understanding 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?

The description is a single, tightly worded phrase with no filler or redundancy. It is appropriately concise for a simple tool, though it sacrifices detail for brevity.

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 and a terse description, the tool's return value is not explained. The agent is left guessing what statistics are provided, how they are structured, and how the optional libraryKey affects results. For a tool with only one parameter and no explicit output format, the description should provide more 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?

Schema coverage is 100% with libraryKey described as 'Library section key (optional)', so the schema fully documents the parameter. The description offers no additional semantic value beyond what the schema already provides, earning the baseline score 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?

The description clearly states a specific verb ('Get') and resource ('library-specific statistics'), which distinguishes it from sibling tools like get_libraries (which lists libraries) and get_library_items (which lists items). However, it lacks detail on what 'statistics' encompasses, making it clear but not fully specific.

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 no guidance on when to use this tool versus alternatives such as get_watch_stats or get_user_stats. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer appropriate usage from the name alone.

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 destructiveHint=false, and the description does not contradict this. It adds only the word 'detailed' without explaining what that includes (e.g., metadata fields, streaming URLs). Since annotations cover safety, the bar is lower, but the description still provides no extra behavioral context.

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?

A single, clear sentence with no unnecessary words or repetition. It is appropriately concise and front-loaded with the main 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?

The tool is simple with one well-documented parameter and safety annotations, so the description is largely sufficient. However, the phrase 'detailed information' is vague and no output schema exists, leaving some uncertainty about the exact return payload. Given the low complexity, this is a minor gap.

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% with the ratingKey parameter described as 'The rating key of the media item.' The description does not add additional meaning beyond 'specific media item,' so it meets 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 clearly states the verb 'get' and the resource 'detailed information about a specific media item,' which distinguishes it from sibling list/search tools like get_library_items and search_media by focusing on a single item identified by a rating key.

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?

Usage is implied: use this when you have a ratingKey and need detailed information. However, the description does not explicitly state when to use this tool vs alternatives or provide exclusions, leaving the agent to infer from the tool name and parameter.

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 provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the clarification that 'on deck' means 'continue watching,' which is useful, but it does not disclose ordering, pagination, or scope limitations (e.g., whether fully watched items are excluded).

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 nearly as short as possible while still being informative: 'Get on deck (continue watching) items.' The parenthetical adds value without unnecessary words, and the key verb 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 zero-parameter tool with no output schema, the description provides the basic purpose but is not fully complete. It does not explain exactly what qualifies as 'on deck' (e.g., progress percentage, whether started items are included) or how it differs from similar sibling tools. The lack of linkage to alternatives reduces completeness.

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 on the description. Baseline of 4 is appropriate because the description does not need to explain what each parameter means.

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 action ('Get') and the resource ('on deck items'), with the parenthetical '(continue watching)' disambiguating the meaning of 'on deck.' This directly distinguishes it from sibling tools like get_recently_watched or get_watch_history.

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?

No guidance is provided on when to use this tool versus alternatives. For example, it does not say 'use this for in-progress items, while get_recently_watched is for anything recently viewed.' This leaves the agent without context for selecting among many similar retrieval tools.

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. However, the description adds no extra behavioral context—no mention of return format, pagination, error handling, or whether the playlist must exist. The description merely restates the obvious action.

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 a single, front-loaded sentence with no wasted words. It clearly conveys the action and the target resource.

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 should explain what the returned 'items' look like (e.g., media IDs, metadata, or just counts). The vague phrase 'items in a Plex playlist' leaves the response format ambiguous, which is a significant gap for a simple 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 description coverage is 100%—playlistId is documented as 'Playlist rating key'. The tool description adds no additional parameter meaning, so the baseline score of 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 uses the specific verb 'Get' with the resource 'items in a Plex playlist', clearly stating the tool's function. It distinguishes from sibling tools like get_playlists (which lists playlists) and add_to_playlist (which modifies).

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?

No guidance is provided on when to use this tool versus alternatives. The description only states what it does without mentioning use cases, exclusions, or relationships to sibling tools such as get_playlists or search_media.

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 description adds no behavioral details beyond the annotations. Annotations already indicate a safe read operation (readOnlyHint=true, destructiveHint=false), but the description does not disclose return format, whether it includes playlist contents, or any additional context such as authentication requirements. It essentially restates the tool's name.

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 a single concise sentence that directly communicates the tool's function. It contains no filler and is front-loaded with the action ('Get') and target ('all Plex playlists').

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 tool with no parameters and no output schema, the description is sufficiently complete. It tells the agent exactly what the tool returns (all playlists), and annotations cover the safety aspects. The lack of details about return structure is acceptable given the tool's 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?

The input schema has zero parameters, and schema description coverage is vacuously 100%. With no parameters to explain, the baseline of 4 is appropriate; the description does not need to elaborate on parameter behavior.

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 'Get all Plex playlists' uses a specific verb ('Get'), identifies the resource ('Plex playlists'), and specifies the scope ('all'). This clearly distinguishes it from sibling tools like get_playlist_items, which focuses on items within a playlist, and create_playlist, which is for creation.

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 the use case—anytime you need a complete list of Plex playlists—but it does not explicitly state when to use this tool over alternatives. No exclusions or alternative references are provided, so guidance is implied rather than stated.

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. However, the description adds no behavioral context beyond what annotations and schema already provide—'by plays or duration' simply restates the metric parameter. No additional traits like pagination, defaults interpretation, or return format are disclosed.

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 a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's primary purpose, making it appropriately concise.

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 tool has a rich schema and annotations, and the description gives the essential idea. However, it lacks guidance on when to use this tool versus related ones, and with no output schema, it could benefit from hinting at the return format. It is minimally viable but not fully contextual.

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 mentions 'plays or duration' which maps to the metric parameter, but it adds no new meaning beyond the schema's own descriptions.

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 verb 'Get' and the resource 'content', and indicates the sorting options 'by plays or duration'. It does not explicitly differentiate from sibling tools like get_recommendations or get_recently_added, but the core purpose is 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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context where another tool would be preferred, leaving the agent without usage direction.

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 description merely restates the tool name, adding no behavioral detail beyond what the annotations (readOnlyHint=true, destructiveHint=false) already convey. It does not explain the meaning of 'recently added' (e.g., time frame, media type) or what the response contains.

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 extremely brief, consisting of only three words, but it is redundant with the tool name. It does not earn its place by providing any new information or context.

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 tool is simple, but the description leaves ambiguity about what 'recently added' refers to and lacks any explanation of the return value, which is especially problematic given there is no output schema. Sibling tools with similar purposes make the lack of context more significant.

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 fully documents the single 'limit' parameter with type and default. The description adds no additional meaning or usage hints beyond the schema, so it meets the baseline for this dimension.

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 ('Get') and resource ('recently added media'), making the primary function clear. However, it does not distinguish this from sibling tools like get_recently_watched or get_on_deck, which could also return recently added items in different contexts.

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?

No information is provided about when to use this tool versus alternatives such as get_library_items or get_recently_watched. The description lacks any contextual or exclusionary 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, openWorldHint, and destructiveHint, so the safety profile is known. The description adds no additional behavioral context such as ordering, pagination, or list return behavior, which would be useful beyond what annotations 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?

The description is a single, concise sentence that front-loads the action and resource. Every word earns its place, with 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?

The tool is simple with two well-documented parameters, but no output schema exists and the description does not mention return format or that mediaType supports 'all' and 'episode.' Given the number of sibling tools, more context would help differentiate this from get_watch_history.

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% for both parameters, with defaults and enums clearly documented. The description adds no parameter information beyond the schema, matching the baseline expectation when the schema is comprehensive.

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 retrieves recently watched movies and shows, using a specific verb and resource. However, it does not explicitly distinguish it from sibling tools like get_watch_history, and it omits that episodes are also supported via the mediaType parameter.

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?

No guidance is provided on when to use this tool versus alternatives such as get_watch_history or get_recently_added. The usage context is only implied by the name 'recently watched,' but there are no explicit exclusions or references to sibling tools.

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 behavioral context about the scoring algorithm (analyzes genres, directors, actors) and conditional Trakt rating profile usage, which goes beyond what annotations 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?

The description is composed of four short sentences, each adding substantive detail about the tool's purpose, algorithm, per-user capability, and Trakt integration. It is front-loaded with the core purpose and contains no filler, though it is slightly more verbose than the minimal two-sentence ideal.

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 recommendation tool, the description covers what it does, how it works, and when user-specific behavior applies. It omits explicit return format details, but that is not critical given the simple list output implied by 'recommendations' and the absence of an output 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 coverage is 100% with each parameter individually described, so the description adds minimal parameter-specific meaning. The 'per-user' mention aligns with the userId parameter but doesn't offer new syntax or formatting details 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 tool's function: retrieving personalized movie recommendations from the user's Plex library. It distinguishes itself from siblings like search_media or get_recently_watched by specifying the recommendation logic (watch history, genres, directors, actors) and per-user support.

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 usage for personalized recommendation requests, referencing watch history and optional Trakt integration for rating refinement. It does not explicitly name alternatives or exclusion criteria, but the context is unambiguous and no conflicting use cases are suggested.

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 readOnly and non-destructive behavior. The description adds no additional behavioral context such as what statistics are included, whether external authentication is needed, or any limitations. With annotations present, the description provides minimal value beyond 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?

The description is a single concise sentence with no fluff or redundancy. It is appropriately brief for a simple getter tool, though it sacrifices informational richness.

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 should convey what statistics are returned, but it only says 'watch statistics' without specifics. The tool's context among many similar sibling tools is not addressed, and no usage context is provided.

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 provides full coverage for the only parameter (timeRange) with a description. The tool description adds no additional parameter semantics beyond the schema, 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 states the tool retrieves user-specific watch statistics with a specific verb and resource. However, it does not explicitly distinguish it from sibling tools like get_watch_stats or trakt_get_user_stats, which could have overlapping scope.

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?

No guidance is provided on when to use this tool versus alternatives. The description only states the function without context, prerequisites, or 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 this as a safe, read-only operation, and the description adds 'session information' as a behavioral detail about the response content. It does not mention pagination, limits, or ordering, but with annotations covering safety, the added context is sufficient for a 3.

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 a single, front-loaded sentence with no wasted words. It efficiently communicates the core function, though 'detailed' is slightly vague.

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 three optional parameters and good annotations, the description is minimally adequate, but it lacks details on output shape or how it differs from related tools like get_recently_watched. The absence of an output schema and sibling differentiation makes the description less complete for an agent making tool-selection decisions.

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 provides descriptions for all three parameters (limit, userId, mediaType), so schema coverage is 100%. The description does not add any parameter semantics beyond what the schema already states, placing it at 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?

The description clearly states the tool retrieves watch history and includes session information, using a specific verb and resource. However, it does not differentiate from sibling tools like get_recently_watched or get_fully_watched, so it earns a 4 rather than 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?

No guidance is provided about when to use this tool versus alternative watch-history tools such as get_recently_watched or get_watch_stats. The description only states what the tool does, leaving the agent to infer its scope. This is a significant gap given the number of similar sibling tools.

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 readOnlyHint and destructiveHint annotations already disclose the safety profile, and the description is consistent (non-destructive read). It adds minimal extra context by specifying 'user's' (implying the authenticated user), but does not disclose return format, ordering, or pagination 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 a single, focused sentence with no redundant words. It immediately communicates the tool's purpose without 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 zero-parameter, read-only tool, the description is sufficiently complete. It does not explain the return structure, but given the simplicity and the absence of an output schema, the description covers the essential context. Slightly more detail about what is returned could push it to 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?

The tool has zero parameters, so the schema coverage is trivially 100%. With no parameters to describe, the baseline of 4 applies, and the description adds no parametric ambiguity.

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 ('Get') and a specific resource ('the user's Plex watchlist'), making the tool's function unambiguous and distinct from sibling tools like get_watch_history or get_playlists.

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?

No explicit guidance is provided on when to use this tool versus alternatives like get_watch_history or get_recently_watched. The description simply states what the tool does without contextualizing its use case.

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, and destructiveHint=false, so the safety profile is clear. The description adds only 'comprehensive' and 'Tautulli-style', which give a hint of output style but no substantive behavioral detail 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?

The description is a single, front-loaded sentence that conveys the core purpose without wasted words. Every word 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?

The description, combined with schema and annotations, gives a moderate picture. However, without an output schema, 'comprehensive watch statistics' is vague, and the absence of detail on what analytics are returned leaves the agent guessing about the output 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%, with both parameters described. The description adds no additional parameter semantics, so the baseline of 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 states the verb 'Get' and resource 'watch statistics', making the tool's basic purpose clear. However, it does not differentiate from sibling tools like 'get_user_stats' or 'get_library_stats', so it lacks sibling discrimination.

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?

No guidance is provided on when to use this tool versus alternatives. The description mentions 'Tautulli-style analytics' but does not explain what scenarios it suits or when to choose other stats tools.

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 readOnlyHint=false and destructiveHint=false, the description discloses an operational gate with the environment variable requirement, which is important behavioral context because the tool likely fails without it. It does not detail side effects or return behavior, but the mutability and prerequisite are clear.

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 one sentence, action-first, and includes the key prerequisite in a parenthetical with zero wasted words. It avoids restating the title or repeating information already present in annotations.

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 single-parameter mutation with no nested objects and no output schema, this description covers the action, the required parameter, and the key prerequisite. The only minor gap is not describing the expected successful response or failure behavior, which is not critical for deciding how to 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?

The schema already documents the only parameter, ratingKey, with a meaningful description and 100% coverage. The tool description adds no extra parameter-level detail beyond reinforcing that the item is a Plex media item, so no compensation is 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 clearly names a specific action ('Mark'), a specific resource ('a Plex media item'), and the resulting state ('unwatched'). It is also semantically distinguishable from the sibling tool mark_watched without needing to open 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 intention is self-evident and the required environment gate is stated, so an agent can infer when to use it. However, it does not explicitly mention alternatives such as mark_watched or state when the opposite tool should be preferred.

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 establish that this is not a read-only operation. The description adds useful behavioral context by explicitly calling out the PLEX_ENABLE_MUTATIVE_OPS requirement, which is key environmental information beyond the basic mutation flag. It does not contradict any 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 a single efficient sentence that communicates the operation and the crucial prerequisite in very few words. The information is front-loaded and there is no unnecessary 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 simple one-parameter tool with clear annotations and a complete input schema, the description is sufficient to explain the key action and the required environment flag. It could be more complete about expected return behavior or idempotency, but those are less critical given the tool's low 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 only parameter is fully documented in the schema (ratingKey is described as 'The local Plex rating key of the media item'). Since schema description coverage is 100%, the tool description need not repeat or enrich this parameter. The 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 specifies a clear verb 'Mark' with a clear resource 'Plex media item' and the target state 'watched'. Although it does not name alternatives, its wording meaningfully differentiates it from the sibling mark_unwatched and other media operations.

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 includes a configuration prerequisite (PLEX_ENABLE_MUTATIVE_OPS=true) but provides no guidance on when this tool should be preferred over related tools like mark_unwatched, rate_media, or update_metadata. The intended selection criteria are largely left to the agent's 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?

The description is minimal and does not disclose significant behavioral traits. Annotations indicate it is a write operation (readOnlyHint=false) and not destructive, but the description does not mention potential side effects such as automatically searching for the movie (searchForMovie defaults to true) or that it may download metadata. This lack of behavioral context is a notable gap for a mutation 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 a single, clear sentence that is front-loaded and free of any fluff. It efficiently conveys the tool's purpose without unnecessary details.

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 complexity (7 parameters, no output schema) and its side effects, the description is too sparse. It does not explain what happens after adding (e.g., whether the movie is monitored, searched for, or what a successful response contains). This incompleteness leaves the agent without important runtime 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 provides 100% coverage of all 7 parameters with clear descriptions, defaults, and enums. The description adds no extra parameter information beyond what the schema already offers, so it meets 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?

The description clearly states the tool adds a new movie to Radarr using TMDB ID, with a specific verb ('Add'), resource ('movie to Radarr'), and method ('by TMDB ID'). This distinguishes it from sibling tools like radarr_search and radarr_get_movies.

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 its usage (adding movies to Radarr) but provides no explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. The tool name and sibling list offer some implied context, but no direct comparison or when-not-to-use guidance is given.

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 safe-read nature is covered. The description adds no additional behavioral context such as date-range behavior, return format, or any side effects. It simply restates the purpose without enriching the agent's understanding 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?

The description is a single, well-structured sentence that front-loads the main purpose. It is appropriately concise with no filler or redundant wording, making it easy 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?

The tool is a simple read-only calendar listing with good schema coverage and safe annotations. However, with no output schema, the description could clarify what the response contains (e.g., list of movies with dates). It also relies on the schema for date default behavior, leaving some gaps. Overall, it is adequate but not fully 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?

The input schema provides 100% parameter coverage with descriptions for limit, startDate, and endDate, including defaults. The description adds no extra parameter semantics, but since the schema is complete, 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 'Get upcoming movies from the Radarr calendar' clearly states a specific verb (get), resource (Radarr calendar), and scope (upcoming movies). It differentiates from siblings like radarr_get_movies (which likely lists all movies) and sonarr_get_calendar (for TV series), though it doesn't explicitly name alternatives.

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?

No guidance is provided on when to use this tool versus alternatives. There are no explicit contexts, exclusions, or alternative tool mentions. The description is purely declarative and offers no conditional advice.

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 agent knows it is a safe read operation. The description adds minimal extra context about the data being 'missing/wanted' movies but does not elaborate on response format, pagination behavior, or any other runtime nuances. It meets the baseline but provides no additional behavioral disclosure beyond what the annotations and name imply.

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 a single, seven-word sentence that is front-loaded with the action verb and directly states the tool's purpose. There is no redundant information, fluff, or repetition of schema details, making it maximally concise and well-structured.

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 pagination tool with good annotations and self-explanatory parameters, the description is nearly complete. It clearly states the resource type (missing/wanted movies) and source (Radarr). While it lacks an explicit alternative reference or deeper behavior description, the simplicity and existing schema coverage make it sufficient for most use cases.

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 provides complete descriptions for both parameters (page and pageSize) with defaults, achieving 100% schema description coverage. The tool description does not add any additional parameter semantics, so the 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 'Get missing/wanted movies from Radarr' uses a specific verb (Get) and identifies the resource (missing/wanted movies) and source system (Radarr). This clearly distinguishes it from sibling tools like radarr_get_movies (which likely returns all movies) and sonarr_get_missing (which targets TV series), making the purpose unambiguous.

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

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

The description implies that the tool is used to retrieve missing/wanted movies but provides no explicit guidance on when to use it over alternatives such as radarr_get_queue or radarr_search. There is no 'Use this when...' or mention of exclusions, leaving the usage context to be inferred from the name alone.

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 only the scope ('all movies') and optional filter, which adds minimal behavioral context beyond what annotations and schema provide. No return format, pagination behavior, or edge cases are disclosed.

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 a single, front-loaded sentence that conveys the core purpose without extraneous details. Every word 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 two well-documented parameters and strong annotations, the description is adequate. It doesn't explain return values, but no output schema exists, and the tool's purpose is straightforward. A 4 is appropriate given the completeness relative to 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?

Schema coverage is 100% because both 'limit' and 'filter' have descriptions. The description's mention of 'optional title filter' aligns with the 'filter' parameter but does not add additional meaning beyond the schema. Baseline 3 is appropriate when the schema carries the parameter documentation.

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 lists all movies in Radarr with an optional title filter. The verb 'list' and resource 'movies' are specific, and 'all movies' differentiates it from tools like radarr_get_missing or radarr_get_queue.

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 usage for retrieving the full movie library but does not explicitly contrast with siblings like radarr_search (for discovering new movies) or radarr_get_missing. No exclusions or alternate tool mentions are provided, so guidance is implied rather than 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?

The description says 'Get', which is consistent with the readOnlyHint and destructiveHint annotations. However, it adds no additional behavioral context beyond what annotations already provide, such as return format, rate limits, or prerequisites. With annotations covering the safety profile, this is acceptable but not enriched.

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 a single sentence, front-loaded with the main action and resource, and includes a useful parenthetical about usage. Every word earns its place; there is no 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?

Given the tool's simplicity (no parameters, no output schema) and strong annotations, the description fully covers what the tool does and when to use it. It explains the returned items (quality profiles and root folders) and the prerequisite context for adding movies.

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 the baseline is 4. The description doesn't need to explain any parameter details. It correctly focuses on the output and purpose.

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's function with a specific verb and resource: 'Get Radarr quality profiles and root folders'. It distinguishes itself from the sibling tool 'sonarr_get_profiles' by explicitly naming Radarr, and adds context by noting it's needed before adding movies.

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 clear context for when to use the tool: 'needed before adding movies'. This implies the appropriate usage time without explicitly naming alternatives or exclusions. While it doesn't say 'use this instead of X', the context is clear 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 readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal extra context ('current') beyond the annotations, but it does not disclose additional behavioral traits such as permissions or rate limits. It is consistent with the annotations, so 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?

The description is a single, front-loaded sentence: 'Get the current Radarr download queue'. Every word earns its place, with no unnecessary detail or repetition. It is optimally concise and well-structured.

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 (one optional parameter, no output schema, and clear annotations), the description adequately covers the essentials. It does not explain the return format or queue contents, but for a well-known domain like Radarr, this is sufficient. The absence of an output schema is offset by the clarity of the tool's purpose.

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 provides a full description for the only parameter 'limit' (Max results to return, default: 200), giving 100% coverage. The tool description does not add further meaning or context about how the parameter interacts with the queue, but the baseline of 3 applies because the schema already handles the 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 the specific verb 'Get' and identifies an exact resource: 'the current Radarr download queue'. This clearly distinguishes it from sibling tools like sonarr_get_queue (for Sonarr) and radarr_get_movies (for movies), leaving no ambiguity about its function.

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 clear context by specifying 'current', indicating this returns the live download queue rather than historical data. It does not name alternatives, but the target use is self-evident for an agent familiar with Radarr. No explicit exclusions are mentioned, but none are necessary for such a straightforward getter.

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, and the description adds the behavioral nuance that the search targets TMDB (an external source) rather than the local Radarr library. This is useful context not present in annotations, though it is not highly detailed.

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 a single, focused sentence that immediately states the action and purpose. No filler or redundant phrases.

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 search tool with two well-documented parameters and no output schema, the description is sufficient overall. The meaning of 'new movies' could be slightly ambiguous (new releases vs. not-yet-in-library), but this does not prevent correct use.

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' have clear descriptions. The tool description does not add extra parameter meaning beyond what the schema already provides, aligning with the baseline for full 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 clearly states it 'Search TMDB for new movies to add to Radarr', identifying the specific action (search), resource (TMDB), and intent (new movies to add). This distinguishes it from sibling tools like radarr_get_movies (listing existing movies) and radarr_trigger_search (triggering searches).

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 usage as a discovery step before adding movies to Radarr ('to add to Radarr'), providing clear context. However, it does not explicitly name alternatives or define when-not-to-use, so it falls 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 indicate readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond the action itself. It does not mention that triggering a search may initiate asynchronous processing, interact with external indexers, or affect queue state. The description adds minimal value over 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 a single concise sentence that is front-loaded with the core action and resource. Every word adds value, with 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?

Given the simple one-parameter tool and annotations, the description is minimally adequate but lacks guidance on expected outcomes or integration with other Radarr workflows. It does not explain what happens after triggering the search or how to verify results, so it is not fully 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?

The schema already fully documents the single parameter (movieId) with a description that includes the 'omit to search all missing' detail. The tool description adds no additional parameter semantics, so the 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 verb 'Trigger' and the specific resource 'search for missing movies', with optional movie ID. This distinguishes it from sibling tools like radarr_search, which likely searches for movies to add, and sonarr_trigger_search, which is for TV series.

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?

No guidance is provided on when to use this tool versus alternatives such as radarr_search or radarr_get_missing. The description only states what it does, without any context on selection criteria or 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?

The annotations already declare readOnlyHint=false and destructiveHint=false, so the mutating behavior is covered. The description adds the operational requirement PLEX_ENABLE_MUTATIVE_OPS=true, which is beyond the annotations and helpful. However, it does not disclose side effects such as whether the rating overwrites an existing one, and no contradiction with annotations 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?

A single, genuinely informative sentence that includes the core action and the critical prerequisite without filler. Every word earns its place, and the important operational condition is neatly parenthesized.

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 setter with only two fully-described parameters and no output schema, the description and schema together are sufficient. It captures the purpose, the operation type, and the necessary configuration flag. Missing only minor behavioral nuance like return values or confirmation, which is not essential here.

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 both parameters have clear descriptions (rating range 0 to 10, ratingKey as local Plex rating key). The description does not add further parameter meaning beyond the schema, 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: 'Set the user's Plex rating for a media item.' This clearly identifies what the tool does. It also distinguishes itself from sibling tools like update_metadata or mark_watched, as none of those specifically target user ratings.

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 does not state when to use this tool versus alternatives, nor does it mention any exclusions. It only includes a prerequisite environment variable, which is a technical requirement, not usage guidance. There is no comparison to sibling tools or conditions like 'use this when you need to change a rating.'

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 set readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds valuable context by noting the mutative ops flag requirement, which is not present in the annotations. It does not elaborate on side effects or return values, but given the annotation coverage, this is more than 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 a single sentence, front-loaded with the action and requirement. Every word earns its place; there is no fluff 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 2-parameter mutation tool with no output schema, the description covers the critical prerequisite (mutative ops flag) and the core action. It doesn't explain error behavior or return format, but these are not essential given the simplicity and the presence of sibling tools for 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?

Schema description coverage is 100%, with clear descriptions for both playlistId and playlistItemId. The tool description adds no additional parameter semantics beyond schema, so the baseline of 3 applies—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 'Remove' and resource 'item from a playlist', clearly distinguishing from siblings like add_to_playlist, clear_playlist, and delete_playlist. It also includes an essential prerequisite (PLEX_ENABLE_MUTATIVE_OPS=true) that adds operational clarity.

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 requirement for PLEX_ENABLE_MUTATIVE_OPS=true, which is a key condition for using this tool. It implies use when removing a single item from a playlist, but does not explicitly name alternatives like clear_playlist for bulk removal or delete_playlist for whole-playlist deletion, though sibling names signal these distinctions.

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 this is a mutating tool (readOnlyHint=false), so the description does not need to relabel that. It does add a useful operational prerequisite, the PLEX_ENABLE_MUTATIVE_OPS=true requirement, but it does not mention idempotency, failure behavior, or what happens if the item is not on the watchlist.

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 a single front-loaded sentence that states the action, target, and supported keys with no filler. The minimal helpful qualification about PLEX_ENABLE_MUTATIVE_OPS is included without bloat.

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 mutation, the description plus schema is almost sufficient. The one notable omission is what the tool returns or whether removal is idempotent, but the input mechanics and prerequisite are well covered.

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 parameter docs already explain plexGuid and ratingKey. The description reinforces the two-identification-modes idea but does not add significant meaning 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 uses a specific verb ('Remove'), a specific resource ('movie or show'), and a specific target ('account watchlist'), and it names both allowed identifier types. This makes it unambiguous and distinct from siblings like remove_from_playlist.

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 says the tool is for removing watchlist entries and even states the required PLEX_ENABLE_MUTATIVE_OPS=true prerequisite. It does not explicitly contrast with alternatives or state when-not-to-use, but the operation and context are clear.

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 only the 'Plex libraries' scope but does not mention pagination behavior, match semantics, or what happens when no results are found, adding minimal value beyond the annotations.

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

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

The description is only one sentence, which is concise, but it is under-specified rather than efficiently compact. It omits critical usage and behavioral details, making it too minimal to earn a higher score for structure.

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 should clarify return format or result behavior but does neither. It also fails to position the tool relative to its many search-related siblings, leaving an incomplete picture for a tool with five parameters.

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 descriptive text for all five parameters, including defaults and enum values. The description itself adds no parameter-specific information, so the baseline score of 3 is appropriate due to the schema's completeness.

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 action (search) and resource (media in Plex libraries), making the basic purpose understandable. However, it does not differentiate from sibling search tools like radarr_search or sonarr_search, nor does it clarify whether it searches across all libraries or only within a specific library.

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?

No guidance is provided on when to use this tool versus alternatives such as radarr_search, sonarr_search, or get_library_items. There are no explicit context clues or exclusions to help an agent choose correctly among the many sibling tools.

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=false and destructiveHint=false, but the description adds no behavioral context beyond the primary action. It fails to disclose potential side effects such as searchForMissingEpisodes defaulting to true (which may trigger downloads) or that the series must not already exist.

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 a single, clear sentence that immediately conveys the tool's purpose without any wasted words. It is perfectly sized for the information it provides.

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?

This tool has 8 parameters and no output schema, yet the description is extremely brief. It does not explain expected behaviors like auto-detection of rootFolderPath/qualityProfileId, or what the return value indicates on success. Given the complexity and side-effect potential, the description is insufficient.

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 8 parameters with descriptions, and context signals show 100% coverage. The description adds little beyond highlighting TVDB ID as the key identifier, so it does not meaningfully enhance parameter understanding. 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 the action (add), the resource (a new series to Sonarr), and the key identifier (by TVDB ID). It distinguishes this tool from siblings like sonarr_search or sonarr_get_series by focusing on the creation use case.

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 no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It is implied that this is for adding new series, but there's no mention of checking existing series or using related tools like sonarr_get_profiles to obtain required IDs.

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 temporal scoping ('upcoming') but does not disclose pagination, return format, or other behavioral nuances. Matches the baseline for annotation-covered tools.

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?

A single, front-loaded sentence with zero filler. It efficiently states the action and resource without unnecessary words, making it easy 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 simplicity (3 optional parameters, no output schema, safe read annotations), the description sufficiently conveys the basic function. It does not detail return values, but the phrase 'upcoming episodes' implies the output, which is adequate for a low-complexity 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 description coverage is 100%, so all three parameters (limit, startDate, endDate) are already documented in the schema. The description adds no additional parameter semantics beyond implying date-range behavior, so the baseline of 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 uses a specific verb ('Get'), identifies the resource ('upcoming episodes'), and scopes it to 'Sonarr calendar'. This clearly distinguishes it from sibling tools like sonarr_get_series (series list) and sonarr_get_missing (missing 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 phrase 'upcoming episodes' provides clear context for when the tool is appropriate (calendar/schedule queries), but it does not explicitly mention alternatives or exclusion cases. The context is clear enough for a simple read-only 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 mark this as read-only (readOnlyHint=true) and non-destructive (destructiveHint=false). The description adds no extra behavioral context, such as pagination behavior or return format. It is consistent with annotations but does not disclose anything beyond 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?

The description is a single, front-loaded sentence with a clear verb, resource, and system scope. No filler or redundancy. It is concise and well-structured.

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 tool with optional pagination parameters, the description is adequate. The schema covers the parameters, and the purpose is clear. It does not specify the return structure, but this is not required for such a straightforward operation.

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 fully documents both parameters (page and pageSize) with descriptions and defaults. The description does not mention them, but with 100% schema coverage, the schema carries the burden. The description adds no additional parameter meaning beyond what is already provided.

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 action ('Get'), the resource ('missing/wanted episodes'), and the system ('from Sonarr'). It distinguishes itself from sibling tools like sonarr_get_series (series info) and radarr_get_missing (Radarr, not Sonarr).

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 when to use this tool (when you need missing/wanted episodes from Sonarr) but does not explicitly mention alternatives or exclusion conditions. The context is clear but lacks explicit guidance beyond the obvious.

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 useful behavioral context beyond annotations by specifying that the tool returns both quality profiles and root folders, which is relevant for the 'add series' workflow.

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 a single, tightly worded sentence that leads with the action ('Get'), names the resources, and adds a parenthetical usage hint. No wasted words, and every phrase contributes meaning.

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 lookup tool, the description fully captures what the tool does, what it returns, and why it matters in the broader workflow. With no output schema or complex behavior, nothing essential 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?

There are zero parameters, so the schema already fully documents that no inputs are needed. The description does not need to add parameter details; the baseline of 4 applies because there is nothing to compensate for.

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 ('Get') and names the exact resources ('Sonarr quality profiles and root folders'). It also distinguishes itself from sibling tools like sonarr_get_series by explicitly framing itself as a prerequisite for adding series.

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 indicates when to use this tool: 'needed before adding series' (e.g., before sonarr_add_series). It does not explicitly list alternatives or exclusions, but the context is strong enough for an agent to infer the appropriate use case.

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 the operation read-only and non-destructive. The description adds the temporal qualifier 'current' (i.e., live snapshot rather than historical), but otherwise provides no additional behavioral detail such as result ordering or queue item composition. 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?

The entire description is one short, front-loaded sentence. Every word contributes to identifying the tool's purpose; there is no filler or redundant detail.

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 low complexity (one optional parameter, no output schema) and strong annotation coverage, this description is sufficient to understand what the tool returns at a high level. It doesn't explain queue item fields, but that is not required since no output schema exists and the tool is a simple read-only fetch.

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 single parameter 'limit' is fully described in the schema (including default), so description needs little added parameter context. With 100% schema coverage, baseline 3 is appropriate; description adds no extra 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 the specific verb 'Get' and identifies the exact resource ('current Sonarr download queue'), which clearly distinguishes it from sibling tools like radarr_get_queue or sonarr_get_series.

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?

No when-to-use or alternative guidance is provided. It doesn't mention that Radarr has its own queue tool or when a queue view is preferred over search/missing tools. Context must be inferred entirely from the tool name and 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=true and destructiveHint=false, so the safety profile is covered. The description adds that the operation returns 'all series' by default and supports an optional title filter, which is slightly beyond annotations but largely repeats the schema. No mention of pagination or return format, so a mid score is appropriate.

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 a single sentence with no filler or redundant detail. Every word contributes meaning, and it is front-loaded with the primary action ('List all series').

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 tool is simple, with two well-documented parameters and annotations that clarify safety. The description conveys the core operation and filter capability. While it doesn't explicitly state the return shape, the lack of an output schema and the simplicity of the tool make this adequate, though slightly more detail on return fields would push it to 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 coverage is 100% with clear descriptions for both 'limit' and 'filter'. The description only restates the 'filter' parameter as 'optional title filter', adding no new semantic value. Baseline 3 is correct since the schema already carries full parameter documentation.

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 'List all series in Sonarr with optional title filter' uses a specific verb ('List') and identifies the exact resource ('series in Sonarr'), clearly distinguishing it from sibling tools like sonarr_get_missing or sonarr_search. The optional filter is also mentioned, making the purpose fully transparent.

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 implies when to use this tool (when you need a list of all series) and the sibling context makes alternatives obvious. However, there is no explicit when-not-to-use or comparison with alternatives like sonarr_search, so it falls short of the highest bar.

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. The description adds the context that the search targets TheTVDB, but does not disclose any additional behavioral traits such as network dependencies, rate limits, or result filtering. It neither contradicts annotations nor enriches them significantly.

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 a single, concise sentence that front-loads the action and purpose. Every word earns its place, with no fluff 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?

The tool is a simple search with complete annotations and a fully described schema. The description adequately covers the high-level use case, though it does not describe the output format or any preconditions. Given the low complexity, it is nearly 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% (both 'query' and 'limit' have descriptions). The description does not add parameter-level detail, but the schema already handles this, so the baseline of 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 the verb ('Search'), the resource ('TheTVDB'), and the intent ('new series to add to Sonarr'). This distinguishes it from sibling tools like radarr_search (movies) and sonarr_get_series (existing series).

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 usage for discovering new series to add, but it does not explicitly contrast with alternatives like sonarr_get_series or radarr_search. No when-not-to-use guidance is provided, so usage context is only implied.

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 readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but the description adds no behavioral context beyond the core action. It does not disclose that triggering a search may start downloads, that the operation is asynchronous, or what side effects may occur. The description carries some burden because annotations are sparse, yet it fails to elaborate.

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 a single, direct sentence that front-loads the action and includes the key optional parameter. Every word earns its place; no wasted 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?

Given the tool's simplicity (one optional parameter, no output schema), the description is sufficient for an agent to select and invoke it correctly. It covers the action and the optional series scoping. A slight deduction for not mentioning side effects or expected return behavior, but overall it is complete for a trigger-style 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 description coverage is 100%, so the schema already explains seriesId as 'Sonarr series ID (omit to search all missing)'. The description's phrase 'optionally for a specific series' adds minimal semantic value beyond the schema. With full schema coverage, 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 uses a specific verb ('Trigger') and resource ('search for missing episodes') with an optional scope ('optionally for a specific series'). It clearly distinguishes this from sibling tools like sonarr_get_missing (which lists missing) and sonarr_search (which may search broadly), making the purpose 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 implies usage: trigger a search for missing episodes, optionally scoped to one series. However, it does not explicitly mention when to use this versus alternatives like sonarr_get_missing (to just view missing) or sonarr_search (to search based on other criteria). No exclusions or when-not-to-use guidance is provided.

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 it is not read-only and has external effects (openWorldHint=true, readOnlyHint=false). The description adds that it 'starts' the OAuth process, which implies user involvement, but does not explain the flow, whether it returns a URL, or how it connects to complete_auth.

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 a single, focused sentence that states the core purpose without any wasted words. It is front-loaded and easily parseable, embodying concise structure.

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 in a multi-step OAuth flow with no output schema and external effects, the description is too sparse. It lacks critical context such as expected next steps, return value, or any prerequisite conditions, making it incomplete for an agent to use 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 only parameter 'state' has a schema description ('Optional state parameter for OAuth flow'), so schema coverage is 100%. The description does not add additional parameter context, resulting in the baseline score for high 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 clearly states the tool's action ('Start Trakt.tv OAuth authentication process') with a specific verb and resource. It distinguishes from siblings like trakt_complete_auth and trakt_get_auth_status by implying this is the initial step, though it does not explicitly name alternatives.

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?

No guidance is provided on when to use this tool versus alternatives like trakt_complete_auth or trakt_get_auth_status. It does not mention that this should be called first in the OAuth flow or what the next steps are.

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 readOnlyHint=false and destructiveHint=false, and the description adds no further behavioral context. There is no mention of what happens on invalid/expired codes, whether tokens are stored, or if prior steps are required, leaving the agent to guess the side effects 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?

The description is a single, well-structured sentence that front-loads the action ('Complete') and resource ('Trakt.tv authentication') with the required input ('authorization code'). 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 one-parameter tool with no output schema, the description is minimally sufficient. However, it misses the broader OAuth flow context, such as the need to call trakt_authenticate first and what constitutes success or failure, which would help the agent understand the tool's place among siblings.

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 provides 100% coverage for the single 'code' parameter with a clear description ('Authorization code from Trakt OAuth callback'). The tool description merely repeats the phrase 'authorization code' without adding syntax, format, or lifecycle details, so the schema carries the meaning.

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 completes Trakt.tv authentication using an authorization code, which is a specific verb+resource+means construction. It distinguishes from siblings like trakt_authenticate by indicating this is the completion step, though it doesn't explicitly name the counterpart.

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?

Usage is implied—the agent can infer this tool is used when an authorization code is available, likely after an initial authentication request. However, the description does not explicitly mention when to use it versus alternatives like trakt_authenticate or trakt_get_auth_status, nor any prerequisites.

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 description aligns with annotations (readOnlyHint=true, destructiveHint=false) but adds no additional behavioral context such as return format, latency, or caveats. With annotations covering the safety profile, the description provides minimal extra value, but nothing contradicts.

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 a single, front-loaded sentence with no filler or unnecessary words. It efficiently communicates the tool's purpose 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 zero-parameter, read-only status check, the description is adequate. It states the action and resource, and the absence of an output schema is mitigated by the simple nature of the tool. However, it does not describe what the response contains (e.g., boolean vs. object), which could be inferred from the name.

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 the description has no need to explain parameter semantics. Baseline is 4 as per rubric, and the description does not interfere with clear 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?

The description uses the specific verb 'Check' with resource 'Trakt.tv authentication status', clearly identifying what the tool does. It distinguishes itself from sibling tools like trakt_authenticate and trakt_complete_auth, which handle the authentication flow, and trakt_get_sync_status, which concerns sync status.

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 usage by stating its function, but it does not explicitly state when to use this tool versus alternatives. The sibling tool names provide context (e.g., using this after authentication), but the description itself offers no direct guidance or 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the scope of 'ongoing sync operations' but does not disclose additional behavioral traits such as what the return value looks like, what happens when no syncs are in progress, or whether the operation is blocking. This is similar to the calibration example where annotations carry safety and the description adds a scope constraint.

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 a single, concise sentence with no unnecessary words. It earns its place by stating the core function clearly, and there is no fluff 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?

The tool is simple (no parameters, read-only) and annotations cover safety, so the description is mostly sufficient. However, there is no output schema, and the description does not explain what the 'status' response contains or how to interpret it. For a status-check tool, this omission leaves some ambiguity, making it slightly less than fully 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?

The tool has zero parameters, so the description is not required to explain parameter semantics. The schema coverage is trivially 100% and there is nothing for the description to add. The baseline score of 4 for zero-parameter tools applies 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 clearly states the action ('check') and the resource ('status of ongoing sync operations'), which is a specific verb+resource pair. It differentiates from sibling tools like trakt_get_auth_status by explicitly focusing on sync operations. However, it could be more explicit about what 'sync operations' encompasses, so it does not fully achieve the top score.

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 no guidance on when to use this tool versus alternatives. It does not mention any exclusions or alternatives, such as trakt_sync_to_trakt or trakt_get_auth_status, nor does it explain when a status check would be appropriate. The context is entirely implied by the word 'ongoing'.

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 and non-destructive behavior, so the description adds no extra safety context. It also fails to disclose any behavioral details such as required authentication, output format, or what 'enhanced' entails, offering no value beyond the annotations.

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

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

The description is a single, front-loaded sentence with no fluff. Every word earns its place, making it extremely concise and well-structured, even if minimal.

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 insufficient for an agent to understand what 'enhanced viewing statistics' means or what output to expect, especially since there is no output schema. It also fails to clarify how this tool relates to other Trakt stats tools or when to use it, leaving significant gaps.

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 description coverage is 100%, and the 'userId' parameter already has a meaningful explanation. The tool description adds no parameter-specific meaning, so the 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 uses verb 'Get' with resource 'viewing statistics from Trakt.tv', indicating a retrieval operation. However, 'enhanced' is vague and does not distinguish this tool from sibling get_user_stats or other stat tools, so differentiation is weak.

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 no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or alternative tools, leaving the agent to guess based on the name alone.

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 (readOnlyHint: true, destructiveHint: false) already cover safety, but the description adds no behavioral context beyond the basic search action. It does not mention authentication needs, result format, rate limits, or any side effects. The description is not contradictory, but it provides no extra 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?

The description is a single, concise sentence with zero wasted words. It is front-loaded with the action ('Search') and resource, making it easy 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?

With no output schema, the description should explain what the tool returns or how results are presented, but it does not. It also fails to provide context about when to choose this over sibling search tools. The description is too minimal to be fully complete for a tool with four parameters and no output 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%, with all four parameters (query, type, year, limit) having descriptions. The description itself adds no parameter information, so the baseline of 3 applies given the 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 specific verb ('search') and resource ('movies and shows on Trakt.tv'), clearly identifying the tool's function. It does not explicitly distinguish from sibling search tools like radarr_search or sonarr_search, but the mention of 'Trakt.tv' provides a platform-specific differentiator.

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?

No guidance is provided on when to use this tool versus alternatives. It does not state that this is the preferred tool for searching Trakt content, nor does it mention any exclusions or conditions. The agent is left to infer usage from the name alone.

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 that this is a non-read-only, non-destructive, open-world operation. The description adds the specific behavior of 'real-time scrobbling' but does not disclose details like whether authentication is required, if it creates a session that must be stopped, or how it interacts with the Plex playback element. It adds some context but not rich behavioral detail.

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

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

The description is a single, front-loaded sentence that conveys the core action without any fluff. Every word serves a purpose, making it concise 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?

Despite the annotations and full schema coverage, the description is too minimal for a side-effectful tool. It does not mention authentication prerequisites, return value, or that this is for starting a scrobble session during active playback. With 5 parameters and a family of trakt_* tools, more context is needed 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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description itself adds no parameter-level meaning beyond what the schema provides, so it neither helps nor hurts.

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 ('Enable') and resource ('real-time scrobbling to Trakt.tv'), clearly distinguishing it from sibling tools like trakt_sync_to_trakt or trakt_authenticate. However, it does not explicitly mention that this applies to currently playing media, which would fully clarify the scope.

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 no guidance on when to use this tool vs alternatives, nor does it mention prerequisites such as prior authentication via trakt_authenticate. There is no indication of when not to use it or how it differs from trakt_sync_to_trakt.

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 description says 'Get', implying a read-only operation, but the annotation readOnlyHint=false contradicts this. The tool may have side effects, yet the description provides no warning or explanation, creating an annotation 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?

The description is a single, concise sentence that front-loads the action. Every word is useful, with no 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?

Given the lack of an output schema and the annotation contradiction, the description is incomplete. It doesn't explain return values, side effects, or what 'comparison' entails, making the tool's behavior uncertain.

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 the schema already fully covers parameter semantics. The description adds nothing about parameters, but with no parameters, the baseline is 4.

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 action ('Get watch history') and resource ('Trakt.tv'), with a purpose ('for comparison'). It distinguishes itself from sibling tools like get_watch_history (local history) and trakt_sync_to_trakt (reverse sync).

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?

There is no explicit guidance about when to use this tool versus alternatives. The phrase 'for comparison' hints at its use, but it does not mention alternatives or exclusions, leaving the agent without clear selection criteria.

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 readOnlyHint=false (write operation) and destructiveHint=false. The description adds no additional behavioral context such as authentication requirements, rate limits, side effects, or what happens to existing Trakt data. It merely restates the action without elaborating on consequences or prerequisites.

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 a single, front-loaded sentence that fully conveys the core purpose without any wasted words. It is an example of efficient, minimal writing 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 sync tool with no output schema and annotations that are not rich (only readOnlyHint/destructiveHint/openWorldHint), the description is too sparse. It does not explain the sync process, whether authentication is required, what a 'sync' entails (e.g., one-time vs. continuous, full vs. incremental), or what the expected outcome/return is. This leaves significant gaps for an agent invoking the 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 schema description coverage is 100%, with each parameter (dryRun, batchSize, includeProgress) clearly described. The description does not add any parameter-specific meaning beyond what the schema already provides, so 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 'Sync Plex watch history to Trakt.tv' uses a specific verb ('Sync') and explicitly names the source (Plex) and destination (Trakt.tv), clearly distinguishing it from the sibling tool trakt_sync_from_trakt which syncs in the opposite direction.

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 directional phrasing 'Plex to Trakt.tv' makes the intended use clear and implicitly contrasts with trakt_sync_from_trakt. However, it does not explicitly state when to use this tool over alternatives or mention exclusions, though the sibling context provides sufficient differentiation.

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