Server Quality Checklist

Tool Scores

• safari_get_performance_metricsC
  2.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 carries the full burden of behavioral disclosure. 'Get page performance metrics' implies a read-only operation, but it doesn't specify whether this requires an active session, what the output format might be, or if there are any rate limits or permissions needed. The description lacks details on what 'performance metrics' encompass, leaving behavioral traits unclear.

  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 'Get page performance metrics' is a single, clear sentence that efficiently conveys the core action without unnecessary words. It's front-loaded with the key information, making it easy to parse quickly. There's no wasted text, and it directly addresses the tool's function in a minimal format.

  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 complexity of performance metrics and the lack of annotations and output schema, the description is incomplete. It doesn't explain what types of metrics are returned (e.g., numeric values, timestamps, categories) or any dependencies, such as needing an active session. For a tool that likely outputs structured data, more context is needed to guide effective 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 input schema has 100% description coverage, with 'sessionId' documented as 'Session identifier'. The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining how the sessionId relates to performance metrics or providing examples. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

  Purpose3/5

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

  The description 'Get page performance metrics' states the verb ('Get') and resource ('page performance metrics'), making the purpose clear at a basic level. However, it doesn't distinguish this tool from potential alternatives or specify what types of performance metrics are included (e.g., load times, resource timing, memory usage), leaving it somewhat vague compared to more specific descriptions.

  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. Given sibling tools like 'safari_get_page_info' and 'safari_get_console_logs', there's no indication of whether this tool is for real-time metrics, historical data, or specific performance aspects. Without any context on prerequisites or exclusions, users must infer usage from the tool name alone.

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

• safari_clear_console_logsC
  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 implies a destructive action ('Clear') but does not specify if this is irreversible, requires specific permissions, affects other session data, or has side effects like resetting logs. This leaves significant gaps in understanding the tool's behavior, warranting a low score.

  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, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded and wastes no space, earning a perfect score for conciseness.

  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 destructive nature (implied by 'Clear'), no annotations, and no output schema, the description is insufficient. It fails to address critical aspects like what 'clearing' entails, potential impacts, or return values, making it incomplete 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?

  The input schema has 100% description coverage, with 'sessionId' documented as 'Session identifier'. The description adds no additional meaning beyond this, such as format examples or constraints. According to the rules, with high schema coverage, the baseline is 3, which is appropriate here.

  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 ('Clear') and the resource ('captured console logs for a session'), making the purpose understandable. It distinguishes from siblings like 'safari_get_console_logs' by specifying a destructive operation, though it doesn't explicitly name alternatives. This earns a 4 for clarity without full sibling differentiation.

  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 'safari_clear_network_logs' or 'safari_close_session', nor does it mention prerequisites like needing an active session. Without any context on usage scenarios or exclusions, it scores a 2 for lacking guidance.

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

• safari_clear_network_logsC
  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 clears logs, implying a destructive mutation, but doesn't specify if this is irreversible, requires specific permissions, or has side effects (e.g., affecting session state). For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential information.

  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 destructive nature (clearing logs) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like irreversibility, error conditions, or what happens after clearing (e.g., does it return confirmation?). For a mutation tool with no structured safety hints, more context is needed to guide safe usage.

  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 has 100% description coverage, with the single parameter 'sessionId' documented as 'Session identifier'. The description doesn't add any meaning beyond this, such as explaining what a session is or where to obtain the ID. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

  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 ('Clear') and target resource ('captured network logs for a session'), making the purpose immediately understandable. It distinguishes from sibling tools like 'safari_clear_console_logs' by specifying network logs rather than console logs. However, it doesn't explicitly mention that this is a destructive operation, which would make it fully specific.

  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 an active session), when not to use it (e.g., if logs are needed for analysis), or how it relates to siblings like 'safari_get_network_logs'. This leaves the agent to infer usage from context alone.

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

