Bazarr MCP server

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds no extra behavioral context beyond the implicit write action; it doesn't explain side effects, reversibility, or the impact of blacklisting (e.g., preventing future subtitle downloads). It fails to disclose any details that would inform an agent how the system changes state.

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

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

The description is concise, includes the endpoint and a parameter list with brief labels, and front-loads the purpose. It has minor grammatical imperfection but no redundancy or clutter, making it efficient to parse.

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

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

Given the tool has 6 required parameters, no enums, and an output schema, the description covers the basics but lacks contextual details. It doesn't explain the business logic of blacklisting, when it's needed, or what the response indicates. The absence of usage guidance and behavioral depth makes it minimally adequate for an agent to call, but not fully self-sufficient.

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

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

The description provides slightly more readable labels than the schema titles (e.g., 'Series ID' vs 'Seriesid', 'Subtitles file path' vs 'Subtitles Path') and lists all parameters. However, it doesn't explain the meaning of each parameter in the context of blacklisting (e.g., what 'provider' refers to, how 'language' is used) or any relationships between them, leaving gaps that the schema also fails to fill (0% 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 action ('Add an episodes subtitles to blacklist') with a clear resource and verb, and the tool name reinforces the blacklist concept. It distinguishes from siblings like delete_episodes_blacklist and create_episodes_subtitles, though the phrasing is slightly awkward ('an episodes subtitles').

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 tool versus alternatives like delete_episodes_blacklist or create_episodes_subtitles. No mention of prerequisites, conditions, or scenarios where blacklisting is appropriate, leaving the agent to infer usage solely from the 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 indicate that this is a write operation (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false). The description adds no further behavioral context: it does not mention side effects (e.g., overwriting existing subtitles), authentication requirements, file constraints, or failure modes. The HTTP method and path are mere restatements of the operation.

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

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

The description is very concise, consisting of a one-sentence action and a linear list of arguments. It is correctly front-loaded with the purpose and efficiently conveys the required parameters without fluff. Structurally, the Args section is readable, though it could benefit from more detailed explanations if space allowed, but nothing is redundant.

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

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

For a tool with six required parameters and an output schema, the description is adequate but incomplete. It covers all parameters minimally but omits important context: the expected file format and size, whether existing subtitles are overwritten, authentication requirements, or any dependencies (e.g., the episode must exist). The output schema likely covers return values, but the description still leaves gaps in operational context.

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

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

The schema has 0% description coverage, so the description is the sole source of parameter meaning. It provides brief labels (e.g., 'Series ID', 'Episode ID') and important clarifications like 'Language code2', 'Forced true/false as string', and 'Subtitles file as file upload object'. However, the descriptions are minimal; they lack details such as language code format (e.g., ISO 639-1), accepted file formats, or constraints on the boolean strings. This is adequate but not 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 states a specific verb ('Upload') and a specific resource ('episode subtitles'), which clearly distinguishes it from siblings like create_movies_subtitles (which handles movies). The HTTP method and path reinforce the action, and the resource is 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?

There is no explicit guidance on when to use this tool versus alternatives (e.g., create_movies_subtitles for movies, or delete_episodes_subtitles for removal). The intended use is only implied by the resource name; no prerequisites, context, or conditions are provided.

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

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

Annotations already cover idempotency (true) and non-destructiveness, while the description adds the HTTP method (POST) and the fact that credentials are used for authentication. It does not explain whether the test is strictly read-only or what side effects, if any, occur on the Jellyfin server, which would be useful given readOnlyHint=false.

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

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

The description is compact: a one-line purpose, the endpoint, and two param explanations. It front-loads the purpose and contains 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?

For a simple two-parameter test connection tool, the description plus existing output schema and annotations cover the essential invocation details. The only notable omissions are explicit sibling routing and behavior-on-failure or side-effect clarification, which are minor 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?

With 0% schema description coverage, the Args section carries the full burden and does so adequately: url is identified as the Jellyfin server URL and apikey as the Jellyfin API key. The meanings are sufficient for two simple string parameters, though no format or examples are 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 opens with a specific verb ('Test') and resource ('connection to a Jellyfin server'), and includes the exact HTTP endpoint. The 'Jellyfin' scope distinguishes it from the sibling create_plex_test_connection, so an agent can tell them apart without opening schemas.

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

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

The context is clear: use this to verify a Jellyfin connection with credentials. However, the description never explicitly states when to prefer this over create_plex_test_connection or other siblings, and it omits any prerequisites or exclusions beyond the parameters.

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 traits beyond what the annotations already provide. Annotations indicate readOnlyHint=false (mutation), idempotentHint=true, and destructiveHint=false, which the description implicitly matches by saying 'Update'. However, it does not disclose any additional side effects, prerequisites, or error behavior. Since annotations cover the basic safety profile, the description adds minimal value here.

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

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

The description is short and well-structured: an action line, the HTTP endpoint, and a two-argument list. It is front-loaded with the purpose and contains no redundant fluff. The inclusion of the endpoint is a minor extra but not detrimental.

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 relatively simple with two optional parameters and an output schema, so the description's coverage is adequate for basic use. However, it omits any usage context, such as when to use this over patch_movies, and does not explain the 'none' option for profileid. The name/action mismatch also adds a small amount of ambiguity. Overall, it is minimally sufficient but not comprehensive.

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

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

With 0% schema description coverage, the description must compensate for the sparse schema. It does provide brief explanations: 'radarrid: Radarr movie(s) ID' and 'profileid: Languages profile(s) ID or "none"'. This adds meaning beyond the schema's bare anyOf array/null types, but it does not clarify whether the values are arrays, the expected format, or how 'none' should be interpreted. The guidance is minimal but not absent.

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 'Update' and the resource 'specific movies languages profile', which distinguishes it from siblings like create_movies_subtitles or create_movies_blacklist. However, the tool name 'create_movies' conflicts with the described 'Update' action, which could confuse agents about whether this is a creation or modification tool.

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

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

The description provides no guidance on when to use this tool versus alternatives. It only gives the HTTP endpoint and argument descriptions, with no mention of when it should be chosen over similar sibling tools (e.g., patch_movies or create_movies_subtitles) or any conditions for use.

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 idempotentHint=true, so the description doesn't need to restate those. The description adds the HTTP endpoint (POST /api/movies/blacklist) and the list of arguments, which gives some behavioral context. However, it does not disclose what happens on success, whether existing blacklist entries are replaced, or any side effects beyond adding an entry. With annotations covering the safety profile, a 3 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 short and front-loaded with the action, but it includes a redundant HTTP endpoint line and an Args block that mostly repeats the schema. The one-line glosses add little value. It is not bloated, but it is not tightly written either; the Args section could be trimmed or enriched.

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 5 required parameters, no enums, and an output schema, but the description does not explain the purpose of blacklisting, the meaning of 'radarrid' (Radarr ID) in context, or what the output schema contains. The description is adequate for a simple create operation but lacks enough context for an agent to know why or when to invoke it, especially with 0% schema coverage and no parameter details.

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 0%, so the description must compensate. It lists all five parameter names with one-word glosses ('Radarr ID', 'Provider name', etc.), which adds minimal meaning beyond the schema's property names. The glosses are nearly tautological (e.g., 'provider: Provider name') and do not explain formats, constraints, or how the parameters relate to the blacklist operation. This is a clear gap given the 0% 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 action ('Add a movies subtitles to blacklist') and identifies the resource (movies blacklist). It is distinguishable from siblings like create_episodes_blacklist and delete_movies_blacklist, though it doesn't explicitly contrast with them. The grammar is slightly awkward ('a movies subtitles') but the intent 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?

No guidance is given on when to use this tool versus alternatives. It does not mention that this is for movies (not episodes), nor does it explain when blacklisting is appropriate. The sibling list includes create_episodes_blacklist and delete_movies_blacklist, but the description does not differentiate or provide 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?

Beyond the annotations, which already say the operation is non-read-only and idempotent, the description only restates the HTTP POST method and parameter list. It does not disclose upload constraints, overwrite/replace behavior, authentication needs, or validation consequences.

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

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

The description is compact and well organized: one sentence, the endpoint, and a labeled Args block. Nothing is extraneous, and the information appears in a scannable order, with only minor grammar awkwardness ('a movie subtitles').

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 five required parameters are all listed with brief explanatory labels, and the presence of an output schema reduces the need to describe return values. However, the description still lacks details about file formats, semantics of forced/hi, the effect of re-uploading, and alternative routing information.

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?

