Server Quality Checklist

Tool Scores

• get_session_stateC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It implies a read-only inspection ('Retrieve') and mentions debugging, but does not explicitly state non-mutating behavior, performance implications, or any side effects. The word 'retrieve' hints at safety but is not declared.

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

  Conciseness2/5

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

  The description is a single 10-word sentence, which is extremely concise but under-specified for a tool with 11 parameters. While it has no fluff, it is not appropriately sized for the tool's complexity, missing necessary operational context.

  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 (11 parameters, modes, streaming options), the description is far from complete. It does not define 'aggregated', explain deltas vs full state, or mention any configuration nuances. The output schema exists, but the behavior and semantics of the tool are largely undefined.

  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 coverage is 82%, so most parameters are documented in the schema. The description adds 'aggregated' to clarify the output nature, but does not explain undocumented parameters like mode and since_version. The minimal description does not compensate for these gaps.

  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 a specific verb ('Retrieve') and resource ('aggregated session state') with a stated purpose ('for debugging and visibility'). It is distinct from siblings like manage_session which suggests management rather than read-only inspection.

  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 on when to use this tool versus alternatives such as manage_session or execute_flow. The description gives a high-level purpose but no conditions, exclusions, or prerequisites for invoking this tool.

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

• build_test_suiteC
  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 only states that it generates a suite from steps, but omits side effects like file writing (hinted in schema) or whether state is modified. The description adds minimal 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.

  Conciseness4/5

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

  The description is a single, compact sentence that directly states the core purpose. It is appropriately sized and front-loaded, though it could incorporate more behavioral context without becoming verbose.

  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 (9 parameters) and lack of annotations, the description is inadequate. It doesn't explain the generation process, output format (despite an output schema), or edge cases like session_id auto-resolution. The schema fills parameter details, but the description fails to provide overarching usage context.

  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 100%, so all 9 parameters are thoroughly documented in the schema. The main description does not add any parameter-specific details or clarifications beyond what the schema provides, justifying the baseline score of 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 explicitly states the verb 'Generate' and the resource 'Robot Framework test suite' from 'previously executed steps'. It clearly indicates the tool's function and distinguishes it from execution-oriented siblings like run_test_suite, though it doesn't explicitly name alternatives.

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

  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 such as run_test_suite or execute_flow. There's no mention of prerequisites, context, or scenarios where this tool is preferred, leaving the agent to infer usage.

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

• execute_flowC
  2.9/5.0
  Behavior2/5

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

  With no annotations at all, the description carries the full burden of disclosing side effects, state changes, and error behavior, but it does not do so. It does not mention that executing a flow may mutate session state, how failures or rethrows behave, or whether partial execution leaves side effects. The schema hints at these behaviors through fields like stop_on_failure and rethrow, but the description itself does not surface them.

  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 a single compact sentence with the core idea front-loaded and no filler. While it is lean and well ordered, it is also somewhat under-specified for such a complex tool, so it earns a 4 rather than a 5.

  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 14-parameter control-flow executor with no annotations and many structure-dependent fields, a one-line description is not enough to guide correct invocation. It does not explain how the structure parameter selects among if/for/try block parameters, what side effects flow execution has on the session, or how errors are handled. The presence of an output schema reduces the return-value burden, but the invocation and execution semantics remain under-specified.

  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 100%, so the input schema already documents all 14 parameters, including structure-specific fields like then_steps, except_steps, and max_iterations. The tool description adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description names a specific verb ('Execute'), a resource ('structured flow'), and enumerates the supported flow types ('if/for/try'), while scoping execution to a session. This makes it reasonably distinct from sibling tools like execute_step or execute_batch, though it does not explicitly name or contrast those alternatives.

  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 execute_flow versus execute_step, execute_batch, or other siblings. It only states the operation and the session context; there are no exclusions, conditions, or pointers to alternatives, so choosing this tool over its siblings is left entirely to inference.

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

