Server Quality Checklist

Tool Scores

• add_to_playlistC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It states the tool adds a movie and mentions success/error messages, but doesn't address permissions, rate limits, whether duplicates are allowed, or what happens if the playlist/movie doesn't exist. For a mutation tool with zero annotation coverage, this is inadequate.

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

  Conciseness4/5

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

  The description is appropriately sized with clear sections (purpose, parameters, returns). The first sentence states the core function, followed by structured details. No wasted words, though the 'Returns' section could be more specific.

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

  Completeness2/5

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

  For a mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It covers basic purpose and parameters but lacks crucial context about error conditions, prerequisites, behavioral details, and relationships with sibling tools.

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

  Parameters3/5

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

  Schema description coverage is 0%, but the description explicitly lists both parameters with brief explanations ('key of the playlist', 'key of the movie'). This adds meaningful semantics beyond the bare schema, though it doesn't explain what constitutes a valid key format or where to obtain these keys.

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

  Purpose4/5

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

  The description clearly states the action ('Add a movie') and target resource ('to an existing playlist'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'create_playlist' or 'get_playlist_items' beyond the obvious functional difference.

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

  Usage Guidelines2/5

  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 doesn't mention prerequisites (e.g., playlist must exist), exclusions, or clarify relationships with sibling tools like 'create_playlist' or 'get_playlist_items'.

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

• get_movie_detailsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns a 'formatted string with movie details or an error message', which adds some context about output format and error handling. However, it lacks details on permissions, rate limits, or whether it's a read-only operation, which are important for a tool with no annotations.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded, starting with the core purpose followed by parameter and return details. It uses clear sections ('Parameters:', 'Returns:') for structure, with no wasted sentences, making it efficient and easy to scan.

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

  Completeness3/5

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

  Given the tool has no annotations, no output schema, and low schema coverage, the description is minimally adequate. It covers the basic purpose, parameter, and return format, but lacks depth in usage guidelines, behavioral traits, and parameter details, which are needed for a tool with such sparse structured data.

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

  Parameters3/5

  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 the parameter 'movie_key' and explains it as 'The key identifying the movie', adding basic meaning beyond the schema's title 'Movie Key'. However, it doesn't provide examples, format details, or constraints, leaving gaps in understanding how to use the parameter effectively.

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

  Purpose4/5

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

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed information about a specific movie'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_movie_genres' or 'search_movies', which might provide overlapping or related functionality.

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

  Usage Guidelines2/5

  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 doesn't mention prerequisites, such as needing a valid movie_key, or compare it to siblings like 'search_movies' for finding movies or 'get_movie_genres' for genre-specific details, leaving the agent to infer usage context.

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

• get_movie_genresC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'A formatted string of movie genres or an error message,' which hints at output behavior but lacks details on error conditions, rate limits, authentication needs, or side effects. For a tool with zero annotation coverage, this is insufficient to fully inform the agent.

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

  Conciseness4/5

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

  The description is concise and well-structured, with a clear purpose statement followed by parameter and return sections. It uses minimal words without redundancy, making it easy to parse. However, it could be more front-loaded by integrating the return info into the main sentence for better flow.

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

  Completeness3/5

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

  Given the tool's low complexity (one parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic purpose and output format but lacks usage guidelines, detailed behavioral context, and full parameter semantics. It is adequate as a minimum viable description but not fully comprehensive for optimal agent use.

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

  Parameters3/5

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

  The description adds minimal parameter semantics: it mentions 'movie_key' as 'The key of the movie,' which provides basic meaning. However, with 0% schema description coverage and only one parameter, the baseline is 4 for zero parameters, but here it compensates slightly. It does not explain what a 'movie_key' is (e.g., an ID, title, or other identifier), so it adds limited value beyond the schema.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get genres for a specific movie.' It specifies the verb ('Get') and resource ('genres for a specific movie'), making the intent unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_movie_details' or 'search_movies', which might also involve movie data retrieval, so it falls short of a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_movie_details' (which might include genres) or 'search_movies', nor does it specify prerequisites or exclusions. This lack of contextual usage information limits its effectiveness for an AI agent.

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

• get_playlist_itemsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves items and returns a formatted string or error, but lacks details on permissions, rate limits, pagination, or what the formatted string includes (e.g., item names, IDs). For a read operation without annotations, this is insufficient.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded, starting with the core purpose followed by parameter and return details. It avoids unnecessary fluff, though the structure could be slightly improved by integrating the parameter explanation more seamlessly rather than as a separate section.

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

  Completeness2/5

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

  Given the tool's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It doesn't cover behavioral aspects like error conditions or output format details, and with no sibling differentiation, it falls short of providing full context for effective use by an AI agent.

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

  Parameters3/5

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

  The description adds minimal semantics beyond the input schema, which has 0% description coverage. It explains that 'playlist_key' identifies the playlist to retrieve items from, but doesn't clarify the key's format (e.g., numeric ID, string name) or provide examples. With one parameter, the baseline is 4, but the lack of detail reduces it to 3.

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

  Purpose4/5

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

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('items in a specific playlist'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_playlists' (which might list playlists themselves rather than items within one), leaving room for potential confusion.

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

  Usage Guidelines2/5

  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 doesn't mention siblings like 'list_playlists' for listing playlists or 'add_to_playlist' for modifying playlists, nor does it specify prerequisites such as needing an existing playlist key. This lack of context could lead to misuse.

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

• create_playlistB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It states the tool creates a playlist and returns a success/error message, but lacks critical behavioral details: it doesn't specify required permissions, whether movie keys must be valid or exist, if there are rate limits, if the playlist is private/public by default, or what happens on duplicate names. This is a significant gap for a mutation tool with zero annotation coverage.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded with the core purpose in the first sentence. The parameter and return sections are structured clearly, with no redundant information. However, the return statement could be more concise (e.g., 'Returns success or error details').

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

  Completeness2/5

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

  Given the tool's complexity (a mutation with 2 parameters), no annotations, and no output schema, the description is incomplete. It covers basic purpose and parameters but lacks behavioral context (e.g., permissions, error conditions), usage guidelines, and detailed return value explanation. This is inadequate for a tool that creates resources.

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

  Parameters4/5

  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 adds meaningful semantics: it explains that 'name' is the desired name for the playlist and 'movie_keys' is a comma-separated string of movie keys to include. This clarifies the format and purpose beyond the schema's basic titles, though it doesn't detail constraints like length limits or key validation.

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

  Purpose4/5

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

  The description clearly states the action ('Create a new playlist') and the resource ('playlist'), specifying it includes movies. It distinguishes from siblings like 'add_to_playlist' (which modifies existing playlists) and 'list_playlists' (which reads playlists). However, it doesn't explicitly differentiate from all siblings (e.g., 'delete_playlist' is clearly different).

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

  Usage Guidelines2/5

  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 doesn't mention prerequisites (e.g., needing valid movie keys), exclusions (e.g., not for updating existing playlists), or direct alternatives like 'add_to_playlist' for modifying playlists. Usage is implied only by the tool's name and basic purpose.

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

• delete_playlistB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a playlist and mentions success/error messages, but lacks details on permissions required, whether deletion is irreversible, rate limits, or side effects (e.g., impact on associated items). This is a significant gap for a destructive operation.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded, starting with the core action. The parameter and return sections are structured but could be more integrated; overall, it avoids unnecessary verbosity while covering essential points efficiently.

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

  Completeness2/5

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

  Given the tool's complexity (destructive operation with no annotations and no output schema), the description is incomplete. It lacks critical context such as authentication needs, error handling specifics, or behavioral nuances, making it inadequate for safe and effective use by an AI agent.

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

  Parameters3/5

  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 adds meaning by explaining that 'playlist_key' identifies the playlist to delete, which clarifies the parameter's purpose beyond the schema's title ('Playlist Key'). However, it does not provide format examples or constraints, leaving some ambiguity.

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

  Purpose5/5

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

  The description clearly states the specific action ('Delete') and resource ('a playlist from the Plex server'), distinguishing it from sibling tools like 'create_playlist' or 'list_playlists'. It directly addresses what the tool does without being tautological.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing playlist), exclusions, or compare it to related tools like 'add_to_playlist' or 'get_playlist_items', leaving usage context unclear.

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

• list_playlistsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return format ('formatted string of playlists or an error message'), which is helpful, but lacks critical details like whether this requires authentication, how many playlists might be returned (pagination?), or if there are rate limits. For a read operation with zero annotation coverage, this leaves significant gaps.

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

  Conciseness4/5

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

  The description is brief and front-loaded with the core action ('List all playlists in the Plex server'), followed by a concise note on returns. Both sentences are necessary—the first defines the purpose, and the second clarifies output format—with no wasted words.

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

  Completeness3/5

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

  Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose and output format, which might suffice for a straightforward list operation, but lacks context about authentication, performance, or sibling tool differentiation that could help an agent use it effectively.

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

  Parameters4/5

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

  The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain any parameters, so it appropriately focuses on the action and output. A baseline of 4 is justified since there are no parameters to document.

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

  Purpose4/5

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

  The description clearly states the verb ('List') and resource ('all playlists in the Plex server'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'get_playlist_items' or 'create_playlist', which would require more specific scope definition.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'get_playlist_items' (which presumably retrieves items within a specific playlist) or 'search_movies' (which might find content across playlists). The description only states what it does, not when it's appropriate.

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

• recent_moviesB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format ('A formatted string of recent movies or an error message'), which adds some value, but fails to cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or error conditions beyond a generic mention. For a tool with zero annotation coverage, this is insufficient.

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

  Conciseness4/5

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

  The description is well-structured with clear sections for purpose, parameters, and returns, using minimal sentences that each serve a purpose. It could be slightly more front-loaded by integrating parameter details into the main description, but overall it's efficient and easy to scan.

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

  Completeness3/5

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

  Given the tool's low complexity (one parameter, no output schema, no annotations), the description is adequate but has gaps. It covers the basic purpose and parameter semantics, but lacks usage guidelines and full behavioral transparency (e.g., no mention of read-only nature or error handling details), making it minimally viable but not fully complete.

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

  Parameters4/5

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

  The description adds meaningful context for the single parameter 'count' by explaining it as 'The maximum number of recent movies to return', which clarifies its role beyond the schema's basic type and default. Since schema description coverage is 0% and there's only one parameter, this compensation is effective, though not exhaustive (e.g., no range or constraints mentioned).

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

  Purpose4/5

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

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('recently added movies from the Plex library'), making it easy to understand what it does. However, it doesn't explicitly differentiate itself from sibling tools like 'search_movies' or 'get_movie_details', which prevents a perfect score.

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

  Usage Guidelines2/5

  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 'search_movies' or 'get_movie_details'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the purpose alone.

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

• search_moviesA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that the tool returns 'a formatted string of up to 5 matching movies (with a count of any additional results)' and handles errors, which adds useful context about output format and limitations. However, it doesn't mention performance characteristics, authentication requirements, or whether this is a read-only operation (though 'search' implies it likely is).

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

  Conciseness4/5

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

  The description is well-structured with clear sections for purpose, parameters, and returns. It's appropriately sized for a tool with 13 parameters. However, the parameter explanations could be slightly more concise, and the purpose statement could be more front-loaded with key limitations (like the 5-result limit).

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

  Completeness4/5

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

  Given the tool's complexity (13 parameters, no annotations, no output schema), the description does a good job of explaining what the tool does, what parameters mean, and what to expect in return. The main gap is the lack of usage guidance relative to sibling tools. The description compensates well for the missing schema descriptions and annotations.

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

  Parameters5/5

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

  The schema description coverage is 0%, so the description must fully compensate. It provides detailed semantic explanations for all 13 parameters, including examples like 'rating (e.g., "PG-13")' and clarifications like 'True returns only watched movies, False only unwatched.' This adds significant value beyond the basic parameter names in the schema.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Search for movies in your Plex library using optional filters.' This specifies the verb ('search'), resource ('movies'), and context ('Plex library'). However, it doesn't explicitly differentiate from sibling tools like 'recent_movies' or 'get_movie_details', which prevents a perfect score.

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

  Usage Guidelines2/5

  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 doesn't mention sibling tools like 'recent_movies' for recently added movies or 'get_movie_details' for detailed information about specific movies. There's no context about prerequisites, limitations, or when this search tool is most appropriate.

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