With 0% schema description coverage, the parameter list carries the semantics: radarrid as Movie ID, language as two-letter code, forced and hi as boolean-like strings, and file as an upload object. It clarifies types and presumed formats, though 'hi' is not expanded to hearing-impaired and acceptable file formats are omitted.

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

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

The description opens with the action 'Upload' and the resource 'movie subtitles', and the POST endpoint /api/movies/subtitles reinforces the scope. Because sibling create_episodes_subtitles exists, the movie-resource wording distinguishes this tool from that one.

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 when-to-use guidance and does not mention alternatives such as patch_movies_subtitles or create_episodes_subtitles. An agent must infer from the tool name and the word 'movie' when this is the right choice.

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, idempotentHint=true, and destructiveHint=false, and the description does not contradict these (POST aligns with a write operation). However, the description adds no behavioral context beyond the endpoint verb — it never explains what side effects creating the key has, whether an existing key is overwritten, or what the response represents. With no contradiction, but no added value over annotations, this sits at a 2.

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 text is short, which is good, but it redundantly states the endpoint twice ('POST plex/apikey' and 'POST /api/plex/apikey') in the space where a real purpose statement should go. It earns credit for brevity but not for density of useful 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?

The tool is simple (one param, has an output schema), so the bar is moderate. Yet the core question — what creating a Plex API key entails and how it differs from create_plex_encrypt_apikey — is left entirely unexplained. The output schema covers return values, but the fundamental purpose ambiguity makes the definition incomplete.

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

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

Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It merely repeats 'apikey: API key', which adds nothing beyond the schema's own 'Apikey' title. It does not state the expected format, whether the key is user-provided or generated, or any constraints — a clear failure to compensate for the coverage gap.

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

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

The description is essentially a tautology — it restates the endpoint ('POST plex/apikey') and the parameter name, but never says what 'creating' an API key actually does (generates a new key? stores/provides an existing one?). It also fails to distinguish itself from the closely related sibling create_plex_encrypt_apikey, leaving an agent unable to tell the two apart.

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 tool versus alternatives. Given the sibling create_plex_encrypt_apikey, an agent has no basis for choosing between them. No context about prerequisites, sequencing, or intended workflow is provided.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, but the description adds no behavioral context beyond the endpoint. It does not explain what 'encrypt-apikey' does, whether it creates a new encrypted key, overwrites an existing one, or what side effects occur. With no annotations covering the operation's semantics, the description carries the burden and fails to disclose 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 extremely short, but it is under-specified rather than concise. It repeats the same information twice ('POST plex/encrypt-apikey' and 'POST /api/plex/encrypt-apikey') without adding any explanatory value.

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

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

For a tool with no parameters and an output schema, the description could be minimal, but it still fails to explain what the tool does, what the output represents, or how it relates to other Plex API key tools. An agent cannot determine the purpose or effect of calling this endpoint from the description alone.

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 to document. The description's mention of the endpoint is the only relevant context, and with no parameters, the 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 is essentially a tautology: it repeats the tool name and the HTTP endpoint ('POST plex/encrypt-apikey') without explaining what encrypting an API key means, what it does, or what the result is. It does not distinguish this from sibling tools like create_plex_apikey or create_plex_test_connection.

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 given on when to use this tool versus alternatives. The description only restates the endpoint and provides no context about prerequisites, typical use cases, or when another Plex-related tool would be more appropriate.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false, but the description adds no behavioral context beyond the raw endpoint. It does not mention what the logout invalidates, whether authentication is required, or what side effects occur. It does not contradict the annotations, but it contributes nothing extra.

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 very short and front-loaded, but it contains redundant information: 'POST plex/oauth/logout' and 'POST /api/plex/oauth/logout' say essentially the same thing. It is concise but not efficiently informative.

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 endpoint with an output schema and annotations, the invocation surface is simple and the exact URI is provided. However, the description lacks the intended effect and any relation to the broader OAuth flow, so an agent must infer when and why to call it.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter documentation burden. The description correctly implies no arguments are needed by only specifying the endpoint.

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 provides the exact HTTP method and endpoint, 'POST /api/plex/oauth/logout', which identifies a specific resource and distinguishes it from sibling Plex OAuth tools by path. However, it never states the semantic effect, such as 'invalidates the current Plex OAuth session', and largely echoes the tool name and endpoint without adding meaning.

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 given about when to use this tool versus alternatives like create_plex_oauth_pin or create_plex_select_server. The description only repeats the endpoint and gives no context for when a logout operation is appropriate.

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

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

Annotations already indicate the operation is non-read-only, idempotent, and non-destructive, but the description adds no further behavioral context. It does not mention what side effects occur, what the returned PIN represents, or how this fits into the OAuth flow.

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 text is short but poorly structured: the endpoint is written twice ('POST plex/oauth/pin.' and 'POST /api/plex/oauth/pin'), and the Args block just repeats schema information. Each element adds little value beyond the tool name itself.

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?

Although the tool has only one optional parameter and an output schema, the description is too thin to guide correct invocation. Without any explanation of the Plex OAuth PIN creation flow or its role among the create_plex_* siblings, the definition is only minimally usable.

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 0%, so the description needed to compensate, but it only restates 'client_id: Client ID,' which mirrors the schema title. It does not explain whether the client ID is required, what format it should take, or why it is needed.

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

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

The description names a specific resource and HTTP verb ('POST /api/plex/oauth/pin'), so an agent can infer this creates a Plex OAuth PIN. It does not explicitly explain what the PIN is for or differentiate itself from related siblings like get_plex_oauth_pin_by_pin_id_check, but the endpoint is concrete enough to be 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?

No guidance is given about when to use this tool versus the many related Plex OAuth tools, such as list_plex_oauth_pin, list_plex_oauth_servers, or create_plex_oauth_logout. An agent would have to rely entirely on naming conventions and endpoint paths.

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, idempotentHint=true, and destructiveHint=false, so the description does not need to restate those. However, it adds no behavioral context beyond the endpoint: it does not mention that this selects the server for future operations, whether it replaces the current selection, or any side effects. Given annotations exist, a 2 is appropriate for missing contextual depth.

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

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

The description is extremely short but not concise in a helpful way; it is under-specified. It begins with a redundant repetition of the endpoint, then lists parameters without any framing. There is no useful structure or front-loaded purpose statement, so the brevity reflects a lack of content rather than efficient communication.

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

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

For a tool with 5 parameters (3 required) and an output schema, the description is far from complete. It does not explain the purpose, behavior, or expected response format. The parameter explanations are minimal and the tool's role in the Plex workflow is absent, leaving the agent with insufficient information to call it correctly.

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

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

The schema has no descriptions (coverage 0%), so the description's parameter list is the only explanatory source. Each parameter is given a terse label (e.g., 'Machine identifier') that barely exceeds the schema title, and some are ambiguous (e.g., 'local: Is local connection' does not clarify expected values or format). The description fails to compensate for the schema's lack of detail.

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 only repeats the endpoint 'POST plex/select-server' and does not explain what selecting a server accomplishes. It is a near-tautology of the tool name and provides no functional context, such as 'selects the active Plex server for the application' or 'registers a new Plex server'. It fails to distinguish from sibling tools like create_plex_test_connection or create_plex_webhook_create.

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 given on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or scenarios where another tool should be preferred. The description is entirely silent on usage context, leaving the agent to guess.

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 context beyond the endpoint. Annotations already provide idempotentHint and destructiveHint, but the description does not explain what the test does, what happens on success/failure, or any side effects.

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 very concise, with the endpoint and parameter listed directly. It is not verbose, but the structure is minimal and lacks a clear statement of purpose. Still, it is efficient.

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

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

Even though an output schema exists, the description does not state the tool's purpose or behavior. An agent cannot confidently determine when to use this tool or what it accomplishes beyond the endpoint. This is a significant 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?

The description provides 'uri: Server URI', which clarifies the meaning of the sole parameter. This adds value beyond the schema, which only has type and title. The parameter is adequately explained.

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 HTTP method and endpoint (POST /api/plex/test-connection) but does not explicitly say the tool tests a Plex server connection. It relies on the tool name for purpose, which is somewhat clear but not directly stated.

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 given on when to use this tool versus alternatives like list_plex_test_connection or create_jellyfin_test_connection. The agent must infer usage from the name and endpoint, which is insufficient.

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

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

The description is entirely silent on behavior—no mention of what the operation does, what side effects exist, what is created, or what the response contains. Annotations only indicate idempotentHint=true, but the description adds no context beyond that. The agent has no insight into expected outcomes or potential side effects.

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

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