• manage_attachC
  2.9/5.0
  Behavior2/5

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

  There are no annotations, so the description must carry the full burden of disclosing behavioral traits. 'Inspect or control' hints at mutation but does not disclose the potentially destructive force-stop/terminate/disconnect-all actions, side effects, or reversibility. The action enum documents these, but the description itself is silent.

  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 one concise, front-loaded sentence with no filler. It could be slightly more informative about destructive behavior, but as a high-level statement it is efficiently worded and easy to parse.

  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?

  The rich action enum and presence of an output schema cover much of what an agent needs to invoke the tool, but the top-level description still lacks usage context and safety warnings for a tool with highly destructive actions. It is adequate but has clear gaps.

  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 single parameter is 100% covered by schema descriptions with an exhaustive enum and per-action semantics, so the description does not need to add parameter detail. It also adds none, which is acceptable given the baseline for full schema coverage.

  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?

  'Inspect or control attach bridge configuration' names a specific verb and resource, making the tool's scope clear. It is not tautological and the 'attach bridge' resource distinguishes it from the sibling session/library tools, though it does not explicitly reference them.

  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 offers no guidance on when to use this tool versus manage_session or the other siblings, no mention of the default action, and no exclusions. The only usage hints come from the action enum in the schema, which the description itself does not surface.

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

• manage_library_pluginsC
  2.9/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden of explaining behavior. It implies reload is a mutating operation and inspect is non-mutating, but it does not disclose side effects, reversibility, permission requirements, or what diagnose actually does.

  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 four words with no filler, so it is very concise and front-loaded. However, the brevity creates ambiguity by substituting 'inspect' for the schema's more specific 'list' and 'diagnose' actions.

  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 tool with three distinct actions and no annotation coverage, a single generic sentence is not enough. An agent cannot tell what diagnose entails, what reload's consequences are, or when to reach for this tool instead of a sibling. The output schema covers return shape but not these behavioral and usage gaps.

  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?

  Input schema coverage is 100%, and the schema already documents both parameters, including the action enum and the conditional plugin_name. The description adds no parameter-specific meaning, but the baseline of 3 is appropriate because the schema handles the semantic load.

  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 identifies a specific resource ('library plugins') and high-level operations ('inspect or reload'), giving a general sense of purpose. However, it collapses the three concrete actions in the schema (list, reload, diagnose) into two umbrella verbs, and it does not explicitly mention 'diagnose' as a distinct operation.

  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 about when to use this tool or how to choose among list, reload, and diagnose. There is no mention of alternatives or exclusions, so the agent must infer usage solely from the schema enum and sibling names.

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

• set_library_search_orderC
  2.9/5.0
  Behavior2/5

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

  Annotations are absent, so the description carries the full burden. It only says 'set', which implies a mutation, but does not disclose consequences such as whether the order is replaced entirely, session-specific effects, permissions required, or any side effects. For a mutation tool, this is insufficient disclosure.

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

  Conciseness5/5

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

  The description is a single, focused sentence that front-loads the core action and purpose. There is zero waste—every word contributes meaning. It is optimally concise for its content.

  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?

  Despite having an output schema, the description lacks critical behavioral context: what an 'explicit order' means in practice, whether it replaces or merges with existing orders, and how it affects keyword resolution across sessions. Since annotations are missing, the description should fill this gap but does not.

  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 100%, with both parameters well-documented ('Library names in priority order (highest first)' and 'Session to apply the search order to'). The description adds no parameter-specific detail beyond the schema, so the baseline of 3 applies.

  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 'Set' and the resource 'library search order', with the purpose 'for keyword resolution'. It is distinct from siblings like manage_library_plugins and recommend_libraries, though it does not explicitly name them. The verb and resource are specific enough to differentiate.

  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?

  There is no guidance on when to use this tool versus alternatives. The description only states what it does, with no mention of conditions, exclusions, or scenarios where another tool would be more appropriate. This is a significant gap given the large sibling list.

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