• safari_execute_scriptC
  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. It mentions execution but doesn't disclose critical behavioral traits such as whether this requires an active session, potential side effects (e.g., modifying page state), error handling, or security implications. This is a significant gap for a tool that executes code in a browser.

  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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.

  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 complexity of executing JavaScript in a browser, the description is insufficient. With no annotations, no output schema, and a lack of behavioral details (e.g., return values, error cases), it leaves the agent with incomplete information. This is inadequate for a tool that performs a potentially impactful operation.

  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%, providing clear documentation for all parameters (sessionId, script, args). The description adds no additional meaning beyond the schema, such as examples of script usage or context for args. Baseline 3 is appropriate when the schema handles parameter documentation adequately.

  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 ('Execute JavaScript') and context ('in the browser context'), which is specific and unambiguous. However, it doesn't differentiate from potential sibling tools like 'safari_inspect_element' that might also involve browser interaction, so it doesn't reach the highest 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. With siblings like 'safari_get_page_info' or 'safari_inspect_element', there's no indication of scenarios where executing JavaScript is preferred or required, leaving the agent without usage context.

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

• safari_get_console_logsC
  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 for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires an active session, what format the logs return in, if there are rate limits, or any error conditions. The mention of 'for debugging' adds minimal context but leaves critical operational details unspecified.

  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, efficient sentence that states the core purpose without unnecessary words. Every word earns its place, making it appropriately sized and front-loaded for quick understanding.

  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 no annotations, no output schema, and a read operation with parameters, the description is incomplete. It doesn't explain what the tool returns (log format, structure, or content), doesn't mention dependencies like requiring an active session, and doesn't differentiate from sibling tools. For a debugging tool in a suite with multiple logging options, this leaves significant 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 description doesn't mention any parameters, but schema description coverage is 100% with both parameters well-documented in the schema. The baseline score of 3 is appropriate since the schema adequately describes 'sessionId' and 'logLevel' with enum values, and the description doesn't need to compensate for schema 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 the verb 'Get' and resource 'browser console logs' with the purpose 'for debugging', making the tool's function immediately understandable. However, it doesn't differentiate from its sibling 'safari_get_network_logs' which also retrieves logs, leaving some ambiguity about when to choose console logs versus network logs.

  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 'safari_get_network_logs' or 'safari_get_page_info'. It mentions 'for debugging' which gives a general context, but offers no explicit when/when-not instructions or prerequisites for usage.

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

• safari_get_network_logsC
  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 full burden. It mentions 'Get' and 'performance analysis,' implying a read-only operation, but fails to disclose behavioral traits like whether this requires an active session, if logs are real-time or historical, potential rate limits, or data format. This leaves significant gaps for an agent to understand operational 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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

  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 lack of annotations and output schema, the description is incomplete for a tool that likely returns complex log data. It doesn't explain what the logs contain, their format, or how they relate to performance analysis, leaving the agent with insufficient context to use the tool effectively beyond basic invocation.

  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 has 100% coverage with a clear description for 'sessionId,' so the description adds no additional parameter information. This meets the baseline score of 3, as the schema adequately documents the single required parameter without needing extra details from the description.

  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 ('Get') and resource ('network activity logs') with a purpose ('for performance analysis'), making the tool's function understandable. However, it doesn't explicitly differentiate from sibling tools like 'safari_get_console_logs' or 'safari_get_performance_metrics', 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?

  No guidance is provided on when to use this tool versus alternatives. With siblings like 'safari_get_console_logs' and 'safari_get_performance_metrics' available, the description lacks context on selection criteria, such as whether this tool is for network-specific logs or how it complements other logging tools.

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

• safari_get_page_infoC
  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 what the tool does but lacks critical details: it doesn't specify if this is a read-only operation, what permissions are required, how it handles errors (e.g., invalid sessionId), or the format of returned data (e.g., JSON structure). This leaves significant gaps for safe and effective use.

  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 extremely concise and front-loaded, consisting of a single, clear sentence that directly states the tool's function. There is no wasted language or unnecessary elaboration, making it efficient for quick comprehension.

  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 complexity of browser automation tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a JSON object with URL and title fields), error conditions, or dependencies on other tools like 'safari_start_session'. This leaves the agent with insufficient context for reliable 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 schema description coverage is 100%, with the single parameter 'sessionId' fully documented in the schema. The description adds no additional parameter information beyond what the schema provides, such as context on where to obtain the sessionId or its format. This meets the baseline for high schema coverage but doesn't enhance understanding.

  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 specific verbs ('Get') and resources ('current page URL and title'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'safari_get_console_logs' or 'safari_get_network_logs', which also retrieve information but for different resources.

  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 an active session), exclusions, or comparisons to siblings like 'safari_inspect_element' or 'safari_get_performance_metrics', leaving the agent to infer usage from context alone.

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

