Server Quality Checklist

Tool Scores

• select_weather_forecast_city_israelA
  4.3/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 and does disclose the key behavior: it clicks a suggestion and navigates to the forecast page. It also warns that the first suggestion may not be the city itself, which is a non-obvious behavioral caveat an agent needs to avoid incorrect selection.

  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 purpose sentence is front-loaded and the Args block is compact, giving only the information needed to pick the right index. There is no filler or repetition.

  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 one-parameter UI-interaction tool with an output schema, the description is close to complete. A minor gap is that prerequisites are only implied: an agent must infer that the autocomplete list already exists, presumably from a sibling tool, and that a matching suggestion should be available.

  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 0%, but the description fully compensates for the only parameter: index is defined as a zero-based suggestion position, its default is explained, and a decision rule is provided for preferring the matching city text. This goes beyond the schema's bare integer/default definition.

  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 concrete action and target ('Click a city from the autocomplete list') and the expected outcome ('load its forecast page'). This clearly distinguishes it from siblings such as enter_weather_forecast_city_israel, open_weather_forecast_israel, and extract_weather_forecast_israel.

  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 autocomplete-list phrasing implies the tool should be used after a city search has produced suggestions, but it does not explicitly mention alternatives or exclusions relative to sibling tools. The guidance is about choosing an index, not about when to select this tool rather than another.

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

• close_weather_browser_israelA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and adds meaningful behavioral context: 'Safe to call at any time' implies idempotency and that the tool won't error or cause side effects even if no browser is open. It also clarifies the tool's scope as closing only the browser opened by the sibling tools.

  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?

  A single sentence that front-loads the core action ('Close the browser') and appends the key safety note. Every word earns its place; there is no redundancy or filler.

  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?

  For a zero-parameter cleanup tool with an output schema present, the description fully covers what the tool does and when it is safe to call. No additional details about return values are necessary because the output schema exists.

  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 input schema has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter info, but none is needed since the tool requires no arguments.

  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 ('Close') and a clear resource ('the browser opened by these tools'), making the action unambiguous. It also distinguishes this from sibling forecast tools by identifying it as a cleanup operation on a browser instance rather than a forecast-related action.

  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 phrase 'Safe to call at any time' provides explicit state-independent guidance, telling the agent it can invoke this tool without prerequisites or timing concerns. It does not name alternatives, but none exist for closing the browser, so the guidance is sufficient.

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

• enter_weather_forecast_city_israelA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full behavioral disclosure. It reveals that the tool returns live site suggestions, numbers them from 0, and may surface non-city results in surprising order. It does not mention side effects or prerequisites, but the browser-automation context and sibling names imply 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 concise and front-loaded with the action, followed by return behavior and next-step guidance. The example about 'חיפה' earning place because it illustrates an important quirk. No redundant filler is present.

  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 one required parameter, an existing output schema, and the explicit pointer to the following sibling tool, the description is nearly complete. It could mention the prerequisite of an already-open forecast page, but that is implied by the sibling open_weather_forecast_israel.

  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 add meaning beyond the schema's bare 'City' title. It does so by specifying the city must be in Hebrew and providing concrete examples ('תל אביב', 'חיפה', 'באר שבע'). This is sufficient for a single obvious parameter.

  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 action ('Type an Israeli city name into the forecast search box') and clearly identifies the tool's output (numbered autocomplete suggestions). It also distinguishes this from the sibling select_weather_forecast_city_israel by instructing the agent to call that tool after reading the list.

  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 explains the workflow: enter a city name, read the returned suggestions, then call select_weather_forecast_city_israel. It also warns that suggestions may include neighborhoods and landmarks, guiding the agent to inspect the list before choosing.

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

• open_weather_forecast_israelA
  4.5/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 behavioral burden. It discloses the side effect of opening a browser, the resulting state ('leaves the browser sitting on the forecast page with the city search box ready'), and the return value (page title and URL). This is meaningful beyond a bare action statement.

  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 short paragraphs, front-loads the core action and ordering instruction, and provides the necessary behavioral outcome and return info. Every sentence earns its place with no redundancy.

  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?

  For a parameterless opener tool, the description covers what it does, when to call it, what state results, and what it returns. The output schema handles return formatting, so nothing essential is missing for correct selection and invocation.

  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 zero parameters, so there is nothing for the description to document. The baseline of 4 applies, and the description adds no conflicting or unnecessary parameter information.

  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 action — 'Open a browser and navigate to the Israeli weather forecast site' — with a clear verb and resource. The sibling tools cover closing, entering, selecting, and extracting, so this is unambiguously the initial navigation step.

  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 explicit 'Call this first' provides clear ordering guidance and sets expectations for the workflow. It does not name alternatives or exclusions, but among siblings this is clearly the entry point, so the context is sufficient.

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

• extract_weather_forecast_israelA
  4.8/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. It discloses the output format, default content (current conditions plus 3-day hourly forecast), clamping ranges, and the trade-off of reducing the window. It omits error cases (e.g., page not open) but covers essential behavioral traits.

  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?

  Well-structured and front-loaded: first sentence states purpose, second gives call sequence, third explains defaults, then detailed args. No wasted words; every sentence serves a distinct purpose.

  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 the output schema exists and annotations are absent, the description covers all essentials: dependency on prior step, default sufficiency, and parameter constraints. An agent can correctly call it with confidence.

  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 has zero descriptions (0% coverage), so the description must compensate. It explains each parameter's purpose, default behavior, clamping range, and when to leave unset, adding substantial meaning beyond the raw 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 clearly states a specific action: reading the forecast from the currently open page and returning it as clean markdown. It differentiates from siblings (open, select, close) by focusing on extraction after selection, so an agent can tell them apart without checking 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?

  Explicitly instructs to call after select_weather_forecast_city_israel, advises using no arguments, and explains when to adjust parameters (only for multi-day questions). It also warns against shrinking the window, providing clear when-to-use and when-not-to-use guidance.

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