The description is extremely short but redundant—it repeats the same endpoint in two different formats. This is under-specification, not conciseness. The repetitive lines do not earn their place, and the description would be more concise if it simply stated the purpose in one sentence.

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

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

Even for a simple tool with no parameters and an output schema, the description fails to state what the tool does. An agent cannot infer that this creates a Plex webhook, what the expected outcome is, or how it relates to other webhook operations. The description is fundamentally incomplete.

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

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

With zero parameters in the schema (100% coverage), the description does not need to explain parameter semantics. The baseline for 0 params is 4, and since there are no parameters to clarify, the description adequately (if minimally) meets this requirement by not adding contradictory or misleading information.

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 only repeats the endpoint path ('POST plex/webhook/create' and 'POST /api/plex/webhook/create'), which is essentially a tautology of the tool name. It does not state what the tool actually does (e.g., creating a Plex webhook configuration), nor does it distinguish it from siblings like create_plex_webhook_delete or list_plex_webhook_list.

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

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

No guidance is provided on when to use this tool versus alternatives. There are many related Plex webhook and other create tools among the siblings, but the description gives no context about the purpose, prerequisites, or 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?

The description states the tool 'delete's a webhook URL, which is a destructive operation, but the annotations declare destructiveHint: false. This is a direct contradiction. The description also does not add other behavioral context (e.g., idempotency, side effects) beyond what annotations already provide, but the contradiction is severe.

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

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

The description is compact but redundant: it repeats the endpoint twice ('POST plex/webhook/delete.' and 'POST /api/plex/webhook/delete'). The Args section is concise, but the repetition wastes space. Still, the structure is straightforward and front-loaded with the endpoint.

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 delete tool with one parameter and an output schema, the description provides the basic action. However, it does not resolve the misleading 'create' prefix, lacks usage guidance, and the annotation contradiction creates confusion. An agent would not have enough context to confidently call this tool instead of a sibling.

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 no description for webhook_url (0% coverage). The description compensates minimally by listing 'webhook_url: Webhook URL to delete', which clarifies the parameter's purpose. However, it does not provide format constraints, examples, or any additional semantic detail, so it only barely covers the gap.

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

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

The description states a specific action (delete) and resource (webhook URL) via the endpoint 'POST /api/plex/webhook/delete' and the argument description 'Webhook URL to delete'. It clearly indicates this tool deletes a webhook, though it does not explicitly differentiate from sibling tools like create_plex_webhook_create or list_plex_webhook_list. The 'create' prefix in the name is confusing but the description resolves it.

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 tool versus alternatives. The description simply restates the endpoint and argument, with no mention of prerequisites, use cases, or conditions that would select this tool over related webhook tools such as create_plex_webhook_create or list_plex_webhook_list.

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 idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it resets status but provides no additional behavioral context such as side effects, scope (all providers vs. specific), or state changes. It does not contradict the annotations.

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

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

The description is extremely concise and front-loaded with the core purpose. It includes the endpoint and parameter specification without filler. While minimal, it efficiently conveys the necessary information for a single-parameter tool.

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 (1 parameter, no nested objects) and has an output schema, so return value explanation is unnecessary. The description covers the action and allowed value, but omits context about the scope and effect of resetting provider status, which might be ambiguous for an agent. Given the low complexity, this is acceptable 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?

Schema coverage is 0%, so the description must compensate. It explicitly lists the action parameter and the allowed value 'reset', which the schema does not provide as an enum. This is essential for correct invocation and goes beyond the minimal schema definition.

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

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

The description states a specific action ('Reset providers status') and resource ('providers'), making the tool's purpose clear despite the misleading 'create' prefix. It distinguishes from siblings like create_providers_episodes and create_providers_movies by specifying a reset operation, though it doesn't elaborate on what 'status' entails.

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 tool versus alternatives. There is no mention of conditions, prerequisites, or exclusions. The description is purely declarative and does not help an agent decide between this and other provider-related 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 idempotentHint=true, which align with the description's 'download' action. The description adds the endpoint and parameter details but does not elaborate on side effects, required authentication, or the nature of the download (e.g., immediate vs queued). It adds some value beyond annotations but not rich 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?

The description is concise, with a one-line purpose followed by the endpoint and a structured Args list. It is front-loaded and avoids unnecessary prose, though the Args formatting is a bit informal.

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

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

The description covers the endpoint, all parameters, and the output schema exists to define the return value. It does not mention prerequisites like provider existence or authentication, but these are likely implied by the system context. The coverage is adequate for calling the tool correctly.

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

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

The schema has 0% description coverage, so the description's Args list is essential. It explains all 7 parameters, including allowed values for hi, forced, and original_format, and clarifies that 'subtitle' is an ID from a previous GET. This adds significant meaning beyond the bare schema types.

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 'Manually download an episode subtitles' and provides the POST endpoint, which distinguishes it from list/delete siblings. It is specific about the resource (episode subtitles) but does not explicitly mention the provider context, though the name implies it.

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 like create_episodes_subtitles or create_providers_movies. There are no exclusions or conditions, leaving the agent to infer the appropriate context 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 indicate the operation is not read-only, not destructive, and idempotent. The description adds that this is a manual download and that subtitle IDs come from a GET request, but it does not disclose side effects such as where the subtitle is stored or whether provider configuration is required. No contradiction with annotations.

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

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

The description is compact and well-structured: a one-line purpose, the endpoint, and a bullet-style Args list. Every line contributes useful information with no filler.

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

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

All required parameters are documented and an output schema exists, so the description is largely sufficient for calling the tool. It could be slightly stronger by noting where provider names come from or how to obtain subtitle IDs, but 'as returned by GET' provides a reasonable pointer.

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 0%, but the description explains all six parameters, including allowed values for hi, forced, and original_format, and clarifies that subtitle is an ID returned by GET. This fully compensates for the schema's lack of 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 action ('Manually download') and the resource ('movie subtitles'), with an explicit POST endpoint. It is understandable and distinct from most siblings, though it does not explicitly contrast itself with create_movies_subtitles or list_providers_movies.

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

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

The word 'Manually' hints at when to use it, but the description gives no explicit guidance about when to choose this over create_movies_subtitles or how to prepare provider/subtitle data. No alternatives or exclusions are mentioned.

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

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

Beyond the annotations, the description only says 'Update', which does not disclose side effects, whether the previous profile is replaced, or any authentication prerequisites. It adds no behavioral context to the existing idempotentHint/readOnlyHint 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 short and front-loaded, with a clear one-sentence overview followed by a compact args list. The endpoint line adds minor context but is not waste.

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 an output schema and simple parameters, the core call information is mostly present, and the parameter semantics are documented. However, the missing usage guidance and the create/update ambiguity leave an agent without enough context to confidently select and invoke 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?

Schema coverage is 0%, but the description compensates by explaining that seriesid is the Sonarr series ID and profileid is the language profile ID(s) or the sentinel 'none'. This gives crucial meaning not available in the schema.

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

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

The description states a specific action ('Update specific series languages profile') on a specific resource, so an agent can understand the operation. However, it does not differentiate from siblings such as patch_series or create_series, and the tool name 'create_series' conflicts with the update semantics.

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 given about when to use this tool versus alternatives like patch_series or create_series, or when the 'none' profile value is appropriate. The context is limited to raw parameters, leaving selection to inference.

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

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

The description discloses the concrete operations (shutdown or restart) and the endpoint, which adds useful behavior context. Annotations already indicate idempotent and non-destructive, and the description does not contradict them, though it does not explain side effects beyond the action names.

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

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

The description is short and front-loaded, delivering the core purpose in the first sentence followed by the endpoint and parameter detail. Every sentence contributes meaningfully 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?

For a simple one-parameter tool with an output schema and clear annotations, the description provides enough context to invoke it correctly. It lacks fuller when-to-use or effect detail, but the low complexity and existing annotations cover most needs.

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

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

With 0% schema description coverageched, the description compensates by defining the `action` parameter and enumerating its allowed values: 'shutdown' and 'restart'. This is essential semantic information that the schema alone lacks.

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 explicitly states 'Shutdown or restart Bazarr', giving a specific action and resource. It also lists the two possible action values, making the tool's purpose unambiguous and distinct from siblings like create_system_backups or create_system_account.

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 makes clear that the tool is for shutdown/restart actions, so the primary usage intent is evident. However, it does not explicitly discuss when to prefer this over alternatives or mention any conditions/exclusions, leaving that to the agent's inference.

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

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