• safari_inspect_elementC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but provides minimal behavioral insight. It implies a read-only operation ('inspect and get') but doesn't disclose critical traits: whether it requires specific permissions, affects page state, has rate limits, returns structured data, or handles errors. This is inadequate for a tool with potential side effects in a browser 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, efficient sentence with zero waste. It's front-loaded with the core action and outcome, making it easy to parse quickly without unnecessary elaboration.

  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 no annotations and no output schema, the description is incomplete for a tool that interacts with browser sessions. It lacks details on return values (e.g., what properties are retrieved), error conditions, session management requirements, and how it fits within the sibling tool ecosystem, leaving significant gaps for 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 100%, so the schema already documents both parameters ('sessionId' and 'selector'). The description adds no additional meaning beyond implying these are used for inspection, maintaining the baseline score of 3 where the schema handles parameter documentation 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 verb ('inspect') and resource ('DOM element') with the outcome ('get its properties'). It distinguishes from most siblings (e.g., screenshot, navigation, logs) but doesn't explicitly differentiate from similar inspection tools like 'safari_get_page_info' or 'safari_execute_script', which might also retrieve element data.

  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 is provided. It doesn't mention prerequisites (e.g., needing an active session), compare to siblings like 'safari_get_page_info' for broader page data, or specify contexts where element inspection is appropriate versus script execution.

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

• safari_navigateC
  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 full burden for behavioral disclosure. It states what the tool does but lacks critical details: whether navigation blocks until page load, handles errors (e.g., invalid URLs), requires specific permissions, or has side effects (e.g., clearing logs). For a navigation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that states the core functionality without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse. Every word earns its place, achieving maximum clarity with minimal verbosity.

  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 complexity of browser navigation (which can involve loading states, errors, and session dependencies), the description is incomplete. With no annotations, no output schema, and minimal behavioral context, it fails to provide enough information for reliable use. The agent lacks guidance on what happens after navigation or how to handle failures.

  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 ('sessionId' and 'url') clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides—it mentions 'URL' but not 'sessionId', and offers no additional context about parameter usage, formats, or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Navigate to') and resource ('a URL in Safari'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'safari_start_session' or 'safari_execute_script', but the verb 'navigate' is specific enough to distinguish it as a browser navigation operation rather than session management or script execution.

  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 an active session via 'safari_start_session'), nor does it clarify when navigation is appropriate versus other browser interactions like taking screenshots or inspecting elements. The agent must infer usage from context alone.

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

• safari_start_sessionC
  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 mentions 'dev tools access' but doesn't cover critical aspects like whether this is a read-only or mutating operation, authentication requirements, potential side effects (e.g., opening a browser instance), rate limits, or error handling. For a tool that likely initiates a session, this is a significant gap in 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 a single, efficient sentence that front-loads the core action ('Start a new Safari automation session') and adds a key feature ('with dev tools access') without unnecessary details. Every word earns its place, making it highly concise 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?

  Given the complexity of starting an automation session, no annotations, no output schema, and moderate schema coverage, the description is incomplete. It lacks details on behavioral traits, parameter usage, expected outputs, or how it integrates with sibling tools, leaving significant gaps for an AI agent to understand and invoke it correctly.

  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 does not mention any parameters, while the input schema has 2 parameters with 50% coverage (only 'sessionId' is described). Since schema coverage is moderate, the baseline is 3, as the description adds no value beyond the schema—it doesn't explain what 'sessionId' is used for or the purpose of 'options' like enabling inspection or profiling.

  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 ('Start a new Safari automation session') and the resource ('Safari'), with the specific feature of 'dev tools access' distinguishing it from generic session tools. However, it doesn't explicitly differentiate from sibling tools like 'safari_list_sessions' or 'safari_close_session' in terms of purpose, keeping it from 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, such as whether it's for initial setup before other operations like 'safari_execute_script' or 'safari_navigate', or how it relates to sibling tools like 'safari_list_sessions'. It lacks explicit when/when-not instructions or named alternatives.

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

