Server Quality Checklist

Tool Scores

• get_current_weatherC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves current weather, implying a read-only operation, but doesn't cover important aspects like rate limits, error handling, data freshness, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

  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 in French that conveys the core purpose and default behavior without any wasted words. It's appropriately sized and front-loaded, 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., temperature, conditions), potential errors, or how it differs from sibling tools. For a tool with no structured output and zero annotation coverage, more contextual information 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?

  Schema description coverage is 100%, with clear documentation for both parameters (city and country). The description adds minimal value beyond the schema: it mentions the default city (Sydney) and that the city parameter is optional, but this is already covered in the schema. Since the schema does the heavy lifting, 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 clearly states the tool's purpose: 'Récupère la météo actuelle pour une ville' (Retrieves current weather for a city). It specifies the verb ('récupère') and resource ('météo actuelle'), and mentions the default city (Sydney). However, it doesn't explicitly differentiate from sibling tools like get_weather_by_coordinates or get_weather_forecast, which prevents a score of 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 provides minimal usage guidance: it mentions the default city (Sydney) but offers no explicit advice on when to use this tool versus alternatives like get_weather_by_coordinates or get_weather_forecast. There's no context on prerequisites, limitations, or comparisons to siblings, leaving the agent with little direction.

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

• get_weather_by_coordinatesC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves weather but doesn't disclose any behavioral traits such as rate limits, authentication needs, error handling, or what the output looks like (e.g., current conditions, forecast details). For a tool with no annotations, 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 in French that directly states the tool's function. It's front-loaded with the core purpose and has no wasted words. This is appropriately concise for a simple retrieval tool.

  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 (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on output format (e.g., what weather data is returned), behavioral aspects like error cases, and differentiation from siblings. Without annotations or output schema, the description should provide more context to be fully helpful.

  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 clear documentation for 'lat', 'lon', and 'days' including defaults and constraints. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain coordinate formats, units, or how 'days' affects the output. Given high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to.

  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: 'Récupère la météo selon les coordonnées géographiques' (Retrieves weather based on geographic coordinates). It specifies the verb ('récupère') and resource ('météo'), and while it doesn't explicitly distinguish from siblings like 'get_current_weather' or 'get_weather_forecast', the mention of coordinates provides some differentiation. However, it's not fully specific about scope (e.g., current vs. forecast) compared to siblings.

  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 'get_current_weather' or 'get_weather_forecast'. It doesn't mention any prerequisites, exclusions, or contextual factors (e.g., use this for coordinates-based queries, use others for city names). The lack of usage context leaves the agent to infer based on tool names alone.

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

• get_weather_forecastC
  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. It states the tool retrieves forecasts but lacks critical details: whether it's a read-only operation, any rate limits, authentication requirements, error handling, or response format. For a tool with no annotation coverage, this leaves significant behavioral gaps unaddressed.

  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—a single sentence in French that efficiently conveys the core functionality. It's front-loaded with the main purpose and includes key details (7-day forecast, Sydney default) without any fluff or redundant information. Every word earns its place.

  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 moderate complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the forecast data includes (e.g., temperature, precipitation), how results are structured, or any limitations beyond the 7-day range. Without annotations or output schema, the description should provide more context about behavior and returns.

  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 fully documents all three parameters (city, country, days) with descriptions, defaults, and constraints. The description adds marginal value by mentioning the 7-day forecast scope and Sydney default, but doesn't provide additional semantic context beyond what's already in the schema. Baseline 3 is appropriate when 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 tool's purpose: 'Récupère les prévisions météo sur 7 jours' (Retrieves 7-day weather forecasts). It specifies the verb ('récupère'), resource ('prévisions météo'), and scope ('sur 7 jours'). However, it doesn't explicitly differentiate from sibling tools like 'get_current_weather' or 'get_weather_by_coordinates' beyond implying a forecast vs. current weather distinction.

  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 minimal usage guidance. It mentions 'Sydney par défaut' (Sydney by default), which hints at optional city parameter usage, but offers no explicit when-to-use rules, no comparison to alternatives like 'get_current_weather' for current vs. forecast data, and no prerequisites or exclusions. 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.

• search_citiesC
  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. While it indicates this is a search operation that returns coordinates, it doesn't describe important behavioral aspects like whether this is a read-only operation, what format the coordinates are returned in, whether there are rate limits, how partial matches are handled, or what happens when no cities are found. The description provides basic functionality but lacks 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.

  Conciseness4/5

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

  The description is a single, efficient sentence in French that clearly states the tool's purpose. It's appropriately concise without being overly brief, though it could potentially be more front-loaded with additional context about when to use the tool. There's no wasted language or redundancy.

  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 search tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the coordinates are returned in (latitude/longitude pairs, geojson, etc.), whether results are paginated, how many results are returned, or what happens with ambiguous queries. The description provides basic functionality but leaves too many operational questions unanswered for effective agent use.

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

  Parameters3/5

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

  The description mentions searching by city name, which aligns with the single 'query' parameter in the schema. Since schema description coverage is 100% and the schema already documents the parameter as 'Nom de la ville à rechercher' (Name of the city to search for), the description adds minimal value beyond what's already in the structured data. The baseline score of 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 tool's purpose: searching for cities by name to obtain their coordinates. It specifies both the verb ('search') and resource ('cities'), and indicates the outcome ('obtain coordinates'). However, it doesn't explicitly differentiate from sibling tools like get_current_weather, which are weather-related rather than city search tools.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like get_current_weather or explain that this tool is for finding city coordinates rather than weather data. There's no information about prerequisites, limitations, or appropriate contexts for use.

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