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 this is not read-only, is open-world, and is non-destructive. The description adds the useful constraint that output is written within ./exports, but it does not disclose overwrite behavior, file creation side effects, or permission requirements.

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 no wasted words. It communicates the action, resource, and output format immediately.

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

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

The schema fully documents parameters and annotations cover the safety profile, so the description is minimally adequate. However, for a file-writing export tool it omits relevant behavioral details such as overwrite handling and what the tool returns.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description reinforces the output location constraint but adds no syntax or format details beyond what the schema 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?

States a specific verb and resource: export a full library to a JSON file. It clearly distinguishes itself from read-only sibling tools like get_library_items by emphasizing file export, though it does not explicitly name an alternative.

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 get_library_items or search_media. The export intent is implied, but there are no conditions, exclusions, or named alternatives.

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

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

Annotations already 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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds value by enumerating the three things returned (fields, tags, lock state), which matters because there is no output schema, but it says nothing about auth, rate limits, or what 'locked' implies for follow-up edits.

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?

One front-loaded sentence with no filler; the return contents are placed immediately after the verb. It is perhaps slightly over-compressed, but nothing is wasted.

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 read-only tool with no output schema, the description covers the essentials of what comes back. It stops short of explaining the concept of 'locked fields' or the intended workflow (inspect before editing), leaving the agent to infer the tool's role.

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% for the single ratingKey parameter, so the schema carries the meaning. The description adds nothing about the key's format or where to obtain it, which is the correct baseline when the schema already documents it.

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?

Specific verb ('Get') plus a concrete resource and return categories ('editable fields, available tags and locked fields') scoped to a media item. Clear without opening the schema, but it does not distinguish itself from the closest sibling, get_media_details, which plausibly overlaps.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The obvious use case – calling this before an edit/update to learn what can be changed and which fields are locked – is never stated, nor is how it differs from get_media_details.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is clear. The description adds that pagination is supported and useful for large libraries, but it does not describe return shape, ordering behavior, or performance characteristics beyond that. With annotations carrying the main burden, 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 concise sentence with no wasted text. The pagination capability is front-loaded and directly actionable.

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 listing tool with a fully described schema and read-only annotations, the essential invocation details are present. However, with no output schema, the description could say more about what item data is returned or how it relates to search_media and get_recently_added. It is minimally adequate but leaves noticeable 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?

Schema description coverage is 100%, so the input schema already documents all five parameters, including limit, offset, type, sort, and libraryKey. The description only reinforces pagination and does not add syntax or usage meaning beyond the schema. Baseline 3 is appropriate when 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 clearly states the verb and resource: list items in a library. It also mentions pagination, which distinguishes it from some sibling operations, but it does not explicitly differentiate itself from related tools such as search_media or get_recently_added.

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 only usage hint is the parenthetical 'useful for large libraries,' which implies pagination relevance but gives no guidance on when to choose this tool over search_media, get_recently_added, or get_libraries. There are no explicit alternatives 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 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?

Annotations already cover the read-only, non-destructive, open-world profile, so the description's real contribution is the non-obvious disclosure that new episodes of existing seasons are omitted due to season grouping — a surprise an agent would otherwise hit. It doesn't describe return shape or ordering guarantees beyond 'newest first'.

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

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

Two sentences, no filler, and the caveat about season grouping is front-loaded before the parameter workaround. Every clause carries information an agent needs.

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 3-parameter read tool with full schema coverage and annotations, the description covers the main gotcha and the filtering path. With no output schema, it could say more about what an item record contains, which is the remaining 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%, so the baseline is 3, but the description adds meaning beyond the schema: it explains why type is worth passing (to surface episodes that season grouping hides) and restates the type/libraryKey coupling. That is genuine semantic value, not repetition.

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

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

States a specific verb and resource ('Get recently added media') plus scope ('across all libraries'), which separates it from get_library_items and get_recently_watched by implication. It does not name a sibling explicitly, so it stops short of full differentiation.

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

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