• execute_stepB
  3.2/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 only states the purpose and does not reveal side effects, error handling, or return behavior. While schema parameter descriptions cover things like recording and timeouts, the top-level description itself lacks any 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys the core action with zero waste. It is appropriately sized and well-structured.

  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?

  With 15 parameters, an output schema, and rich sibling tools, the description is too minimal. It does not synthesize the overall behavior (e.g., how steps are recorded for build_test_suite, BDD grouping, or when to use this over execute_batch). The schema covers details, but the high-level context is missing.

  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 schema has 100% coverage with detailed descriptions for all 15 parameters. The one-sentence description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate given the high schema coverage.

  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 it executes a single Robot Framework keyword or Evaluate within a session, distinguishing it from siblings like execute_batch or execute_flow that handle multiple steps. The verb 'Execute' and resource 'single Robot Framework keyword' are specific and unambiguous.

  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 does not explicitly state when to use this tool versus alternatives. It mentions 'within a session' but provides no guidance on scenarios where execute_batch or execute_flow would be preferable. The only hint appears in the schema description for the keyword parameter, but that is not part of the tool description.

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

• run_test_suiteB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavior on its own. It only states 'validate or execute', but doesn't mention side effects (e.g., whether execution is destructive, whether it generates reports, whether it requires a running session) or any constraints. This is insufficient for an agent to predict the tool's impact, especially given the tool's complexity.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the tool's purpose. It avoids unnecessary detail and stays focused, scoring high on efficiency. There is no redundant wording or filler.

  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?

  Despite having eight parameters, nested options, and an output schema, the one-sentence description does not explain overall workflow, mode selection, or parameter combinations (e.g., session_id vs suite_file_path). The schema covers individual parameters, but the description lacks the high-level context needed for a tool this complex, especially with sibling tools that may overlap in functionality.

  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 schema already provides descriptions for all parameters (100% coverage), so the description does not need to repeat them. The description adds nothing about parameter usage, but the baseline is 3 given complete schema coverage. The description's lack of parameter context doesn't degrade the score, as the schema fills the gap.

  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 tool's function: 'Validate or execute a Robot Framework suite.' It specifies the resource (Robot Framework suite) and the actions (validate/execute), which is enough to distinguish it from sibling tools that target individual steps or flows. The verb is specific and the scope is unambiguous.

  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 offers no guidance on when to use this tool over alternatives like build_test_suite, execute_flow, or execute_step. It neither states conditions nor recommends alternatives, leaving the agent to infer usage from the tool name and schema. There is no mention of prerequisites or typical scenarios.

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

• intent_actionA
  3.6/5.0
  Behavior4/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 explains that the intent is resolved based on the session's active library, lists valid intents, and details the deprecation of extract_text. It does not explicitly state whether operations can be mutating (e.g., clicks, fills) or require permissions, but it does give substantive behavior context. A 4 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.

  Conciseness4/5

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

  The description is about 200 words, well-structured with paragraphs and bullet-like lists. It front-loads the purpose and valid intents, then addresses deprecation. It is not overly verbose and conveys key information efficiently, though it could be slightly tightened. A 4 reflects good organization without wasted words.

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

  Completeness5/5

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

  The description, combined with the extremely detailed schema (100% coverage) and an output schema, provides a complete picture. It explains the intent resolution, deprecation, and library-dependent behavior. Nothing critical is missing for an agent to call this tool correctly, especially given the parameter-rich schema.

  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 100%, so the baseline is 3. The description itself focuses on the intent mechanism and deprecation, not on individual parameters. All parameter meanings are already exhaustively documented in the schema (mode, force, commit, match, etc.). The description adds no new parameter semantics beyond what the schema provides, hence the baseline 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 states a specific verb ('Execute') and resource ('high-level intent that auto-resolves to the correct library keyword'), and lists valid intents. It is clear and not a tautology, though it does not explicitly differentiate from sibling tools like execute_step or execute_flow, so it earns a 4 rather than a 5.

  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 does not provide guidance on when to use this tool versus alternatives. It only mentions the deprecated extract_text and prefers extract, but does not say when to choose intent_action over execute_step, execute_flow, or other siblings. No when-to-use or when-not-to-use guidance is present.

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

