Server Quality Checklist

Tool Scores

• get_system_stationsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true (safe operation) and openWorldHint=true (can query multiple systems). The description adds value by specifying that it returns 'all stations' with 'services and facilities information', which provides context about scope and return content. However, it doesn't disclose important behavioral details like rate limits, authentication requirements, pagination, or error conditions that would be helpful for an agent.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the core purpose. Every word contributes meaning without redundancy. While it could potentially be more structured with separate clauses for different aspects, it achieves good information density with minimal waste.

  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?

  For a read-only query tool with good schema coverage and annotations, the description provides adequate basic context about what the tool returns. However, without an output schema, the description doesn't specify the structure or format of the returned station data (beyond mentioning services and facilities). Given the complexity of station information and the existence of sibling tools with overlapping functionality, more guidance would be beneficial.

  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?

  With 100% schema description coverage, both parameters are well-documented in the schema itself. The description mentions 'specified solar systems' which aligns with the 'systems' parameter, and 'filter stations by' which hints at the 'serviceFilter' parameter. However, it doesn't add meaningful semantic context beyond what the schema already provides about these parameters' purposes and constraints.

  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 all stations') and resource ('in specified solar systems'), including what information is returned ('with their available services and facilities information'). It distinguishes from some siblings like 'get_station_services' (which focuses only on services) and 'solar_system_info' (which provides system-level data), but doesn't explicitly differentiate from 'find_stations_with_services' which has overlapping functionality.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'find_stations_with_services' (which appears to have similar filtering capabilities) or 'get_station_services' (which might provide more detailed service information). There's no context about use cases, prerequisites, or limitations beyond what's in the parameters.

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

• calculate_routeB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with flexible inputs. The description adds that it 'Supports system names or IDs' and calculates 'shortest route,' which provides useful context beyond annotations. However, it doesn't mention rate limits, authentication needs, or what happens with invalid inputs.

  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 with two sentences that efficiently convey core functionality and input support. Every word earns its place, and the information is front-loaded with the primary purpose stated first.

  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?

  For a route calculation tool with good annotations (readOnlyHint, openWorldHint) and 100% schema coverage, the description is adequate but minimal. It lacks output format details (no output schema provided), doesn't explain route characteristics beyond 'shortest,' and offers no error handling 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 parameters are well-documented in the schema. The description adds that it 'Supports system names or IDs,' which clarifies input formats for origin/destination, but doesn't provide additional meaning beyond what the schema already specifies for avoidSystems or flag.

  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: 'Calculate the shortest route between two EVE Online solar systems using ESI API.' It specifies the verb ('calculate'), resource ('route'), and domain ('EVE Online solar systems'), but doesn't explicitly differentiate from sibling tools like 'calculate_multiple_routes' or 'system_connection_map'.

  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 mentions 'Supports system names or IDs' but doesn't explain when to choose this over sibling tools like 'calculate_multiple_routes' or 'find_nearest_trade_hub', nor does it mention any prerequisites or exclusions.

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

• find_nearest_trade_hubB
  3.3/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially large data. The description adds context about 'detailed route information', which suggests richer output than just a hub name. However, it doesn't disclose behavioral traits like rate limits, authentication needs, or what 'detailed' entails (e.g., jump-by-jump breakdowns, distances). No contradiction with annotations exists.

  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 purpose ('Find the nearest trade hub') and adds key context ('provide detailed route information'). There is no wasted verbiage, repetition, or unnecessary elaboration, 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.

  Completeness3/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 output schema) and rich annotations (readOnlyHint, openWorldHint), the description is minimally adequate. It states the purpose but lacks output details (e.g., what 'detailed route information' includes) and usage context relative to siblings. For a routing tool without an output schema, more completeness on return values would be beneficial.

  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 parameter descriptions in the schema (e.g., origin as 'solar system name or ID', maxJumps range 1-20). The description adds no parameter semantics beyond what the schema provides, such as clarifying trade hub types or route details. With high schema coverage, 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: 'Find the nearest trade hub to a specified solar system and provide detailed route information.' This specifies the verb ('find'), resource ('trade hub'), and scope ('nearest to a solar system'). However, it doesn't explicitly differentiate from sibling tools like 'find_nearest_landmarks' or 'calculate_route', which reduces clarity in a crowded toolset.

  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 many sibling tools for routing, navigation, and location queries (e.g., 'calculate_route', 'find_nearest_landmarks', 'find_stations_with_services'), the agent receives no help in selecting this specific tool for trade hub routing over other options.

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