Gives clear conditional guidance: default behavior is season-grouped TV, and passing type plus libraryKey switches to a flat per-type listing newest first. It lacks an explicit when-not-to-use or a named alternative for browsing a whole library, which is where get_library_items would apply.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/external-call profile is covered. The description adds nothing beyond that: it doesn't say what happens on a duplicate add, whether the movie is downloaded or merely monitored, or that a search may be triggered by default.

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 and the key identifier named early. It is efficiently written, though the brevity reflects under-specification rather than disciplined economy.

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 9-parameter mutation with no output schema, the description covers only the core action; duplicate handling, failure modes, and what the response contains are left unstated. The rich input schema compensates substantially, so it is adequate but not 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%, so all nine parameters including the two enums and the tags-creation behavior are already documented in structured fields. The description only restates the tmdbId meaning, adding no semantics beyond the schema. 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?

States a specific verb and resource ('Add a new movie to Radarr') plus the identifier used ('by TMDB ID'), so an agent can immediately tell this apart from read-side siblings like radarr_get_movies or radarr_search. It does not explicitly name the sibling it replaces, but the naming convention makes the boundary obvious.

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 guidance on when to use this versus radarr_search or radarr_get_movies, no prerequisites (does the TMDB ID need to be resolved first?), and no exclusions. The only implied routing is the schema note pointing at radarr_get_tags, which lives in the parameter description, not the tool description.

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=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description contributes nothing further: no note on whether the tag persists server-side, what happens on duplicate labels, or error behavior when the Radarr instance is unreachable.

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 short sentence with the verb front-loaded and no filler. Nothing in it is wasted given the tool's simplicity.

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 create tool with annotation coverage and no output schema, this is minimally sufficient. It still leaves open whether duplicates are rejected and what identifier comes back, which an agent calling a create endpoint would benefit from knowing.

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

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

Schema coverage is 100% and the single 'label' parameter is documented as 'Tag label' in the schema, so the baseline of 3 applies. The description adds no meaning beyond that, such as format constraints or whether the label must be unique.

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

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

States a specific verb+resource ('Create a new Radarr tag'), which the agent can distinguish from radarr_get_tags, radarr_update_tag, radarr_delete_tag and from sonarr_create_tag. It stops short of describing what a tag is used for or what creation returns, but the operation itself is 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?

No guidance on when to create a tag versus reusing existing ones via radarr_get_tags, nor any mention of preconditions such as label uniqueness or required indexer connection. The agent is left to infer the workflow entirely.

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 openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond repeating 'Delete' — critically, it does not say whether the tag is stripped from all associated movies, whether it can be recovered, or what a failure looks like. For a destructive mutation, that is a real gap.

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?

One efficient, front-loaded sentence with no waste. It is appropriately sized but borders on under-specification given the operation is destructive.

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?

A destructive, open-world mutation with no output schema and no annotation-independent detail leaves the agent without knowledge of side effects, confirmation requirements, or failure modes. The description is complete only in the narrowest sense of naming the 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?

Schema coverage is 100%, and the schema itself documents 'Tag ID (from radarr_get_tags)', which fully covers the single parameter. The description contributes no additional meaning, 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?

Specific verb and resource ('Delete a Radarr tag by ID') — an agent can immediately distinguish it from radarr_create_tag and radarr_update_tag in the sibling list. The 'by ID' qualifier identifies the keyed operation, though it does not explicitly name the 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 on when to use this versus radarr_update_tag or when deletion is appropriate. There is no mention of prerequisites (fetching the ID via radarr_get_tags is only in the schema) or of any warning about irreversible removal.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description's useful addition is that results include both IDs and labels, which matters because there is no output schema; it does not mention whether the list is paginated or how it behaves when no tags 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?

A single front-loaded sentence that names the resource and the returned fields with no filler. Nothing could be removed without losing information.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description covers what it does and what fields come back. Only minor gaps remain (empty-result behavior, ordering of returned tags).

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 takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 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?