• recommend_librariesA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description carries the full disclosure burden, but it only describes a suggestion/analysis behavior. It does not disclose that the default apply_search_order=true can mutate session search order, that check_availability defaults to true and probes the environment, or that use_llm_refinement can invoke ctx.sample(). These are material behavioral traits for an agent deciding whether to call this tool.

  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 reasonably compact and front-loaded with the core purpose, followed by scannable bullets. It is slightly repetitive because the opening sentence and the final sentence both express the recommending idea, but the structure helps an agent scan quickly.

  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?

  The output schema and high schema coverage remove the need to describe return values and parameter formats. However, for a 12-parameter, multi-mode tool with no annotations, the description omits important context such as session-mutating defaults and how the sampling/merge modes relate to the main recommendation workflow.

  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 100%, so the baseline is 3. The description adds no parameter-level meaning beyond naming 'scenario' as the input; the schema's own parameter descriptions already carry the mode, k, samples, and flag semantics.

  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 opens with a specific verb and object: 'Recommend libraries for a scenario or generate/merge sampling prompts.' It reinforces this with 'analyzes scenario text and suggests relevant libraries', and situates it among siblings by saying it runs after analyze_scenario and before execute_step and is used to discover which libraries provide needed functionality.

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

  Usage Guidelines4/5

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

  The 'WHEN TO USE THIS TOOL' section gives explicit triggers: immediately after analyze_scenario, on 'No keyword with name' errors, and when discovering needed libraries. It lacks explicit when-not-to-use guidance or named alternative tools such as check_library_availability or find_keywords, so it is clear but not a full routing map.

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

• check_library_availabilityA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must convey behavioral traits. It states 'Verify' which implies a read-only check, but also mentions 'imported/installed' without clarifying whether it performs installation or just checks availability. It does not disclose side effects, error behavior, or what happens when a library is missing. This is a significant gap for a tool that may have installation implications.

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

  Conciseness5/5

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

  The description is two sentences with the primary purpose front-loaded in the first sentence and usage recommendation in the second. No superfluous words, concise and scannable, making it easy for an agent to quickly grasp the tool's role.

  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?

  The tool has a simple one-parameter schema and an output schema, so the description does not need to explain return values. However, it leaves ambiguity about whether the tool only checks or also installs libraries, and what happens for unavailable libraries. Given the lack of annotations, this ambiguity affects completeness. While the usage workflow is clearly defined, the behavioral gap keeps it from being fully complete.

  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 input schema already provides a complete description for the 'libraries' parameter, including a preference for using recommend_libraries output (100% schema coverage). The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description states a specific verb 'Verify' and a resource 'specified Robot Framework libraries', clearly indicating the tool checks import/install availability. It does not explicitly name a sibling it is not, but the context of recommendation workflow helps distinguish it from 'recommend_libraries'. Overall, purpose is clear and actionable.

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

  Usage Guidelines5/5

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

  The description explicitly recommends this as step 3 after 'analyze_scenario' and 'recommend_libraries', and advises using recommended names to avoid unnecessary checks. This provides clear when-to-use guidance and implies the tool should be used after library recommendation, not before, effectively routing the agent to the correct workflow.

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