Annotations already indicate this is not read-only, not destructive, and idempotent. The description adds useful context by naming the HTTP endpoint, the form-login mechanism, and the username/password auth inputs. However, it does not explain session side effects, which credentials are required for which action, or behavior when credentials are missing.

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

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

The description is short, front-loaded with the main purpose, and uses a compact Args block. Every sentence adds useful information: the operation, the endpoint, and parameter semantics. 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 description covers the parameters well, but it does not clarify conditional requirements: login likely needs username and password, while logout may not. This is a meaningful gap because the schema marks only action as required and makes username/password nullable. The presence of an output schema reduces the need to describe return values, but the action-specific parameter dependencies remain undocumented.

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 0%, so the description carries the full burden of parameter meaning. It explicitly lists all three parameters, gives action its allowed values 'login' and 'logout', and explains username and password as Bazarr credentials. This fully compensates for the schema's lack of detail.

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 operation: 'Login or logout from Bazarr UI when using form login.' This is a specific verb plus resource and is distinct from sibling system tools like create_system_settings or create_plex_oauth_logout. It also clarifies that despite the 'create_account' name, the tool does not create accounts.

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 'when using form login' provides clear context for when this tool applies. It does not explicitly name alternatives or exclusions, but the form-login condition is a meaningful usage signal and the action enum is described.

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 supply readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add marginal behavioral context. It states the state-changing action and the endpoint, but does not disclose persistence, response details, or prerequisites; this is acceptable given the annotations 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 very concise, front-loaded with the actionable purpose, followed by the endpoint and the single parameter explanation. Every sentence earns its place with no filler or repetition.

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

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

The tool is low complexity: one required parameter, output schema present, and annotations covering safety and idempotency. The description covers what, where, and the parameter. It could optionally mention list_system_announcements as the source for hashes, but that is not strictly required for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It explains hash as 'hash of the announcement to dismiss', giving functional context beyond the schema's bare 'Hash' title. This fully documents the only parameter.

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

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

The description clearly states a specific action and resource: 'Mark announcement as dismissed' and gives the POST endpoint. It is distinct from list_system_announcements, though the tool name beginning with 'create' is not reconciled with the dismiss action, making sibling differentiation only implicit.

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 intended use is implied by the action statement, but there is no explicit when-to-use guidance, no exclusions, and no pointer to list_system_announcements for discovering announcement hashes. This is adequate but leaves the agent to infer the workflow.

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, idempotentHint=true, and destructiveHint=false, but the description adds no behavioral context beyond the POST endpoint. It does not explain whether retries are safe, whether the backup operation is asynchronous, what is captured, or if any cleanup is needed. For a mutating operation that creates data, this is a noticeable 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?

The description is extremely concise: 'Create a new backup' followed by the endpoint. It is front-loaded, contains no filler, and every part is relevant. The endpoint line is arguably redundant but still adds a concrete API reference.

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 zero parameters and an output schema present, the basic call is well covered. However, the description lacks guidance on when to create a backup, what the idempotency hint means in practice, or any behavioral caveats like duration or storage. It is minimally sufficient but not fully complete for an agent making nuanced 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 tool has zero parameters and 100% schema description coverage, so the schema already covers everything. The baseline for zero-parameter tools is 4, and there is no missing parameter information for the description 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 clearly states the verb ('Create') and the resource ('backup'), and this makes it distinguishable from sibling tools like delete_system_backups and list_system_backups. It does not provide any additional scope or detail, but the core purpose is unambiguous. The HTTP endpoint reinforces the operation but adds little descriptive clarity.

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

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

The description gives no explicit guidance about when to choose this tool over alternatives such as list_system_backups or patch_system_backups. It does not state prerequisites, side effects to consider, or any contrasting condition. The usage is only implied by the action name and the one-line 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 mark the operation as idempotent, non-destructive, and non-read-only. The description adds the specific queue-manipulation semantics and the POST endpoint, which helps clarify what the tool does. It does not contradict the annotations and adds modest behavioral context 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 compact and front-loaded with the core operation, followed by the endpoint and argument list. There is no filler or redundant restating of the schema. The phrasing 'Job ID act onto' is slightly awkward but not harmful.

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 two-parameter tool with an output schema, the description covers the essential invocation details: the endpoint, the target job ID, and the permitted actions. It does not explain whether move_top also force-starts the job or clarify prerequisites, but the core calling context is complete enough for an agent to use it correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does identify 'id' as the job ID to act on and 'action' as one of three specific values, which is minimally sufficient. It does not elaborate on side effects or distinguish consequences of each action, leaving some semantic burden unmet.

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 operations: force start, move to top, or move to bottom of the queue for a specific job. It clarifies the otherwise misleading 'create' name by indicating these are actions on existing jobs rather than creation. It does not explicitly contrast with sibling tools like patch_system_jobs, but its own purpose 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?

The action list implies the intended use: queue control operations on existing jobs. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as patch_system_jobs for modifying job settings or list_system_jobs for viewing jobs.

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 detail beyond the HTTP verb. Annotations already indicate this is a write operation (readOnlyHint=false), idempotent, and non-destructive, so the description itself contributes nothing beyond what structured metadata already provides.

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 contains redundant duplication: 'POST system/settings' is immediately repeated as 'POST /api/system/settings'. This is waste rather than useful conciseness, though it is short and 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?

Given the tool has no parameters and an output schema exists, the minimal endpoint information is partially sufficient. However, it never explains what creating system settings actually does, what settings are affected, or what side effects an agent should expect beyond the annotations.

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

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

The tool has zero parameters and the schema is empty, so the description does not need to explain parameter semantics. The baseline for no parameters is 4, and there is no missing parameter information.

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

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

The description clearly identifies the operation as POST to system/settings, pairing a specific verb with a specific resource. It does not, however, explain what 'system settings' means or how this differs from sibling endpoints like create_system_account or create_system_jobs, so it lacks sibling 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?

There is no guidance on when to use this tool versus any alternative. It only states the endpoint, leaving the agent to infer the appropriate context from the tool name and the path.

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 idempotentHint=true and destructiveHint=false, so the description doesn't need to repeat those. However, it adds no behavioral context beyond the bare fact of running a task—no mention of side effects, background processing, latency, or what the response represents. With annotations present, the description fails to add meaningful 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 brief and not verbose, but it is under-specified rather than concisely informative. It front-loads 'Run task,' which essentially restates the tool name, and follows with the endpoint and an Args list. The structure is plain and lacks formatting like headings, but it does not waste words. The brevity comes at the cost of essential 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 tool is simple (one parameter, output schema exists), the description is still inadequate. It doesn't explain what a system task is, when to run one, what the output indicates, or how this tool fits into the broader system. An agent would lack enough context to decide when to invoke this tool or interpret the result.

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 description includes an Args section that explains taskid as 'Task id of the task to run,' which adds meaning beyond the bare schema. Since schema description coverage is 0%, the description is the only source of parameter semantics. However, it doesn't specify the format of the id, where to obtain it, or any constraints, making it minimal but not fully helpful.

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 says 'Run task.' which is a verb and a resource but extremely vague. It does not specify what a system task is, what 'running' entails, or how it differs from sibling tools like create_system_jobs. The endpoint POST /api/system/tasks is mentioned but doesn't clarify the tool's purpose. The description doesn't distinguish this tool from other create_* tools.

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

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

No guidance is provided on when to use this tool versus alternatives. It simply states 'Run task' with no context about prerequisites, scenarios where it is appropriate, or when to prefer another tool. The description is entirely silent on usage context.

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

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

Annotations already establish idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds that this tests an external connection via POST, but it does not disclose whether a sample event is sent, what side effects occur, or whether external connectivity is required. No contradiction with annotations.

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

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

The description is two short lines: a clear purpose sentence followed by the exact HTTP endpoint. There is no filler, and the most useful information is front-loaded.

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

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

For a zero-parameter test action with an output schema and meaningful annotations, the purpose and endpoint are largely sufficient for invocation. The main gap is usage guidance relative to sibling tools, which is more relevant to the usage-guidelines dimension.

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 the empty input schema is complete and the description has no parameter details to add. Baseline 4 applies for a no-parameter tool.

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

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