• region_name_to_idB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially unbounded data. The description adds that it uses the ESI API, which implies external API calls and potential rate limits, but doesn't explicitly mention these behavioral traits. No contradiction with annotations exists.

  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's front-loaded with the core functionality and includes the API context, making every part of the sentence valuable.

  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?

  For a simple conversion tool with good annotations (readOnlyHint, openWorldHint) and full schema coverage, the description is minimally adequate. However, it lacks output details (no output schema provided), doesn't mention error handling or API constraints, and doesn't guide usage relative to siblings, leaving gaps in 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%, with the parameter 'regionNames' fully documented in the schema (array of strings, max 500 items, English proper nouns only). The description doesn't add any parameter-specific details beyond what the schema provides, so it 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 tool's purpose: converting EVE Online region names to IDs using the ESI API. It specifies the verb ('convert'), resource ('region names'), and mechanism ('ESI API'). However, it doesn't explicitly differentiate from sibling tools like 'solar_system_name_to_id' or 'universal_name_to_id', which perform similar conversions for different entity types.

  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 'region_info' (which might provide more detailed region data) or 'universal_name_to_id' (which might handle multiple entity types). There's no context about prerequisites, limitations, or typical use cases beyond the basic conversion.

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

• stargate_infoB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, non-destructive query with potential for unknown data. The description adds value by specifying the APIs involved (ESI and SDE) and the types of information returned (connections and positions), which provides useful context beyond the annotations.

  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 purpose ('Get comprehensive stargate information') and includes essential details (data sources and content). Every word contributes meaning without redundancy, making it optimally concise.

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

  Completeness3/5

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

  Given the tool's moderate complexity (fetching data from multiple APIs), annotations cover safety and scope, but there's no output schema to describe return values. The description mentions 'connections and positions' as included information, which helps, but doesn't detail format or potential limitations, leaving some gaps for an agent to infer.

  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 the parameter 'stargateIds' fully documented in the schema (array of numeric IDs, max 50). The description doesn't add any parameter-specific details beyond what the schema provides, so it meets the baseline for high coverage without extra value.

  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 comprehensive stargate information') and the data sources ('from both ESI and SDE APIs'), which is specific and informative. However, it doesn't explicitly differentiate this tool from sibling tools like 'solar_system_info' or 'system_connection_map' that might also provide related spatial data, preventing 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. With sibling tools like 'solar_system_info' and 'system_connection_map' available, there's no indication of scenarios where this tool is preferred or excluded, leaving usage context unclear.

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

• get_station_agentsA
  3.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with potentially incomplete data. The description adds valuable behavioral context beyond annotations: it specifies what information is returned (agent types, levels, specializations) and mentions performance considerations ('may be slower' for research agents). This enhances the agent's understanding of what to expect from the tool's 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, well-structured sentence that efficiently communicates the core functionality. It's front-loaded with the main purpose and includes specific details about what information is retrieved. There's no wasted language or unnecessary elaboration - every word contributes to understanding the tool's function.

  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?

  For a read-only tool with good annotations and full schema coverage, the description provides adequate context about what information is returned. However, without an output schema, the description doesn't specify the format or structure of the returned agent data. It also doesn't mention limitations like the 20-station maximum or potential pagination/rate limiting considerations that would be helpful 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?

  With 100% schema description coverage, the input schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain the relationship between station names/IDs and agent retrieval, nor does it clarify the practical implications of including research agents. This meets the baseline expectation when schema coverage is complete.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get information about agents located at specific stations' with specific details about what information is retrieved ('types, levels, and specializations'). It distinguishes from siblings like 'get_station_services' or 'get_system_stations' by focusing specifically on agents rather than services or stations themselves. However, it doesn't explicitly contrast with all sibling tools, preventing a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'find_nearest_trade_hub' or 'get_station_services' that might provide related information. There's no indication of prerequisites, typical use cases, or when this tool would be preferred over other station or system information tools.

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