States a specific verb ('List') and resource ('Radarr tags') with the returned fields ('IDs and labels'). It is clearly distinguishable from radarr_create_tag/radarr_update_tag/radarr_delete_tag and sonarr_get_tags by the read-only 'list all' framing, though it never names those siblings explicitly.

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 only implied: an agent can infer this is how you discover tag IDs before passing them to movie-adding or tag-mutation calls. There is no explicit statement of when to use it, when not to, or which tool to use for a single tag lookup.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered externally. The description adds only that this mutates an existing tag rather than creating one; it says nothing about whether movie-to-tag associations survive the rename, what happens if the ID is unknown, or whether the call is idempotent.

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 six-word sentence with the action and target front-loaded and zero filler. Nothing is wasted, though the terseness contributes to the gaps in other dimensions.

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 two fully documented required parameters, no output schema, and annotations covering the safety profile, the description is minimally sufficient for invocation. It falls short of complete because a mutation tool should indicate return behavior or failure conditions for an unknown tag ID.

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

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

Schema description coverage is 100% — the schema already explains that `id` comes from radarr_get_tags and that `label` is the new label. The description adds no format, length, or uniqueness constraints, so it neither compensates nor detracts; 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 a specific verb ("rename") with a scoped resource ("an existing Radarr tag"), which cleanly distinguishes it from radarr_create_tag and radarr_delete_tag. The "Radarr" qualifier also separates it from the sibling sonarr_update_tag, though it never says so explicitly.

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 guidance on when to use this versus radarr_create_tag or radarr_delete_tag, and no stated precondition such as needing a tag that already exists. The word "existing" hints at a prerequisite, but the agent must infer 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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no note on result ordering, default page size behavior, or how limits apply across large libraries.

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 waste. It is efficient, though the brevity edges into under-specification rather than crispness.

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 five fully documented parameters and read-only annotations the essentials are covered, but there is no output schema and the description does not say what a result contains or how results are ordered/paged in practice, leaving an agent to guess at return 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 every parameter (query, type, limit, offset, libraryKey) documented inline including the enum values and defaults. The description contributes no additional semantic detail, 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?

Specific verb ('Search') plus resource ('media') plus the scoping qualifier 'in Plex libraries', which distinguishes it from the many sibling search tools (sonarr_search, radarr_search, trakt_search) that target other services. It is clear, though it says nothing about what the search matches on (title, cast, etc.).

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 on when to choose this over get_library_items, get_media_details, or the Sonarr/Radarr/Trakt search siblings. Usage is only implied by the word 'Search'; no exclusions or conditions are 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=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it doesn't say what happens on a duplicate, that a search may be triggered, that tags may be created implicitly, or that root folder/quality profile are auto-detected — all of which matter for an 11-parameter mutation.

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 nine-word sentence with the key identifier front-loaded and zero filler. It is efficient, though so terse that the brevity is close to under-specification for a tool with 11 parameters.

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

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

With 100% schema coverage and annotations present, the description only needs to add the operational picture, and it largely doesn't: it is silent on duplicate handling, implicit tag creation, and what auto-detection does when rootFolderPath or qualityProfileId are omitted. There is no output schema, so a hint about the returned series record would have helped.

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 every parameter including defaults, enums and auto-detection behavior is already documented in the schema. The description only echoes the tvdbId parameter and omits 'title', which is also required. Baseline 3 applies since the schema does all the work.

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

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

States a specific verb and resource ('Add a new series to Sonarr') plus the key lookup key ('by TVDB ID'), so the agent knows exactly what the call does. The tool name plus the Sonarr/Radarr prefix naturally separates it from sonarr_get_series and radarr_add_movie, but the description itself never names those siblings or the boundary between them.

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 when-to-use or when-not-to-use guidance, no mention of prerequisites (Sonarr configured, a valid TVDB ID obtained, profiles/root folders resolved), and no pointer to alternatives such as sonarr_get_series for checking whether the series already exists. Usage is only inferable from the verb 'Add'.

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=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond 'Create' — it does not mention duplicate-label handling, required permissions, 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?