• execute_batchA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses sequential execution, variable chaining via ${STEP_N}, and the 0-based/1-based indexing ambiguity with a preference. It does not elaborate on recovery mechanics beyond 'with recovery', but the schema covers on_failure parameters. The disclosed sequencing and indexing are valuable behavioral insights.

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

  Conciseness5/5

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

  The description is concise and well-structured. The first sentence states the core purpose, followed by a clear benefit (round-trip reduction), then precise behavioral details about sequencing and indexing. Every sentence carries necessary information without redundancy.

  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 5 parameters and existing output schema, the description covers the essential operational context: what it does, how steps chain, and indexing rules. It omits details like failure policies or timeout expectations, but those are documented in the schema parameters, so the description is sufficiently complete for an agent to call correctly.

  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 coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the ${STEP_N} indexing nuances (0-based vs 1-based) and the preference when ambiguous, which is not fully specified in the schema's step description. This enriches the semantic understanding of arguments.

  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 executes multiple RF keywords in one call, with recovery and variable chaining. It differentiates from single-step siblings like execute_step by emphasizing batch execution and round-trip reduction, though it could more explicitly contrast with execute_flow or other batching tools.

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

  Usage Guidelines3/5

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

  The description implies a batch use case via 'multiple keywords' and 'reduces N MCP round-trips to 1', but it does not explicitly state when to choose this over execute_step (e.g., for single keywords or BDD grouping). The schema notes BDD limitations, but the description itself lacks explicit alternatives or exclusions.

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

• get_locator_guidanceA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden. It explains the tool's action ('provide guidance') but does not disclose side effects, return format (though output schema exists), or any limitations. It is not misleading, but it does not add behavioral context beyond the basic function.

  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, front-loading the core purpose and then detailing two important use cases. It is somewhat long but each sentence provides useful information, and the sections are clearly separated. No redundant words.

  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?

  The description, combined with the presence of an output schema, covers the main usage scenarios effectively. It explains why and when to use it for API and visual cases, which are the most specialized. The general case (any of the listed libraries) is mentioned but could be slightly more elaborated, yet it is sufficient.

  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 coverage is 100%, but the description adds significant value for the `library` parameter by specifying aliases ('requests'/'api', 'visual'/'screenshot') and detailing what guidance each subset includes (API cookbook contents, visual validation scenarios). This enriches the schema's basic description.

  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 tool's purpose: providing locator/selector guidance for specific libraries (Browser, SeleniumLibrary, etc.). It distinguishes itself from siblings by highlighting specific use cases for API testing and visual validation, making it obvious when this tool is relevant versus others.

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

  Usage Guidelines4/5

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

  It gives explicit when-to-use guidance for two major scenarios: API testing (library='requests') and visual validation (library='visual'), including details like 'BEFORE writing Evaluate-based assertions.' However, it does not explicitly state when NOT to use it or mention alternatives beyond siblings, though the context makes it clear.

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

• get_keyword_infoA
  4.2/5.0
  Behavior3/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 does explain the modes and session scoping, but it does not explicitly state that it is a read-only operation or disclose potential behaviors like the library-mismatch error and artifact externalisation (though these are detailed in the schema). The description adds some context but not a comprehensive behavioral profile.

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

  Conciseness5/5

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

  The description is concise: two sentences and a list of modes. The primary purpose is front-loaded, and every sentence contributes. No fluff or redundancy.

  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 (5 parameters, multiple modes) and the presence of a detailed output schema and exhaustive schema descriptions, the description is sufficient. It covers the primary use case and mode enumeration. It omits some nuances (e.g., externalisation) but those are covered in the schema, so the description is adequately complete.

  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 100%, so the baseline is 3. The description adds value by clarifying the modes and the role of session_id (e.g., scoping the lookup), but it does not go deeply beyond what the schema already documents. It meets but does not exceed the baseline.

  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 a specific action ('Get keyword/library docs or parse a signature') with a concrete verb and resource. It also enumerates distinct modes, making the tool's scope unambiguous and distinguishing it from other lookup tools like find_keywords.

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

  Usage Guidelines5/5

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

  Explicitly instructs when to use: 'Call this before execute_step when you know the keyword name but not its arguments.' It also lists modes, which implicitly guide when each is appropriate. This is clear, actionable guidance with no reliance on inference.

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