• calculate_multiple_routesA
  3.8/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=true and openWorldHint=true, covering safety and data scope. The description adds value by explaining the tool's utility ('finding the best destination or comparing routes'), which provides behavioral context beyond annotations. It doesn't contradict annotations (readOnlyHint aligns with 'calculate' as a query operation), and adds practical insight into how results might be used.

  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 concise sentences that are front-loaded with the core purpose and followed by a utility statement. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse for an AI agent.

  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 moderate complexity (4 parameters, 100% schema coverage, annotations present, no output schema), the description is reasonably complete. It clarifies the multi-destination scope and utility, which complements the structured data. However, it could better address sibling differentiation or output expectations to be fully comprehensive, but it's adequate for the 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%, with all parameters well-documented in the schema (e.g., 'destinations' max 20 items, 'flag' enum values). The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining 'avoidSystems' usage or 'flag' implications. Baseline 3 is appropriate as the schema carries the full burden of parameter documentation.

  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 calculates routes from one origin to multiple destinations, specifying the verb 'calculate' and resources 'routes' with scope 'multiple destinations'. It distinguishes from the sibling 'calculate_route' by emphasizing 'multiple' destinations, though it doesn't explicitly name the sibling. The purpose is specific but could be more differentiated.

  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 provides implied usage context with 'useful for finding the best destination or comparing routes', which suggests when to use this tool. However, it doesn't explicitly state when to use this versus the single-route sibling 'calculate_route' or other routing alternatives, nor does it mention any prerequisites or exclusions. The guidance is helpful but incomplete.

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

• find_stations_with_servicesA
  3.8/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with potentially large data scope. The description adds value by specifying the tool is 'useful for finding trading hubs, reprocessing facilities, or other specialized services,' which gives context about typical use cases. However, it doesn't disclose additional behavioral traits like rate limits, authentication needs, or what happens with no results, leaving room for improvement.

  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 highly concise and front-loaded: two sentences that directly state the purpose and usage context without any wasted words. Every sentence earns its place by providing essential information, making it easy for an AI agent to quickly understand the tool's role.

  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 (4 parameters with nested objects, no output schema), the description is reasonably complete. It covers the core purpose and usage context, and annotations provide safety and scope hints. However, without an output schema, the description could benefit from mentioning what the tool returns (e.g., a list of stations with services), but this is a minor gap given the clear annotations.

  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 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining service name formats or search area constraints. This meets the baseline of 3 since the schema does the heavy lifting, but no extra value is provided.

  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: 'Find stations that offer specific services within specified systems or regions.' It includes the verb 'find' and resource 'stations' with the key constraint of 'specific services' and location scope. However, it doesn't explicitly differentiate from sibling tools like 'get_station_services' or 'find_nearest_trade_hub,' which reduces 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 Guidelines4/5

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

  The description provides clear context for when to use this tool: 'Useful for finding trading hubs, reprocessing facilities, or other specialized services.' This gives practical examples of use cases. However, it doesn't explicitly state when not to use it or name alternatives among the sibling tools, such as 'find_nearest_trade_hub' for simpler trade hub searches.

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