• safari_take_screenshotC
  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 action but doesn't explain what happens after the screenshot is taken (e.g., where it's saved, format, size, or if it's returned as data). This leaves critical behavioral traits like output handling and potential side effects undocumented.

  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, clear sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and efficiently communicates the core function, making it easy to understand at a glance.

  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 complexity of a screenshot tool (which involves visual capture and output handling), the description is incomplete. With no annotations and no output schema, it fails to explain what the tool returns (e.g., image data, file path, or error details). This gap makes it inadequate for an agent to fully understand the tool's 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?

  The input schema has 100% description coverage, with the sessionId parameter clearly documented. The description doesn't add any additional meaning beyond what the schema provides, such as explaining why a sessionId is needed or how it relates to the 'current page'. This meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('take a screenshot') and the target ('current page'), which is specific and unambiguous. However, it doesn't distinguish this tool from potential siblings like 'safari_get_page_info' or 'safari_inspect_element' that might also capture visual information, 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, such as whether it's for debugging, documentation, or visual testing. It also doesn't mention prerequisites like needing an active session, which is implied by the required sessionId parameter but not explicitly stated.

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

• safari_list_sessionsB
  3.1/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 full burden. 'List all active Safari sessions' implies a read-only operation, but it doesn't disclose behavioral traits like whether this requires specific permissions, what format the output takes (e.g., list of session IDs, detailed objects), if there are rate limits, or if it affects system state. The description is minimal and lacks necessary context for safe invocation.

  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, clear sentence with zero waste. It's appropriately sized for a simple tool and front-loaded with the core purpose. Every word earns its place, making it highly concise 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?

  Given the complexity (a read operation with no parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'active Safari sessions' means, what data is returned, or any prerequisites. For a tool that might return structured session data, more context is needed to understand the output format and usage implications.

  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 schema description coverage is 100% (empty schema). With no parameters to document, the description doesn't need to add parameter semantics. A baseline of 4 is appropriate since there's no parameter information to provide beyond what the schema already covers (which is nothing).

  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 active Safari sessions'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'safari_get_page_info' or 'safari_get_console_logs' which might also retrieve session-related information, so it doesn't achieve full sibling differentiation.

  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. With siblings like 'safari_start_session' and 'safari_close_session', it's unclear if this tool should be used for monitoring active sessions versus other purposes. No explicit when/when-not instructions or alternative references are included.

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

• safari_close_sessionB
  3.2/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 action ('Close') but does not describe what happens upon closure (e.g., whether resources are freed, if the session is terminated permanently, any side effects, or error conditions). For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, clear sentence with no wasted words, making it highly concise and front-loaded. It directly communicates the tool's purpose without unnecessary elaboration, earning its place 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 (a mutation operation to close a session), lack of annotations, and no output schema, the description is incomplete. It does not cover behavioral aspects like what closure entails, potential errors, or return values. For a tool that likely involves resource management, more context is needed to ensure safe and correct usage.

  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 has 100% description coverage, with the 'sessionId' parameter fully documented in the schema. The description does not add any meaning beyond what the schema provides (e.g., it doesn't explain where to get the sessionId or its format). With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

  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 ('Close') and resource ('Safari automation session'), making the purpose immediately understandable. It distinguishes this from siblings like 'safari_start_session' by indicating the opposite action, though it doesn't explicitly contrast with all alternatives. The specificity is good but lacks explicit sibling differentiation beyond the obvious.

  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 usage context by referencing 'session' closure, suggesting it should be used after a session is active (e.g., following 'safari_start_session'). However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to close vs. keep a session open) or any prerequisites. The implied context is minimal but reasonable.

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