• resume_batchA
  4.2/5.0
  Behavior4/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 behavior disclosure. It clearly explains that the tool reruns the failed step, optionally injects fix_steps before it, and continues remaining steps from the original batch. It does not discuss side effects or edge cases like repeated failures, but the core execution behavior is transparent.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core purpose, then uses a numbered list to clarify the exact order of operations. Every sentence earns its place; there is no redundant or filler content.

  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?

  The description provides the essential precondition, the execution sequence, and the optional fix-step mechanism. Since an output schema exists, return-value details are not required, and the parameter schema covers format specifics. It could be slightly more explicit about not using this tool for non-failed batches, but the current framing is sufficient.

  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 100%, so the schema already documents each parameter thoroughly. The description adds workflow context around 'fix_steps' and the failure-point relationship, but does not meaningfully expand on parameter formats or defaults beyond what the schema provides.

  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 uses a specific verb ('resume') with a clear resource ('a failed batch'), and precisely states the behavior: re-run the failed step and continue remaining steps. It clearly differentiates itself from execute_batch by describing the failure-point continuation workflow rather than initial execution.

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

  Usage Guidelines4/5

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

  The description gives a specific trigger condition: 'After execute_batch returns status=FAIL with a batch_id, call this to...' This is clear enough for an agent to know when to invoke it. It does not explicitly list exclusions or alternative tools, but the failure condition and step-by-step follow-up make the usage context unambiguous.

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