• find_systems_in_rangeA
  4/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially large result sets. The description adds valuable context beyond this by specifying 'Builds a stargate connection graph for accurate results', which explains the underlying method and accuracy assurance. However, it doesn't detail performance characteristics like speed or limitations on result size, leaving some behavioral aspects uncovered.

  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 zero waste: the first states the core purpose and method, and the second adds technical context about graph building. It's front-loaded with the main action and efficiently structured, making every sentence earn its place without redundancy or unnecessary elaboration.

  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 (graph traversal with multiple parameters), annotations cover safety and scope, and schema fully documents inputs, the description is mostly complete. It explains the method and accuracy but lacks output details (no output schema provided) and doesn't mention potential constraints like data freshness or error handling. This minor gap prevents a perfect score.

  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 parameters. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as clarifying 'origin' as a starting point or 'maxJumps' as a search limit. Thus, it meets the baseline of 3 where the schema handles parameter documentation adequately.

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

  Purpose5/5

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

  The description clearly states the specific action ('Find all solar systems') with the resource ('within a specified jump range from an origin system') and method ('using efficient graph traversal'). It distinguishes from siblings by focusing on range-based discovery rather than route calculation or information lookup, as evidenced by comparing to tools like 'calculate_route' or 'solar_system_info'.

  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 for range-based discovery but doesn't explicitly state when to use this tool versus alternatives like 'calculate_multiple_routes' or 'find_nearest_trade_hub'. It mentions 'efficient graph traversal' which suggests performance benefits, but lacks clear exclusions or named alternatives, leaving usage context partially inferred rather than directly guided.

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

• get_station_servicesA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating it's a safe read operation with open-world data. The description adds useful behavioral context beyond annotations by noting that including agents 'may be slower' and specifying a max of 50 stations, which helps the agent understand performance implications and limits. However, it lacks details on error handling or response format.

  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 in the first sentence and efficiently adds supporting details in the second. Every sentence earns its place by clarifying scope and input flexibility without redundancy, making it easy to scan and understand quickly.

  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 moderate complexity (3 parameters, no output schema), the description is reasonably complete. It covers the tool's purpose, input types, and key behavioral notes like performance trade-offs. However, without an output schema, it could benefit from hinting at the return structure (e.g., list of services) to fully guide the agent, though annotations provide safety 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 the schema fully documents all parameters. The description adds minimal semantic value beyond the schema by mentioning support for 'station IDs and names', which aligns with the 'stations' parameter but doesn't provide additional syntax or usage details. With high schema coverage, 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.

  Purpose5/5

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

  The description clearly states the specific action ('Get comprehensive station information') and resource ('station'), listing key data points like services, docking capabilities, and reprocessing facilities. It explicitly distinguishes from siblings by focusing on service information rather than routes, agents, or system data, making it easy to identify its unique function.

  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 clear context for when to use this tool ('to get service information for stations'), and it implicitly suggests alternatives by mentioning support for both IDs and names, which might differ from sibling tools like 'station_name_to_id'. However, it does not explicitly state when not to use it or name specific alternatives, such as 'get_station_agents' for agent-focused queries.

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

• region_infoA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe, non-destructive operations with potentially large data. The description adds value by specifying data sources (ESI and SDE APIs) and content types (constellations, systems, boundaries), but doesn't detail rate limits, authentication needs, or pagination behavior beyond annotations.

  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, dense sentence that efficiently conveys purpose, sources, and content without redundancy. It's front-loaded with the core action and avoids unnecessary elaboration, making every word count.

  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 (multi-API data aggregation), lack of output schema, and rich annotations, the description is mostly complete. It covers what data is retrieved and from where, but could benefit from mentioning output format or handling of large datasets to fully compensate for the missing output 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%, with the schema fully documenting the 'regionIds' parameter (array of numeric IDs, max 50, requires conversion via 'region_name_to_id'). The description doesn't add parameter-specific semantics beyond what the schema provides, so it meets the baseline for high 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 the action ('Get comprehensive region information') and specifies the resources ('from both ESI and SDE APIs, including constellations, systems, and boundaries'). It distinguishes from siblings like 'region_name_to_id' (conversion tool) and 'region_systems_list' (limited to systems only) by emphasizing comprehensive multi-source data.

  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 implies usage for comprehensive region data needs, and the input schema provides guidance on converting names to IDs via 'region_name_to_id'. However, it doesn't explicitly state when to choose this over alternatives like 'region_systems_list' or 'solar_system_info' for specific data subsets.

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