The description names a specific action ('Test') and object ('external webhook connection'), and the included endpoint /api/system/webhooks/test clarifies the resource. It is distinct enough from sibling test tools like create_plex_test_connection and create_jellyfin_test_connection, though it does not explicitly say 'system' in prose.

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 tool vs alternatives such as create_plex_test_connection or create_jellyfin_test_connection. It also omits prerequisites like whether a webhook must already be configured before testing.

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 idempotency, non-read-only, and non-destructive behavior. The description adds the event trigger and HTTP method, but does not disclose side effects, authentication needs, or expected caller. This is adequate but not rich, given the annotations already carry part of the burden.

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

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

The description is compact and front-loaded: the purpose is in the first sentence, followed by the endpoint and argument summary. There is no filler or redundant prose.

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

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

Even though there is an output schema and useful annotations, the description omits critical context: who sends this webhook, what a valid payload looks like, and how this relates to Plex webhook setup tools. An agent cannot confidently construct the exact 'payload' string needed to trigger the intended search.

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 0%, so the description must compensate. It only says 'payload: Webhook payload', which barely restates the schema's 'Payload' title. No format, JSON structure, or example of the expected Plex payload is provided, leaving the single required parameter underspecified.

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

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

The description states a specific action ('Trigger subtitles search') and the triggering condition ('play media event in Plex'), plus the endpoint. This clearly distinguishes it from sibling tools like create_plex_webhook_create or create_webhooks_radarr, which manage different webhook behaviors.

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 invoke this tool versus alternatives such as create_plex_webhook_create. It is only implied that it responds to a Plex play media event, but there is no explicit statement about prerequisites, callers, or how it differs from sibling webhook 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 signal a non-read-only, idempotent, non-destructive operation. The description adds that the effect is searching for missing subtitles based on Radarr webhooks, but it does not clarify whether this creates a persistent webhook subscription or simply processes an incoming webhook event—an important distinction given the tool 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 minimal and front-loaded: one behavioral sentence followed by the endpoint. It wastes no words, though a clarifying phrase about the create/process webhook relationship would make it easier to parse.

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

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

For a parameterless tool with an output schema, the description is mostly sufficient. The main gap is the unresolved relationship between the tool name ('create_webhooks') and the described behavior ('Search for missing subtitles'), plus no mention of prerequisites or side effects beyond the search.

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 schema coverage is complete, so the description does not need to document arguments. The 'Radarr webhooks' phrasing reinforces context but is not necessary for parameter understanding.

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

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

The description states a concrete outcome—searching for missing subtitles—and scopes it to Radarr webhooks, which distinguishes it from the Sonarr and Plex webhook siblings. It is not fully explicit about whether this creates/registers a webhook, so the exact nature of the operation is slightly inferred, but the intended behavior is clear enough.

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 mention of 'Radarr webhooks' provides clear context for when this tool is relevant, but there is no explicit guidance about when to prefer it over create_webhooks_sonarr or create_webhooks_plex. Usage is implied rather than stated with conditions 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 the tool is non-destructive and idempotent. The description adds useful behavioral context by specifying the HTTP method and path (POST /api/webhooks/sonarr) and the effect of the webhook (triggering a subtitle search). 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 extremely concise: a one-sentence purpose followed by the endpoint. Every word earns its place, and the key action is front-loaded. No unnecessary filler or repetition.

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

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

Given there are no parameters and annotations cover safety, the description is mostly adequate. However, it does not explain what the webhook payload should contain or what the output represents, even though an output schema exists. It also leaves the create-vs-receive ambiguity unresolved, which could confuse an agent about how to invoke 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 input schema has zero parameters, so the description correctly has nothing to add. Baseline is 4 for tools with no parameters, and no additional explanation is needed.

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

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

The description states a specific action: searching for missing subtitles, triggered by Sonarr webhooks, and provides the HTTP endpoint. It distinguishes from siblings like create_webhooks_plex and create_webhooks_radarr by explicitly naming Sonarr. However, it is slightly ambiguous whether the tool creates a webhook registration or handles an incoming webhook, which is a minor clarity gap.

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 use this tool versus alternatives like create_webhooks_plex or create_webhooks_radarr. The differentiation is implied only by the name and the 'Sonarr' reference, but the description does not state conditions like 'use this for Sonarr webhook integration' or mention any 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 destructiveHint=true and idempotentHint=true, so the description's 'Delete' is consistent. The description adds the behavior of the 'all' parameter ('Empty episodes subtitles blacklist'), which is not in annotations, but it does not explain the effect of combining parameters or any side effects beyond deletion. No contradiction with annotations.

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

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

The description is short, includes the endpoint, and front-loads the action. The args list is compact but not well structured; however, it is not verbose. It earns a 4 for efficiency, though the terse phrasing could be improved.

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 destructive, idempotent tool with three optional parameters and no schema descriptions, the description is insufficient. It does not clarify the exact semantics of 'all' versus specific provider/subs_id combinations, nor does it mention what response to expect. Although an output schema exists, the behavior is still ambiguous. 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?

With 0% schema coverage, the description must fully explain the parameters. It gives terse hints: 'all: Empty episodes subtitles blacklist', 'provider: Provider name', 'subs_id: Subtitles ID'. This is ambiguous: 'Empty' likely means 'clear all', but it doesn't clarify whether 'all' is a boolean or string, or how it interacts with provider/subs_id. The description adds minimal meaning beyond the schema, leaving the agent uncertain about required combinations.

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

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

The description states a clear verb and resource: 'Delete an episodes subtitles from blacklist.' This distinguishes it from sibling tools like delete_movies_blacklist and delete_episodes_subtitles by resource and action. The inclusion of the endpoint adds specificity, 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 given on when to use this tool versus siblings. There is no mention of scenarios where this is preferred over delete_episodes_subtitles or create_episodes_blacklist. The description only states what it does, not when to use it.

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

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

Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=true, and the description merely restates the delete behavior without adding consequences, permissions, or side effects. It also fails to explain what happens to the file or system state when subtitles are deleted.

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 tight and well-structured: a clear one-line purpose, the HTTP endpoint, and a compact argument list. No filler is present, though the endpoint line is arguably redundant with the tool name.

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

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

The description covers all required parameters and the destructive nature of the operation, and an output schema exists for return values. However, it lacks usage guidance, clarification of forced/HI semantics, and any behavioral caveats, making it adequate but not fully complete for a six-parameter delete 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 description coverage is 0%, so the Args section must carry the documentation burden. It does provide meaningful hints for all six parameters, such as 'Language code2', 'Forced true/false as string', 'HI true/false as string', and 'Path of the subtitles file', though some entries like 'Series ID' add limited detail.

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

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

The description opens with a specific verb and resource: 'Delete an episode subtitles,' and reinforces it with the DELETE endpoint. This clearly separates it from sibling tools like create_episodes_subtitles, patch_episodes_subtitles, and delete_movies_subtitles.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that creation, patching, or movie-subtitle deletion belong to other tools, leaving the agent to infer usage solely from the verb 'delete'.

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 destructiveHint=true and idempotentHint=true, so the description does not need to restate deletion. It adds some useful behavioral context by noting that 'all' empties the movies subtitles blacklist, but it does not disclose side effects or whether a specific deletion requires both provider and subs_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?

The description is short and front-loads the action and endpoint, followed by a compact argument list. The grammar is slightly awkward ('a movies subtitles'), but there is no redundant filler and every line serves a purpose.

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

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

Given the output schema exists and annotations cover safety and idempotency, the description only needs to explain the operation and parameters. It covers both, but it leaves the key decision implicit: whether to use 'all' to clear everything or provider+subs_id to delete one entry, and which combinations are valid.

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 0%, so the description must compensate for the bare schema. It gives a one-line meaning for each argument, which adds value beyond the schema, but the semantics of 'all' is terse and the relationship between all, provider, and subs_id is left implicit.

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

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

The description states a clear action ('Delete'), a resource ('movies subtitles'), and the target context ('blacklist'), and the endpoint line reinforces it. It is distinct enough from sibling tools like delete_movies_subtitles and delete_episodes_blacklist, though it does not explicitly call out the distinction.

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 sibling alternatives such as delete_movies_subtitles or delete_episodes_blacklist. The purpose is implied but there are no conditions, exclusions, or preference signals to help an agent choose correctly.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description merely repeats the delete semantics without adding context about irreversibility, what is removed on disk versus database, or failure behavior. It does not contradict the annotations, but adds no behavioral 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 compact and scannable, with the action front-loaded and an organized Args block. The endpoint line is somewhat redundant with the tool name, but overall there is no filler or wasted prose.

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 destructive operation with five required parameters, the description leaves important gaps: accepted value formats for forced/hi, what exactly gets deleted, and when to prefer create/patch variants. The output schema exists, so return values need not be described, but behavioral and parameter context is still thin.

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?