One short sentence with zero waste, front-loading the exact action and 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?

For a simple one-parameter tool with complete schema coverage and annotations covering the write/safety profile, the description is minimally adequate. It lacks context about duplicate handling and the result of creation, but those gaps are modest given the structured metadata.

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

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

Schema coverage is 100%, so the single required 'label' parameter is fully documented in the schema. The description adds no additional meaning or constraints beyond what the schema already provides, making the baseline 3 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: create a new Sonarr tag. It clearly distinguishes creation from retrieval/update/deletion by verb, but it does not explicitly differentiate itself from sibling radarr_create_tag or mention how it relates to sonarr_get_tags.

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 guidance on when to use this versus sonarr_update_tag or what to do if a tag with the same label already exists. Usage is only implied by the verb 'Create'.

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, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no mention of irreversibility, whether the tag is detached from existing series, or failure behavior for an unknown ID.

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 no filler. Nothing could be removed without losing information.

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

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

For a one-parameter destructive tool whose annotations carry the risk profile and whose schema carries the ID source, this is minimally sufficient. The gap is that a destructive operation ideally states what is lost and whether the removal is recoverable.

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

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

Schema coverage is 100% and the parameter description already names the source of valid IDs ('from sonarr_get_tags'). 'by ID' in the description restates the schema without adding format, validity, or error semantics; the baseline 3 applies.

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

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

Specific verb ('Delete') plus specific resource ('Sonarr tag') scoped by identifier. It implicitly distinguishes itself from radarr_delete_tag via the service name, but the description never acknowledges the near-identical sibling, so an agent must infer the routing rule.

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 on when to delete versus update (sonarr_update_tag) or how to discover IDs beyond the schema hint. There are no exclusions, prerequisites, or conditions 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. 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, destructiveHint=false, and openWorldHint=true, so the safety profile is clear. The description adds useful return-content context ('with their IDs and labels') but does not mention auth requirements, rate limits, or behavior on empty tag lists; with annotations covering safety, 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?

A single, front-loaded sentence with no filler. Every part contributes either the action, the resource, or the return shape.

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 list tool, the description plus annotations cover what an agent needs to call it correctly. The only minor gap is that it does not state the empty-result behavior, but that 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?

The tool takes zero parameters, so there is no parameter semantics to explain. Baseline 4 applies, and the description correctly does not invent parameter details.

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

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

The description states a specific verb and resource ('List all Sonarr tags') plus the returned fields ('IDs and labels'), so an agent knows exactly what it retrieves. The 'sonarr_' prefix distinguishes it from radarr_get_tags and from the create/update/delete tag siblings, though the description itself does not explicitly name those 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?

Usage is implied: call this when you need the available Sonarr tag IDs or labels, likely before assigning tags elsewhere. However, it does not explicitly say when to prefer this over radarr_get_tags or how it relates to sonarr_create_tag/sonarr_update_tag, leaving the agent to infer from the tool name.

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?

The annotations already state readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds that the operation renames an existing tag, confirming it mutates a label, but it does not explain effects such as whether the old label is lost or what permissions are needed.

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?

It is a single, front-loaded sentence with no filler. It is appropriately short for a simple operation, though the extreme brevity leaves little room for useful 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?

For a simple two-parameter mutation with full schema descriptions and annotations covering the safety profile, the description is mostly sufficient. A brief note about the required tag's existence or the effect of the rename would complete it.

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

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

Schema description coverage is 100%, so the schema already documents both required parameters, including that 'id' comes from sonarr_get_tags and 'label' is the new tag label. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description pairs a specific verb ('Rename') with a specific resource ('existing Sonarr tag'), making the operation clear. It implicitly distinguishes this from sonarr_create_tag and sonarr_delete_tag by saying 'existing' and 'rename', though it does not explicitly name those siblings.

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

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

The word 'existing' implies this is only for tags that already exist and should not be used for creation, which gives some usage context. However, it offers no explicit when-to-use guidance, no mention of alternatives like sonarr_create_tag or radarr_update_tag, and no 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 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.