• region_systems_listA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially incomplete data. The description adds value by specifying what data is returned ('security status and constellation information'), but doesn't disclose behavioral traits like rate limits, pagination, or error conditions beyond what annotations provide.

  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?

  Single sentence efficiently conveys the core purpose with zero wasted words. Front-loaded with the main action ('Get a comprehensive list'), followed by scope and data details. Every element earns its place.

  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 read-only tool with good annotations and full schema coverage, the description provides adequate context about what data is returned. However, without an output schema, it could benefit from more detail about return format (e.g., structure of system objects, pagination). Still, it's mostly complete for its complexity level.

  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 the parameter fully documented in the schema (regionIds array with numeric IDs, max 10 items, name conversion requirement). The description doesn't add any parameter semantics beyond what's already in the schema, so baseline 3 is appropriate.

  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 verb ('Get') and resource ('comprehensive list of all solar systems in specified regions') with specific attributes ('security status and constellation information'). It distinguishes from siblings like 'solar_system_info' (single system details) and 'region_info' (region-level data) by focusing on bulk system listing within regions.

  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 implies usage context ('in specified regions') and the input schema provides explicit guidance to use 'region_name_to_id' tool first for name conversion. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'find_systems_in_range' or 'solar_system_info', though the scope difference is clear from the purpose.

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

• solar_system_name_to_idA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true (safe read operation) and openWorldHint=true (can query arbitrary systems). The description adds that it uses the ESI API, which is useful context about the data source. However, it doesn't disclose rate limits, authentication needs, or error behavior beyond what annotations provide. No contradiction with annotations exists.

  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 purpose ('Convert EVE Online solar system names to their corresponding IDs') and adds necessary context ('using ESI API'). Every word earns its place with zero redundancy or fluff.

  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 low complexity (single parameter, read-only operation), rich annotations (readOnlyHint, openWorldHint), and 100% schema coverage, the description is reasonably complete. However, the lack of an output schema means the description doesn't explain return values (e.g., format of ID mapping), leaving a minor gap. It adequately covers the core functionality but could mention output expectations.

  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 the schema fully documenting the 'systemNames' parameter (array of strings, max 500 items, English proper nouns). The description doesn't add any parameter details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.

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

  Purpose5/5

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

  The description clearly states the specific action ('Convert EVE Online solar system names to their corresponding IDs') and the resource involved ('using ESI API'). It distinguishes from siblings like 'region_name_to_id', 'station_name_to_id', and 'universal_name_to_id' by specifying it's for solar systems only, not other entity types.

  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 implies usage context (when you have solar system names and need IDs), but doesn't explicitly state when to use this vs. alternatives like 'solar_system_info' (which might provide more details) or 'universal_name_to_id' (which handles multiple entity types). It provides clear scope (solar systems only) but no explicit exclusions or named alternatives.

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

• station_name_to_idA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with external data. The description adds value by specifying the ESI API as the data source, which provides useful context beyond annotations. However, it doesn't mention rate limits, authentication needs, or error behaviors.

  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 purpose without unnecessary words. Every element ('Convert', 'EVE Online station names', 'IDs', 'ESI API') earns its place by contributing essential information.

  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 simple lookup tool with good annotations (readOnlyHint, openWorldHint) and full schema coverage, the description is reasonably complete. It specifies the API source and conversion purpose. However, without an output schema, it could benefit from mentioning the return format (e.g., mapping of names to IDs).

  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 the parameter 'stationNames' fully documented in the schema (array of strings, max 500 items, English names required). The description doesn't add any parameter-specific details beyond what the schema provides, so it 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.

  Purpose5/5

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

  The description clearly states the specific action ('Convert'), resource ('EVE Online station names'), and mechanism ('using ESI API'), distinguishing it from sibling tools like 'solar_system_name_to_id' or 'universal_name_to_id' which handle different entity types. It precisely defines the tool's function without being tautological.

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

  Usage Guidelines4/5

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

  The description implies usage context (converting names to IDs via ESI) but doesn't explicitly state when to use this tool versus alternatives like 'universal_name_to_id' or 'get_system_stations'. It provides clear operational context but lacks explicit comparison with sibling tools.

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