With 0% schema description coverage, the Args list is essential and does add some meaning: radarrid=Movie ID, language=Language code2, path=Path of the subtitles file. However, forced and hi only restate that they are true/false strings without explaining accepted values or their meaning, and 'Language code2' is ambiguous about exact format.

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

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

The opening sentence 'Delete a movie subtitles' states a specific verb and resource, and the DELETE endpoint reinforces the action. It is distinct from siblings like create_movies_subtitles or delete_episodes_subtitles, though it never explicitly calls out those differences.

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 routing is provided. The description only states the delete action and parameters, leaving the agent to infer when to choose this over patch_movies_subtitles or delete_episodes_subtitles from the tool 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 provide destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the bar is lower. The description adds that the deleted item is a backup file and exposes the DELETE endpoint, but it does not add deeper behavioral context such as irreversibility, required permissions, or side effects. It does not contradict the annotations.

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

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

The description is short and front-loaded: the core action appears in the first sentence, followed by the endpoint and the required argument. There is no filler, though the phrasing 'Backups to delete filename' is slightly clunky and could be clearer.

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

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

For a single-parameter destructive operation with annotations and an output schema, the description provides enough information: the action, the resource, the endpoint, and the required filename. It omits expected-error behavior or result details, but those are not critical given the output schema and simple tool contract.

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 only provides the parameter name 'filename' and type 'string' with 0% description coverage. The description's Args block, though awkwardly phrased, does communicate that filename is the backup file to delete. This adds minimal but useful meaning beyond the bare schema.

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

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

The description opens with 'Delete a backup file,' a specific verb plus resource, and reinforces it with the DELETE /api/system/backups endpoint. This clearly distinguishes the operation from sibling tools like list_system_backups, create_system_backups, and patch_system_backups by action and target resource.

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 about when to use this tool versus alternatives such as list_system_backups or patch_system_backups. The description also provides no exclusions, prerequisites, or caution about destructive consequences, leaving usage decisions entirely to inference.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, so the destructive nature is clearly known. The description adds the 'queue' context and endpoint, but does not discuss side effects such as whether a running job is cancelled, whether deletion is immediate, or if any confirmation is required. With annotations covering the core safety profile, 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 concise and front-loaded with the main purpose. Including the endpoint and param listing is useful, and there is no superfluous text. It could be slightly more fluid by integrating the endpoint into the first sentence, but overall it is well-structured and efficient.

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

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

For a single-parameter destructive operation, the description is reasonably complete. It names the resource, the action, and the only argument. Output schema exists, and annotations cover safety properties. The main missing piece is guidance on when deletion is appropriate, but that is a usage-guidelines aspect rather than a completeness gap for 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?

Schema description coverage is 0%, so the description must compensate. It does so by explaining 'id' as a 'Job ID to delete from queue', adding domain meaning beyond the bare integer type in the schema. This makes the parameter's role clear, though it could have been slightly more detailed about constraints or 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 opens with a direct, specific verb and resource: 'Delete a job from the queue.' It clearly identifies the operation and target, and the HTTP verb DELETE reinforces the action. The tool name and sibling list further confirm this is a dedicated system-job deletion operation, distinct from other delete_* tools on different resources.

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 like patch_system_jobs or other delete tools. It only states what the tool does, without any context about when deletion is appropriate, whether there are prerequisites (e.g., job must be idle), or which alternatives exist for non-destructive updates.

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 destructive and non-read-only; the description adds that the tool forces rotation and creates a new log file. It does not disclose what happens to the existing log data beyond 'rotation' or mention any side effects or permissions, but it does not contradict the annotations.

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

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

Two short sentences; the first is action-focused and front-loaded, and the second gives the endpoint. Every word earns its place with no filler.

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

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

For a parameterless tool with annotations and an output schema, the description is sufficient to understand the core operation. It could be more explicit about the disposition of the old log file, but the action is simple and the destructive annotation fills part of that 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?

The input schema has zero parameters and no required arguments, so there is nothing for the description to add. A baseline of 4 is appropriate for a parameterless tool.

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 operation ('force log rotation' and 'create a new log file') on the system logs resource, so an agent can tell it apart from list_system_logs and other delete_* siblings. It is not a tautology, though it does not explicitly mention the 'delete' aspect suggested by the name and HTTP method.

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 action is described precisely enough that an agent can infer when to use it (when system logs should be rotated), but the description gives no explicit when-to-use/when-not-to-use guidance or alternatives. There are no caveats or exclusions, making the usage guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond that—it does not say what 'check' returns, whether the PIN is consumed, or how it relates to the OAuth lifecycle. The description contributes essentially nothing 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 short but redundant: the same route appears twice in slightly different formats ('<string:pin_id>' and '{pin_id}'). The only non-redundant line is the trivial Args note. This is under-specification, not efficient conciseness—every sentence does not earn its place.

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

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

With an output schema present, return values are covered, but the tool's purpose, OAuth flow position, and relationship to sibling tools are unaddressed. Plex OAuth PIN checking is a stateful flow, and a one-line route plus path parameter label leaves the agent without enough context to call it appropriately.

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 0%, so the description must compensate. Its only contribution is 'pin_id: Path parameter', which tells the agent the parameter belongs in the path—but the schema already names it and the route template shows {pin_id}. No format, constraints, or meaning of pin_id beyond its name is given.

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 only restates the HTTP route ('GET plex/oauth/pin/<string:pin_id>/check.') and repeats it in full path form. It never states what the tool actually does, such as checking a Plex OAuth PIN's status or validity. This is essentially a mirror of the tool name, which already contains 'check', so it crosses into tautology.

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

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

There is no guidance on when to use this tool versus the many OAuth siblings like list_plex_oauth_pin, list_plex_oauth_validate, or create_plex_oauth_pin. The description does not explain the OAuth flow context, polling expectations, or any 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, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds that the tool returns a count (badges count), which is behavioral context beyond the annotations. However, it does not describe the response format, potential errors, or whether the count is global or user-specific. With annotations covering safety, a 3 is appropriate – the description adds minimal but useful 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 exceptionally concise: two short sentences with no filler. The purpose is front-loaded ('Get badges count'), and the endpoint is included as a useful technical detail. Every word earns its place – there is no redundancy or vague language.

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

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

For a tool with no parameters, a simple output (badges count), and annotations covering safety, the description is complete. The output schema exists (indicated by 'has output schema: true'), so the description need not explain the return structure. The only minor gap is the lack of clarification about what 'badges' refers to, but this is a domain-specific detail that likely falls outside the tool's responsibility.

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 fully covers parameters (100% coverage). With no parameters to document, the baseline is 4. The description does not need to add parameter information, and it correctly includes the HTTP endpoint (GET /api/badges) which is not part of the schema but adds clarity about the operation.

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

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

The description states a clear verb and resource: 'Get badges count' – it identifies exactly what the tool does. However, it doesn't clarify what 'badges' represent (e.g., notification badges, achievement badges), which is a minor ambiguity. It distinguishes from sibling tools by resource (badges vs. movies, episodes, etc.), so it is not confused with other list_* tools.

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

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

The phrase 'to update the UI' provides a clear context for when to use this tool – when the UI needs to display a badge count. It does not explicitly mention alternatives or exclusions, but given there are no similar badge tools among the siblings, the usage context is sufficient. The guidance is clear and directly 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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the GET endpoint and the fact that it returns metadata, but does not describe response structure or any rate limits. Given the annotations, the description provides minimal additional behavioral context, which is acceptable 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 concise, includes the HTTP method and path, and lists parameters in a clear block. It is front-loaded with the main action. However, it could be more structured by explaining parameter interactions, but as a short definition it is efficient.

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 existence of many sibling list_episodes_* tools, this description is incomplete. It does not clarify whether the tool returns all episodes when no parameters are provided, or whether at least one parameter is needed. It also does not specify what 'metadata' includes beyond the schema's output. For a tool with two optional parameters and an output schema, more guidance is needed to avoid ambiguity.

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 0%, so the description must compensate. It provides brief explanations: 'Series IDs to list episodes for' and 'Episodes ID to list'. This adds meaning, but lacks detail on whether both can be used together, if at least one is required, or the format of the IDs. For a tool with zero schema coverage, the parameter documentation is insufficient.

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 episode metadata and can filter by series or episode IDs. It uses a specific verb ('List') and resource ('episodes metadata'). However, it does not differentiate from sibling tools like list_episodes_history or list_episodes_wanted, which might also return episode-related data.

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 implies you provide seriesid or episodeid but does not explain when you would choose this over other list_episodes_* tools. No explicit when-to-use or when-not-to-use instructions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the GET endpoint and paging args, which is useful context, but it does not disclose any behavioral traits beyond what the annotations and schema already convey.

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

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