• analyze_scenarioA
  4.3/5.0
  Behavior4/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 — and it mostly succeeds. It discloses the mutation behavior prominently (CREATES a session), explains the side effects of misuse (redundant session churn), and instructs the agent to save and reuse the returned session_id. It could note failure/error behavior, but the key behavioral traits are covered.

  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?

  Well-structured with a WORKFLOW block, numbered steps, and a highlighted CRITICAL note, with the key routing information (front door, don't call manage_session) front-loaded. Minor redundancy exists between the WORKFLOW summary and the numbered list, but every section earns its place for an orchestration tool.

  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?

  For a complex orchestration tool, the description covers the full workflow: session creation, context detection, library auto-configuration, and session_id reuse across subsequent calls. An output schema exists, so return-value details are not the description's responsibility. The only gap is explicit error/failure behavior.

  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 100% with already-rich parameter text, including the deterministic desktop-forcing behavior of the context enum. Baseline 3 applies: the description confirms the workflow relationship to session_id but adds little parameter-level meaning beyond the schema.

  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 states a specific verb+resource ('Analyze a natural-language scenario into structured intent and create a session') and explicitly names it as 'the single front door'. It clearly distinguishes itself from the sibling manage_session by warning against redundant session churn, so an agent can tell it apart without opening other schemas.

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

  Usage Guidelines5/5

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

  It gives explicit when-to-use guidance ('your FIRST tool call for any test scenario') and explicit when-not-to-use guidance ('do NOT also call manage_session(action="init")'). It names the alternative tool and the failure mode it avoids, leaving nothing to inference.

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

• find_keywordsA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. The detailed strategy parameter documentation discloses important behavior: semantic search has an optional dependency and falls back to pattern matching when not installed, catalog strategy is a literal substring filter that returns 0 for multi-word natural-language queries, and session strategy requires a session_id. It does not explicitly state read-only/no-side-effects, but 'Discover' plus the described search mechanics make the behavior clear.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose, immediately followed by actionable usage guidance. The long parameter documentation is dense but each part earns its place given the tool's complexity, and no redundant or filler text is present.

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

  Completeness5/5

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

  The tool has 8 parameters and an output schema, but the description covers all necessary context: when to call it, how each strategy behaves, library filtering, strict mode, and session requirements. An agent can correctly invoke this tool without needing to infer missing information.

  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?

  Schema coverage is 100%, so the baseline is 3, but the parameter descriptions go far beyond names. Each strategy is explained with its intended use and limitations, library_name semantics clarify sibling compatibility and precedence, and strict_library is described with a concrete example. This gives the agent everything needed to choose parameter values correctly.

  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 states a specific verb and resource: 'Discover Robot Framework keywords using multiple strategies.' It clearly distinguishes this discovery/search tool from execution tools like execute_step and detail tools like get_keyword_info by framing the tool as the way to find keywords before executing them.

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

  Usage Guidelines4/5

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

  The description provides an explicit 'WHEN TO USE THIS TOOL' section with concrete triggers such as 'ALWAYS before calling execute_step with an unfamiliar keyword' and when an error says keyword not found. It does not explicitly name alternative tools for cases like retrieving details for a known keyword, so it stops short of full when-not guidance.

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

• manage_sessionA
  4.8/5.0
  Behavior5/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 reveals important side effects and constraints: init after analyze_scenario causes redundant churn, end_test status is only session tracking metadata and does not affect the generated .robot file, add_data_row rows appear under [Template], and start_test/end_test are local mode only. This is strong, specific behavioral transparency.

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

  Conciseness5/5

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

  The description is long but appropriately structured for a multi-action tool: it opens with the key routing warning, then provides workflows, per-action parameters, return behavior, and examples. Every section is useful, and the most important usage guidance is front-loaded.

  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?

  For a tool with 24 parameters, no annotations, and zero schema descriptions, the description is unusually comprehensive: it covers workflows, all major actions, return values, failure guidance, and common usage examples. The main gap is the undocumented set_tool_profile/tool_profile-related parameters and a few schema-only fields, leaving some invocation paths unexplained.

  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 schema has 0% description coverage, so the description compensates in detail for most parameters: each action lists its relevant params, and examples clarify data shapes such as variables, test_setup, and args. However, several schema parameters—profile, tool_profile, scenario, model_name, model_tier, and the set_tool_profile action—are not documented in the description, and template is referenced but not listed under start_test params. This prevents a perfect score.

  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 opening sentence states the tool's scope: "Manage session lifecycle: initialize, configure libraries/variables, and organize tests." It then differentiates itself sharply from analyze_scenario, which is the session-creating front door. This makes the tool's purpose and boundaries immediately clear.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use and when-not-to-use guidance: prefer analyze_scenario for new scenarios, do not call action="init" right after analyze_scenario, and use manage_session for explicit session operations on existing sessions. It also provides concrete single-test and multi-test workflows and an explicit alternative for the init action.

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

• visual_checkA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the burden. It discloses default behavior (saves to disk, returns path), the effect of return_image=true (image content block), the required ROBOTMCP_SCREENSHOT_MODE, and graceful degradation on failure. This is rich and actionable.

  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 long but every sentence earns its place. It is front-loaded with the core action and then covers options, environment, and compatibility. The structure is logical and not repetitive, though slightly dense.

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

  Completeness5/5

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

  Given no output schema and no annotations, this description is near-complete: it covers purpose, usage scenarios, return types, environmental requirements, supported libraries, and failure behavior. An agent would have enough context to invoke it correctly.

  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 coverage is 0%, so the description must compensate. It thoroughly explains return_image (default false, mode requirements) and implies filename through 'saves the screenshot to disk'. session_id is left inferred, but overall it adds significant meaning to otherwise bare parameters.

  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 states a specific verb and resource: 'Capture a screenshot of the current UI for VISUAL validation'. It explicitly distinguishes the tool's use case (checks DOM/ARIA can't do) from other tools. This makes it easy to differentiate from siblings.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance by listing scenarios like 'canvas/image text, layout/overlap, obscured elements, color, charts' and directs to 'Call get_locator_guidance(library="visual")' for more. It also implies not to use when DOM/ARIA checks suffice.

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