• universal_name_to_idA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, read-only operation with potentially open-ended data. The description adds value by specifying the API used (ESI) and the scope of entity types, but does not disclose additional behavioral traits like rate limits, error handling, or response format. No contradiction with annotations exists.

  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 purpose without unnecessary details. Every word contributes to understanding the tool's function, making it appropriately sized and well-structured.

  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 low complexity (single parameter, read-only operation) and rich annotations (readOnlyHint, openWorldHint), the description is mostly complete. However, the lack of an output schema means the description could benefit from mentioning the return format (e.g., IDs as integers) to fully inform the agent, though it's not critical given the tool's simplicity.

  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 the schema fully documenting the 'names' parameter (array of strings, max 500 items, English proper nouns). The description adds no additional parameter semantics beyond what the schema provides, such as examples or edge cases, so it meets the baseline for high 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 the specific action ('Convert') and resource ('EVE Online entity names to IDs'), explicitly mentioning the types of entities covered (systems, stations, regions, etc.) and the API used (ESI). It distinguishes itself from sibling tools like 'region_name_to_id' and 'solar_system_name_to_id' by being universal across entity types.

  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 implies usage context by specifying it converts names for various EVE Online entities, but does not explicitly state when to use this tool versus alternatives like 'region_name_to_id' or 'solar_system_name_to_id'. It provides some guidance through the input schema's description (e.g., 'Use English proper nouns only'), but lacks explicit when/when-not directives or named alternatives.

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

• constellation_infoA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially incomplete data. The description adds valuable context about data sources (ESI and SDE APIs) and content scope (systems and boundaries), which goes beyond what annotations provide. It doesn't mention rate limits, authentication needs, or pagination behavior, but with annotations covering the safety profile, this is acceptable.

  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, well-structured sentence that efficiently conveys the tool's purpose, data sources, and key content. Every element earns its place with no redundant information, making it front-loaded and easy to parse.

  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 moderate complexity (1 parameter, no output schema), the description provides sufficient context about what the tool does and its data sources. With annotations covering read-only and open-world hints, and the schema fully describing the parameter, the description is adequately complete. A minor gap is the lack of explicit output format details, but this is mitigated by the tool's straightforward purpose.

  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 the parameter description already detailing the array of constellation IDs, numeric-only requirement, max 50 items, and the need to use universal_name_to_id for name conversion. The 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.

  Purpose5/5

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

  The description clearly states the action ('Get comprehensive constellation information') and specifies the data sources ('from both ESI and SDE APIs') and content scope ('including systems and boundaries'). It distinguishes itself from sibling tools like region_info, solar_system_info, and universal_name_to_id by focusing specifically on constellations.

  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 implies usage context by mentioning the need to convert names to IDs first using the universal_name_to_id tool, which is reinforced in the parameter description. However, it doesn't explicitly state when to use this tool versus alternatives like region_info or solar_system_info, nor does it provide exclusion criteria.

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

• find_nearest_landmarksA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate read-only and open-world hints, which the description does not contradict. The description adds behavioral context beyond annotations by specifying that results are sorted by distance and include detailed information like descriptions and positions, which is useful for understanding output 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 front-loaded with the core purpose in the first sentence, followed by return details. It uses two efficient sentences with no wasted words, making it easy to parse quickly.

  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 moderate complexity, annotations cover safety (read-only, open-world), and schema fully describes inputs, the description is mostly complete. However, no output schema exists, and the description could provide more detail on return format (e.g., structure of 'detailed information'), leaving a minor gap.

  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 parameters. The description does not add meaning beyond the schema, as it does not explain parameter interactions or usage nuances. Baseline score of 3 is appropriate given 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 the specific action ('Find'), resource ('nearest EVE Online landmarks'), and scope ('to a specified solar system'), with explicit mention of sorting and return details. It distinguishes from siblings like 'find_nearest_trade_hub' by focusing on general landmarks rather than trade hubs.

  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 clear context for when to use this tool (finding landmarks near a solar system), but does not explicitly state when not to use it or name alternatives. Siblings like 'find_nearest_trade_hub' or 'solar_system_info' might be alternatives, but this is not addressed.

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