The description is compact and front-loaded, with a clear one-line purpose, the HTTP endpoint, and a minimal argument list. There is no filler or redundant prose.

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 low complexity, rich annotations, and existing output schema, the description covers the essential invocation details: endpoint and paging parameters. It falls slightly short by not explaining what 'blacklisted' means in this context or how this tool relates to nearby list_episodes endpoints.

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 0%, so the description must compensate. It does clarify that 'start' is a paging start and 'length' is a paging length, adding meaning beyond the bare schema titles. However, it does not explain default behavior, offset semantics, or how optional values are handled.

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 ('List') and a specific resource ('blacklisted episodes subtitles'), making the tool's scope clear. The 'blacklist' qualifier distinguishes it from related siblings like list_episodes and list_movies_blacklist.

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 given about when to use this tool versus alternatives such as list_episodes or list_episodes_wanted. The description simply restates the tool's purpose and provides no exclusions, prerequisites, or 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds a GET endpoint and paging parameters without contradicting those annotations, but it does not explain pagination behavior, filtering semantics, or event coverage.

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 definition is compact and front-loads the core action and endpoint, followed by a brief argument list. It contains no filler, though the Args block is minimal and could be integrated more elegantly.

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

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

For a simple read-only list endpoint with an output schema, this is mostly adequate. However, it lacks explanation of what an episode history event is, how paging bounds work, and how it differs from related list tools, leaving the agent to infer behavior from the name and endpoint.

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

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

Schema description coverage is 0%, so the description must provide meaning. It partially does by labeling start and length as paging values and episodeid as an Episode ID, but it does not clarify defaults, bounds, or whether episodeid filters the history.

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 episodes history events', and the GET endpoint reinforces the action. It is distinguishable from sibling tools like list_episodes, though 'history events' could be more explicit about what is returned.

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 given about when to use this tool versus alternatives such as list_episodes or list_history_stats. The endpoint and name imply a read-only history listing, but there are no stated prerequisites, use cases, 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 description discloses the GET endpoint, which aligns with and mildly extends the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false). With the annotations already covering the safety profile, the added value is limited to confirming the HTTP verb and endpoint; nothing is said about result-set semantics, paging behavior, or filtering effects, but there is 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 compact and front-loaded: a one-line purpose, the endpoint, and three terse argument lines. No filler. The Args block partially duplicates what the schema already conveys (names and types), but since it carries the only parameter semantics, it 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 a full output schema and strong annotations, the definition is mostly adequate. The main gaps are that 'wanted' is never explained, and the semantics of episodeid as a filter (single ID vs. array, union vs. intersection with paging) are left to inference.

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 0%, so the description must compensate. It does add minimal meaning beyond the schema: start and length are labeled 'paging' integers and episodeid is labeled 'Episodes ID to list'. This is genuine but thin guidance — it does not clarify defaults, zero-based paging, or how episodeid interacts with paging.

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 episodes wanted subtitles') and includes the exact HTTP endpoint (GET /api/episodes/wanted), which disambiguates it from siblings like list_episodes, list_episodes_blacklist, and list_episodes_history. The phrasing is grammatically awkward ('episodes wanted subtitles' vs. 'wanted episodes'), and the 'wanted' concept is not defined, but the intent is discernible.

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 given on when to select this tool over alternatives such as list_episodes, list_episodes_history, or list_movies_wanted. There is no context, no exclusions, and no mention of what makes an episode 'wanted', so the agent must infer the use case entirely from the 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the endpoint and the path parameter but does not disclose behavior like whether the path is required, what happens with a null path, or whether the listing is recursive. No contradiction with annotations.

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

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

The description is short and front-loaded with the main purpose. The Args section is minimal but not bloated. It earns its place, though it could be slightly more informative without becoming verbose.

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 one optional parameter and an output schema, the description is mostly adequate. However, the lack of differentiation from list_files_radarr/list_files_sonarr and lack of path semantics leave some gaps for an agent deciding how to invoke it.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'path: Path to browse', which adds minimal meaning beyond the schema's 'Path' title. It does not explain path format, allowed values, or the consequence of omitting 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?

The description states a specific verb ('List') and resource ('Bazarr file system content'), and includes the HTTP endpoint. It is clear what the tool does, though it doesn't explicitly distinguish it from the sibling tools list_files_radarr and list_files_sonarr, which are likely more specific variants.

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 given on when to use this tool versus list_files_radarr or list_files_sonarr. The description only says 'List Bazarr file system content' with a path argument, leaving the agent to infer which file-listing tool is appropriate for a given context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds only the 'Path to browse' context and the API route, but does not describe behavior like default path handling, error cases, or return format (output schema covers return). No contradictions.

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

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

The description is compact with a title line, endpoint, and args section. It is front-loaded and easy to scan. The endpoint line is slightly redundant with the title but not harmful.

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 operation with an output schema and safety annotations, the description covers the core purpose and parameter. However, it lacks any cross-tool context or usage guidance, which could leave an agent uncertain about when to prefer this over sibling list tools.

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 no description for 'path' (0% coverage). The description adds 'Path to browse', which gives basic meaning but does not specify path format, required vs optional behavior, or how null is handled.

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 ('List') and resource ('Radarr file system content'), and names the endpoint. It distinguishes from sibling 'list_files_sonarr' by naming Radarr, but does not clarify scope (files vs directories) or contrast with the generic 'list_files' tool.

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

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

No guidance on when to use this tool versus 'list_files' or 'list_files_sonarr'. The phrase 'Path to browse' implies a browsing use case, but there are no explicit conditions, exclusions, or alternative 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 disclose that this tool is read-only, idempotent, and non-destructive, so the safety profile is well covered. The description adds the GET endpoint and the concept of path-based browsing, but it does not provide additional behavioral detail such as null-path handling or traversal limits.

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

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

The description is extremely concise and front-loaded: purpose, endpoint, and parameter are each stated in one short line. There is no filler or redundant elaboration.

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

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

For a simple, single-optional-parameter read-only tool with an output schema and strong annotations, this is nearly complete. The only meaningful gap is the absence of a statement about default path behavior, which would make it fully self-contained.

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 0%, so the description must compensate, but 'path: Path to browse' adds little beyond the parameter name. It does not clarify important semantics like what happens when path is null, what path formats are accepted, or whether omitting path lists a root directory.

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 'List Sonarr file system content', which identifies a specific action and resource. The explicit 'Sonarr' qualifier distinguishes this tool from sibling tools like list_files_radarr and list_files.

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 Sonarr-specific wording implies the intended usage context, but there is no explicit guidance about when to choose this tool versus list_files or list_files_radarr. The decision relies on the tool name and sibling grouping rather than description-provided 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the time_frame allowed values and filter parameters, which is useful, but it does not describe the response format, aggregation behavior, or any side effects. Since it is a read-only stats call, the annotations cover the main behavioral traits, and the description adds modest 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?

The description is concise and well-structured: a one-line summary, the endpoint, and a bullet-style parameter list with brief explanations. No unnecessary words or fluff. It is front-loaded with the core purpose and then details parameters, making it easy to scan.

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

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

The description covers the endpoint and all parameters adequately, and the output schema presumably documents the return structure. However, it does not clarify the scope of 'history' (all history vs. per type), which could matter given the many sibling history tools. It also does not mention any limits or notes on filtering behavior. For a simple stats endpoint with optional filters, this is mostly sufficient but leaves some ambiguity.

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 parameter descriptions (0% coverage), so the description is the sole source of parameter meaning. It provides a concise description for each parameter and explicitly lists the valid values for time_frame, which is not present as an enum in the schema. This fully compensates for the schema's lack of 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 states a clear action ('Get history statistics') and a specific resource (history stats endpoint). It is not a tautology and is distinct from the generic 'history' concept, but it does not differentiate from siblings like list_episodes_history or list_movies_history, which might also involve history data. The endpoint path adds specificity, but the scope (all history vs. per-type) is ambiguous.

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 only lists parameters and their meanings, with no mention of conditions, prerequisites, or exclusions. An agent would not know whether to pick this over list_episodes_history or list_movies_history based on the description 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 idempotentHint=true, and the GET endpoint is consistent with those hints. The description adds no detail about auth failures, availability semantics, or response behavior, but for a simple read-only list the annotation coverage is sufficient.

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

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