• get_system_combat_statsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially incomplete data. The description adds valuable context beyond this: it specifies the data sources (ESI and EVE-KILL), the time windows (1-hour and 12-hour), that data is 'unprocessed without analysis', and the requirement for numeric IDs. No contradiction with annotations exists.

  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 efficiently structured in two sentences: the first states the purpose and scope, the second provides critical usage guidance. Every element serves a clear purpose with no redundant information, making it easy to parse quickly.

  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 moderate complexity (single parameter, read-only operation), the description is quite complete. It covers purpose, data sources, output characteristics, and parameter requirements. The main gap is the lack of output schema, leaving return format unspecified, but the description compensates somewhat by mentioning what data is included.

  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 fully documents the 'system_id' parameter. The description repeats the requirement for numeric IDs and references the conversion tool, but doesn't add significant semantic meaning beyond what the schema provides. 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.

  Purpose5/5

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

  The description clearly states the specific action ('Get raw combat statistics'), the resource ('for a solar system by system ID'), and the scope ('including ESI pod/ship kills (1-hour and 12-hour) and recent killmails from EVE-KILL'). It distinguishes itself from siblings like 'solar_system_info' by focusing exclusively on combat statistics rather than general system information.

  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 clear context for when to use this tool: when raw combat statistics are needed, and it explicitly mentions using 'solar_system_name_to_id' for name conversion. However, it doesn't specify when NOT to use it or explicitly compare it to alternative tools for similar purposes.

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

• solar_system_infoA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate read-only and open-world hints, but the description adds valuable context by specifying the data sources ('ESI and SDE APIs') and the types of information included ('security status, connections, and celestial objects'), which helps the agent understand the tool's behavior beyond the annotations. No contradictions with annotations.

  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, well-structured sentence that efficiently conveys the tool's purpose, sources, and key data types without unnecessary words. It is front-loaded with the main action and includes all essential information.

  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 (fetching comprehensive data from multiple APIs) and the absence of an output schema, the description adequately covers what the tool does and the data included. However, it could benefit from mentioning response format or limitations, though annotations provide some safety 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 the schema fully documents the 'systemIds' parameter. The description does not add any parameter-specific semantics beyond what the schema provides, such as format details or examples, but it implies the tool processes multiple systems, aligning with 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 clearly states the specific action ('Get comprehensive solar system information') and resources ('from both ESI and SDE APIs'), distinguishing it from siblings like 'get_system_combat_stats' or 'solar_system_name_to_id' which focus on specific aspects or conversions. It explicitly mentions the scope includes 'security status, connections, and celestial objects'.

  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 clear context for when to use this tool (for comprehensive solar system data), and the input schema includes guidance to use 'solar_system_name_to_id' for name conversions. However, it does not explicitly state when not to use it or compare it to alternatives like 'get_system_combat_stats' for combat-specific data.

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

• system_connection_mapA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially incomplete data. The description adds value by specifying the data source ('stargate data') and the output type ('map of system connections'), which aren't covered by annotations. It doesn't contradict annotations, and provides useful context beyond them.

  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 purpose ('Get a map of system connections') and adds necessary context ('by analyzing stargate data for given solar systems'). Every word earns its place with no redundancy or waste.

  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 moderate complexity (one parameter, no output schema), the description is reasonably complete. It explains what the tool does and the data source, but doesn't detail the output format or map structure. With annotations covering safety and data completeness, and schema fully documenting the parameter, the description provides adequate context, though could benefit from output details.

  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 the parameter 'systemIds' fully documented in the schema (including format, constraints, and conversion guidance). The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for 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 the specific action ('Get a map of system connections'), resource ('stargate data'), and scope ('for given solar systems'). It distinguishes from siblings like calculate_route or find_systems_in_range by focusing on connection mapping rather than routing or proximity analysis.

  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 implies usage context (analyzing stargate data for solar systems) and the input schema provides guidance on converting names to IDs using a sibling tool (solar_system_name_to_id). However, it doesn't explicitly state when to use this tool versus alternatives like find_systems_in_range or calculate_route, nor does it mention exclusions.

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