Three compact lines: a purpose sentence, the endpoint, and one-line argument definitions. It is front-loaded and every element earns its place with no waste.

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, has annotations, and an output schema exists, so the description need not explain return values. It provides the endpoint and parameter meanings, which is sufficient; a brief note about when to use it relative to Jellyfin siblings would make it fully complete, but nothing critical is missing.

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

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

The schema has 0% description coverage, so the description must compensate. It does so by defining url as 'Jellyfin server URL' and apikey as 'Jellyfin API key', giving agents the minimal meaning needed to fill both parameters.

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

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

States 'List available movie and series libraries from the Jellyfin server' – a specific verb, resource, and server. The explicit GET endpoint further clarifies the operation. This distinguishes it from the many create_/list_ siblings targeting other systems.

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 when-to-use guidance or alternatives are mentioned. However, the name and endpoint make the core use case self-evident, so usage is implied rather than entirely absent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the HTTP GET method and paging parameters, which are consistent with a read operation. However, it does not disclose potential defaults for start/length or any filtering behavior beyond radarrid.

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 brief and front-loaded with the main purpose. The endpoint and parameter list follow logically. No filler exists, though the format is fragmented. It earns its keep without being verbose.

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 output schema covers return values and annotations cover safety, the main gaps are usage differentiation and nuanced parameter semantics. For a simple list endpoint, this is adequate but not complete: an agent might not know the default paging values or whether radarrid is required. The presence of many sibling list tools makes the lack of usage guidance more consequential.

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 0%, so the description must compensate. It provides minimal one-line explanations for start, length, and radarrid. This is helpful but thin: start/length are explained as paging integers, and radarrid as 'Movies IDs,' though it does not explicitly state that radarrid is an array or how paging bounds 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?

The description clearly states a verb and resource: 'List movies metadata.' It also signals that it targets specific movies, which distinguishes it from broader list tools, but it does not explicitly differentiate from siblings like list_movies_blacklist or list_movies_history. The GET endpoint is included, reinforcing purpose.

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

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

No guidance is provided about when to use this tool over alternatives. There is no mention of when to prefer list_movies vs list_movies_wanted, list_movies_blacklist, etc., and no exclusions or conditions. The description only states what it does, not when to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP endpoint but does not disclose pagination behavior, default limits, or any side effects, though these are minor for a simple read operation.

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

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

The description is short and front-loaded with the purpose, followed by the endpoint and arguments. The Args section largely repeats schema information but does not create significant bloat.

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

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

With only two optional parameters, an output schema, and safety-oriented annotations, the description is close to sufficient. It is incomplete mainly because it does not clarify pagination semantics or contrast with sibling list tools, but no major context is missing for a basic read-only listing.

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 0%, so the description must carry parameter meaning. It only says 'start: Paging start integer' and 'length: Paging length integer', which adds minimal value beyond the property names and does not explain whether start is an offset, how length is bounded, or what happens when parameters are null.

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

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

The description names a specific verb and resource: it lists blacklisted movie subtitles, making the core purpose understandable. However, it does not differentiate itself from sibling tools like list_episodes_blacklist or list_movies, so it relies partly on the tool name for distinction.

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 about when to use this tool versus alternatives such as list_movies or list_movies_wanted. The description only provides the endpoint and paging arguments, leaving the selection context entirely to the agent's inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds only the endpoint URL and parameter listings, which are technical but not behavioral. It does not disclose pagination defaults, maximum page sizes, ordering, or how history events are defined. Given that annotations cover the safety profile, the description contributes minimal additional 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?

The description is compact and well-structured: a one-line purpose statement, the HTTP endpoint, and a precise list of arguments. Information is front-loaded and nothing is redundant. Every element earns its place.

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

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

For a read-only list tool with three optional params and an output schema present, the description provides the essential parameter semantics and endpoint. However, it leaves out context about what 'history events' contain or how pagination interacts with the radarrid filter. While not fatal, an agent might benefit from a note that paging is applied across filtered results. The lack of any usage guidance also undermines 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?

Schema coverage is 0%, so the description fully compensates. It explains each parameter: 'start: Paging start integer', 'length: Paging length integer', and 'radarrid: Movie ID'. This gives the agent actionable meaning that the bare schema (which only lists integer types with defaults) does not provide. It is clear enough for a simple paging/filter tool.

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 movies history events.' It explicitly narrows the scope to movies, distinguishing it from sibling tools like list_episodes_history. This makes the tool's purpose unambiguous without needing to inspect schema or siblings.

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

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

The description gives no guidance on when to use this tool versus alternatives. There are many similar list tools (e.g., list_episodes_history, list_movies, list_movies_blacklist) and no mention of scenarios, exclusions, or comparisons. The only hint is the resource name itself, which is not enough to route an agent correctly.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds modest value beyond this: the GET /api/movies/tags endpoint confirms the read-only nature, and the word "distinct" signals deduplicated results. It does not describe pagination, ordering, or response composition, but with this annotation coverage the bar is lower.

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 purpose sentence plus a one-line endpoint reference, with zero wasted words. For a parameterless read-only tool, this is the right size — every element earns its place.

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

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

Given the tool's low complexity (0 params, read-only), the presence of an output schema covering return values, and rich annotations covering safety/idempotency, the description is nearly complete for correct invocation. The only slight gap is the absence of any usage context or sibling differentiation, which is minor for such 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?

The tool has zero parameters with 100% schema coverage, so there is nothing for the description to explain about arguments. Per the rubric, the 0-param case warrants a baseline of 4 — the description correctly adds no filler about parameters that do not exist.

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?

"List all distinct tags assigned to any movie" names a specific verb (List), a specific resource (distinct tags), and a scope (any movie). This clearly differentiates it from siblings like list_movies (the movies themselves), list_series_tags (series tags), and list_movies_blacklist/history/wanted, so an agent can select it correctly without inspecting other schemas.

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

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

The usage context is implied by the purpose statement — an agent can infer it is for retrieving the universe of movie tags, likely for filtering or display. However, there is no explicit guidance, no exclusions, and no named alternatives (e.g., list_series_tags for series tags), which would be valuable given the large sibling set.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no meaningful behavioral context beyond restating the endpoint; it does not mention pagination behavior, filtering semantics, or any other operational traits.

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

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

The description is compact and front-loaded with the summary, followed by the endpoint and a short Args list. There is no wasted text, though the opening phrase 'List movies wanted subtitles' is grammatically awkward.

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 that all parameters are optional and an output schema exists, an agent can invoke this tool without arguments and interpret the response. Still, the meaning of 'wanted' and the exact role of radarrid are under-specified, and there is no usage guidance to help select the tool confidently.

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 0%, so the Args section is the only source of parameter meaning. It labels start and length as paging controls and radarrid as 'Movies ID to list', which adds some value beyond the schema's bare names and types. However, the radarrid description is ambiguous and does not clarify that it is an array or how multiple IDs behave.

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

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

The description states a clear action ('List') and resource ('movies wanted subtitles'), which distinguishes it from sibling tools like list_movies, list_movies_blacklist, and list_movies_history. However, the phrasing 'wanted subtitles' is slightly awkward and does not explicitly explain what 'wanted' means in this context.

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 about when to use this tool versus alternatives such as list_movies, list_movies_history, or list_episodes_wanted. The description only provides the endpoint and parameters, with no exclusions, prerequisites, or 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context such as auth requirements, response shape, or exceptions, but it does not contradict the annotations.

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

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

The description is compact and front-loaded, but the second line mostly repeats the first with the /api prefix added. It is not bloated, yet it also does not use its space to add semantic value.

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 parameterless, read-only tool with an output schema and strong annotations, the endpoint is nearly enough to call it. Still, the description lacks any statement of purpose or intended use, so an agent has to infer from the name and HTTP method.

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 schema coverage is 100%, so there is nothing for the description to clarify. The baseline for a parameterless tool 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 names an HTTP verb and a specific resource ('GET plex/autopulse/config'), so an agent can tell this retrieves the Plex Autopulse configuration and distinguish it from the other Plex-related siblings. It stops short of saying what the config contains or why you would fetch it, so it is clear but not as helpful as a semantic summary.

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 about when to choose this tool over alternatives, no prerequisites, and no exclusion criteria. The description only states the endpoint; it leaves all usage decisions to inference.

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