Server Quality Checklist

Tool Scores

• sia_delete_locationC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no behavioral traits beyond this (e.g., whether deletion is irreversible or cascading). It fails to provide additional context beyond what annotations already convey.

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

  Conciseness3/5

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

  The description is short but includes an 'Args' section that partially duplicates the function description. It could be more concise by removing redundancy.

  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 tool with one parameter and rich annotations, the description is adequate but lacks details on return value or error behavior. No output schema is present, so the agent must infer success/failure from other cues.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must add meaning. However, it only restates the parameter 'id' with type and format, adding little beyond the schema. It does not clarify the UUID format or provide any constraints not already in 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 verb 'Delete' and the resource 'location by ID from the SIA LocationService'. Among siblings, there are other delete tools (e.g., sia_delete_area, sia_delete_crop_zone), so it is properly distinguished.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description simply restates the action without providing usage context.

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

• sia_create_perennialA
  3.6/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, etc. The description adds that the tool returns a Created Perennial object, confirming it is a mutation and providing return structure. However, it does not disclose other behavioral traits such as idempotency, side effects on related data, or required permissions. With annotations providing basic safety info, the description offers marginal added value.

  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 structured with an 'Args:' section listing parameters with one-line meanings. It avoids fluff but the parameter list could be integrated more naturally. Still, every sentence serves a purpose.

  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 7 parameters and no output schema, the description covers parameter meanings and states the return type (Created Perennial object). It does not explain error conditions, validation rules, or behavior on duplicate entries. The description is adequate for basic invocation but lacks depth for robust decision-making.

  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 description coverage is low (14%), but the description adds a brief meaning for each parameter (e.g., 'UUID of the parent field' for field_ID). This compensates for the schema's lack of descriptions, enabling an agent to understand the purpose of each parameter beyond name and type.

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

  Purpose5/5

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

  The description clearly states the tool creates a perennial plant record in the SIA PerennialsService. The verb 'create' and resource 'perennial plant record' are specific, and the tool name aligns with sibling tools like sia_create_field, distinguishing it as a creation tool for perennials.

  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 (e.g., when to create a field vs a perennial). It does not mention prerequisites, preconditions, or conditions that would help an agent decide to invoke this tool over sibling creation tools.

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

• sia_create_fieldA
  3.7/5.0
  Behavior3/5

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

  Annotations are all false, providing no behavioral signals. The description discloses that the tool creates a field and returns the created object with ID. It adds context about relationships (farm, area) but does not cover side effects, permissions, or error conditions. The behavioral disclosure is adequate but not rich.

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

  Conciseness5/5

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

  The description is concise: a short paragraph followed by a bullet-like Args list and a return statement. Every sentence adds value, front-loading the purpose. There is no redundant or verbose language. It effectively communicates the necessary information without 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?

  With 4 parameters and no output schema, the description provides a return statement indicating the created object includes an ID. It explains prerequisites for area creation and relationships. However, it does not cover validation or error scenarios (e.g., missing farm). Given the parameter richness and clear schema, it is largely complete but could expand on constraints.

  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?

  Input schema has 100% coverage for parameter descriptions, setting a baseline of 3. The description adds meaningful value by explaining that area_ID should be created with sia_create_area first, and by describing the relationships between field, farm, and area. This goes beyond the schema descriptions, earning a 4.

  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 starts with 'Create a new field in the SIA FarmAndFieldService', which clearly states the verb and resource. It adds context that a field belongs to a farm and is associated with an area, but does not explicitly differentiate from sibling tools like sia_create_area or sia_create_crop_zone. The purpose is clear but lacks sibling distinction.

  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 by listing parameters and highlighting that area_ID must be created with sia_create_area first. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or scenarios where this tool is not appropriate. The guidance is limited to a prerequisite hint.

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

• sia_create_locationA
  3.7/5.0
  Behavior2/5

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

  Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), so 'Create' adds little beyond that. The description does not disclose side effects, permission requirements, or uniqueness constraints, failing to provide value 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 concise, with a clear purpose sentence followed by a bulleted list of arguments. Every word is necessary, and no redundant information is present.

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

  Completeness3/5

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

  The description covers parameters well but lacks details on the return object beyond 'Created Location object with ID'. No output schema exists, so more information about the response structure or potential errors would improve completeness. The four parameters are adequately described.

  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?

  Despite low schema coverage (25%), the description explains each parameter's meaning and provides an example for geolocation_geojson, which the schema also describes. This adds significant clarity for all four parameters, compensating for the schema gap.

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

  Purpose5/5

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

  The description clearly states the verb 'Create' and the resource 'location' with an example ('assembly point'). It distinguishes this tool from sibling tools like sia_create_area and sia_create_crop_zone by naming the specific entity and service.

  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 when to use (to create a location) but provides no explicit guidance on when not to use or alternatives. No prerequisites or exclusions are mentioned, relying on the agent to infer from context.

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

• sia_create_crop_zone_kpiA
  3.8/5.0
  Behavior3/5

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

  The description discloses that this tool creates a KPI object and returns it, which is consistent with the annotations (readOnlyHint=false, destructiveHint=false). However, it does not add behavioral context beyond what annotations provide, such as side effects, authentication requirements, or error conditions.

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

  Conciseness5/5

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

  The description is concise: a one-line summary followed by a clear Args list. Every sentence adds value, with no redundant information. It is front-loaded with the key purpose.

  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 create tool with 4 parameters and 100% schema coverage, the description adequately covers the operation. It mentions the return type ('Created KPI object') and examples. However, it could be more complete by noting that the crop zone must exist, but overall it is sufficient.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The description's Args section mirrors the schema and adds minimal value, such as the example 'total production estimate' in the main description, but does not enhance parameter understanding beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action ('Add a KPI value') and the resource ('to a crop zone'), with examples like 'total production estimate'. It effectively differentiates from sibling tools like sia_create_crop_zone_characteristic, which adds a different type of data.

  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 adding KPI values to crop zones, but does not explicitly state when to use this tool versus alternatives (e.g., sia_get_crop_zone_kpis for reading, or other creation tools). No exclusions or prerequisites are mentioned.

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

• sia_get_areasA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare read-only, open-world, idempotent, non-destructive hints. The description adds value by detailing the return fields and parameter behavior (e.g., filter syntax, default top), providing context 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.

  Conciseness4/5

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

  Description is front-loaded with purpose, followed by entity explanation, parameter list, and return fields. It is efficient with no redundant sentences, though could be slightly tighter.

  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 no output schema, the description includes all key return fields. It covers parameters, behavior, and context. Siblings are distinct, and the tool's role is clear. Adequate for agent 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?

  Schema coverage is 100%, and the description enriches both parameters: gives an OData filter example, states default top=100, and mentions max results in schema but not in description. This adds practical usage context beyond raw schema.

  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 it lists agricultural areas from SIA AreaService, specifies what areas represent, and lists return fields. However, it does not explicitly differentiate from sibling get tools (e.g., sia_get_fields), though the entity type is distinct.

  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 listing areas with optional filtering and pagination, but provides no explicit guidance on when to use this tool versus alternatives like sia_get_crop_zones or sia_get_fields.

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

• sia_get_crop_zone_characteristicsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns an array of objects and gives example filter syntax, but does not elaborate on pagination behavior, sorting, or rate limits. Some value added 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 concise with a clear introductory sentence and a bulleted Args/Returns structure. Every sentence serves a purpose with no redundancy.

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

  Completeness4/5

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

  With no output schema, the description states the return type but does not detail the fields of CropZoneCharacteristicValue objects. However, the tool has simple parameters and annotations cover safety, so it is mostly complete for a read-only listing tool.

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

  Parameters3/5

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

  Schema coverage is 50%, and the description adds a concrete filter example and clarifies the default for top. This goes beyond the schema's minimal description for filter, but the schema already provides type, min, max, and default for top.

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

  Purpose5/5

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

  The description clearly states the tool lists characteristic values attached to crop zones, with examples like tree counts and custom attributes. This verb-resource combination distinguishes it from sibling tools like sia_get_crop_zones (which returns zones) and sia_get_field_characteristics.

  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 an example filter but does not explicitly state when to use this tool versus alternatives like sia_get_characteristic_configurations or how to decide between filtering and pagination. Usage context is implied but not clearly bounded.

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

• sia_get_crop_zonesA
  3.8/5.0
  Behavior3/5

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

  Annotations already confirm it's read-only, idempotent, and non-destructive. The description adds behavioral context by specifying default top=100, max results=500, and the OData filter format, but does not delve into error handling or pagination details.

  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 one-sentence definition of a crop zone, parameter details in two bullet-style lines, and a return type line. No superfluous content; every sentence serves a purpose.

  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 low parameter count, rich annotations, and the description listing return fields (ID, name, isFallow, etc.), the tool is adequately documented for correct invocation. Missing details like field data types or error scenarios are minor gaps.

  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 50% (filter has a description, top does not). The description compensates by explaining 'top' as max results with a default, and provides an example for 'filter' (e.g., "field_ID eq '<uuid>'"). This adds meaningful semantic context beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action ('List crop zones from the SIA CropZoneService') and defines a crop zone, making it distinct from sibling tools like create or delete operations.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as sia_create_crop_zone or sia_get_crop_zone_characteristics. The description only explains what the tool does, not its context of use.

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

• sia_get_kpi_definitionsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description adds value by specifying the return format (array of objects with ID, name, description, unit). However, it does not disclose rate limits, authentication requirements, or whether the list is paginated.

  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 succinct, consisting of three short sentences that immediately convey the tool's purpose, provide an example, and state the return type. No redundant information.

  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 read tool with one optional parameter and no output schema, the description covers the main purpose and output structure. However, it omits details about the 'top' parameter (limiting results) and does not explain potential variations in the returned unit field.

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

  Parameters2/5

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

  The description does not mention the 'top' parameter at all, even though the input schema has no descriptions (0% coverage). With only one optional parameter, the description should explain its purpose (e.g., limiting results) but fails to do so.

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

  Purpose5/5

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

  The description clearly states the tool lists KPI definitions and explains what KPI definitions are with examples. It also distinguishes itself from sibling tools like sia_get_crop_zone_kpis by noting that the IDs are used for creating crop zone KPIs.

  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 usage guidance by stating that kpiDefinition_ID values are used when creating crop zone KPIs, implying this tool is for retrieving definitions. However, it does not explicitly contrast with alternatives like sia_get_crop_zone_kpis or mention when not to use it.

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

• sia_create_crop_zone_characteristicA
  3.9/5.0
  Behavior3/5

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

  The description states it creates a resource and returns it with an ID. However, it does not disclose any behavioral traits beyond that, such as side effects, required permissions, or constraints. Annotations are all false and provide no additional context.

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

  Conciseness5/5

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

  The description is concise: a one-line summary followed by a structured Args list and Returns line. No redundant information, every sentence is necessary.

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

  Completeness3/5

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

  The tool is simple and the description covers parameters and return value. However, the input schema is empty, creating a contradiction that may confuse agents. The description is fairly complete in isolation but incomplete when reconciled with the schema.

  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 description provides clear parameter names, types, and optionality despite the input schema being empty. This adds significant meaning beyond the schema, though no constraints or defaults are specified. The baseline for empty schema is higher, and the description compensates well.

  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 explicitly states it attaches a characteristic value to a crop zone, with concrete examples such as number of trees. This clearly distinguishes it from sibling tools like sia_create_crop_zone (creates a crop zone) and sia_create_crop_zone_kpi (creates a KPI).

  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 attaching characteristics but provides no explicit guidance on when to use this tool versus alternatives like sia_get_crop_zone_characteristics (reading) or other create tools. The usage context is inferred rather than stated.

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

• sia_get_crop_zone_kpisA
  4/5.0
  Behavior4/5

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

  Annotations already indicate a safe read-only operation. The description adds that it returns 'estimated production values', providing useful behavioral context beyond the annotations. No contradictions.

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

  Conciseness4/5

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

  The description is well-structured with an Args and Returns section, but it is slightly redundant given the schema. It remains concise and front-loaded with the main 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?

  With no output schema, the description adequately specifies the return structure (array of KPI objects). It covers the necessary details for a single-parameter read operation.

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

  Parameters3/5

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

  Schema coverage is 100% with a clear description of cropZone_ID. The description repeats this info without adding new meaning, meeting the baseline for full 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 verb 'Get' and the resource 'KPI values for a specific crop zone'. It distinguishes from sibling tools like sia_get_crop_zone_characteristics and sia_get_crop_zones by specifying that it retrieves KPI data.

  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?

  No explicit guidance on when to use this tool versus alternatives like sia_get_crop_zone_characteristics. The description implies usage for retrieving KPIs but lacks exclusions or context for differentiation.

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

• sia_create_crop_zoneA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate it's not read-only and not destructive. The description adds that it returns a 'Created CropZone object with ID', which is useful. 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.

  Conciseness4/5

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

  The description is well-structured with an overview, bulleted arguments, and return statement. It is clear and not overly verbose, though it could be slightly more concise without losing meaning.

  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 (12 parameters, 6 required, no output schema), the description covers the essential purpose and parameters, and mentions the return. It lacks details on error conditions or dependencies, but is sufficient for basic usage.

  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 description coverage is 83%, but the description adds value by grouping parameters by purpose and explaining the linking concept (e.g., 'UUID of the parent field'). It clarifies the role of each field beyond the schema's short descriptions.

  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 'Create' and the resource 'new crop zone', and explains that it links multiple entities (field, area, crop, variety, season), which distinguishes it from sibling tools like sia_create_field or sia_create_area.

  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 creating crop zones but does not explicitly state when to use this tool versus alternatives like sia_create_crop_zone_characteristic or sia_create_crop_zone_kpi. No when-not-to guidance is provided.

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

• sia_get_characteristic_configurationsA
  4.1/5.0
  Behavior4/5

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

  The description is consistent with annotations (readOnlyHint, idempotentHint, etc.). It adds value beyond annotations by explaining the purpose and usage of the configurations, though no additional behavioral traits are disclosed.

  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 three sentences: purpose, definition, and usage guidance. It is efficiently structured with no redundant 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 list tool, the description explains the concept, return type, and how to use the results. It omits the 'top' parameter but the schema covers it. Without output schema, describing return shape adds completeness.

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

  Parameters2/5

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

  The description does not mention the 'top' parameter at all. With schema coverage at 0%, the description should compensate but fails to add meaning; the schema provides constraints but no semantic context.

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

  Purpose5/5

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

  The description clearly states the tool lists characteristic configurations from SIA CharacteristicService, defining them as custom attributes for fields and crop zones. It uses a specific verb 'List' and distinguishes from sibling tools by focusing on configuration 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 explicitly instructs to use configuration_ID values when creating field or crop zone characteristic values, providing actionable context. However, it does not include when to avoid this tool or compare with alternatives.

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

• sia_create_field_characteristicA
  4.2/5.0
  Behavior3/5

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

  Annotations already mark the tool as not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it creates a record and returns the created object, but no additional behavioral traits like authorization needs or side effects are disclosed.

  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 two short paragraphs with a clear docstring-style parameter list. Every sentence adds value; no wasted words. Slightly structured but effective.

  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 no output schema, the description states what is returned ('Created FieldCharacteristicValue with ID'), which is sufficient. The parameter list is complete. However, it could briefly mention constraints (e.g., characteristic configuration must exist) to be fully self-contained.

  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?

  The input schema is empty (0 parameters), so the description provides all parameter documentation: names, types, descriptions, and optionality. This fully compensates for the missing schema, giving the agent complete information to invoke the tool correctly.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Attach a characteristic value to a field' with specific example ('set an external plot ID or custom attribute'). It distinguishes from sibling tool 'sia_create_crop_zone_characteristic' by specifying 'field' in both name and description.

  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 explains the tool's function and lists all parameters with types and descriptions. It does not explicitly contrast with siblings, but the context (field vs crop zone) is clear. A brief when-to-use note would elevate it to 5.

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

• sia_delete_areaA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds value by explicitly labeling the operation as destructive, warning about references, and stating it returns a confirmation message. This goes beyond annotations, though it could mention error 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 concise with a warning, parameter list, and return note. No superfluous content; every sentence serves a purpose. Front-loaded warning is effective.

  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 delete tool with one parameter and no output schema, the description covers the essential behavior, warning, and return type. It could mention idempotency or error cases, but given the annotations and simplicity, it is adequate.

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

  Parameters3/5

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

  The schema has 100% coverage for the required 'id' parameter with a description. The description repeats the parameter info but does not add new meaning beyond the schema. 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 title and description clearly state 'Delete an area by its ID', which is a specific verb+resource. The tool is distinct from sibling delete tools like sia_delete_crop_zone and sia_delete_location, so no confusion.

  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 includes a warning about ensuring the area is not referenced by active fields or crop zones before deleting, providing crucial usage context. It does not explicitly state when not to use this tool or mention alternatives, but the warning implies caution.

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

• sia_get_farmsA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate a read-only, idempotent, non-destructive operation, which matches the description. The description adds useful context such as default top value (100) and maximum (500), going beyond annotations without contradiction.

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

  Conciseness5/5

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

  The description is concise with a clear opening sentence, bullet-pointed arguments, and a return statement. Every sentence adds necessary information with no redundancy.

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

  Completeness4/5

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

  For a simple list tool with no output schema and good annotations, the description covers purpose, parameters, and return structure. It could detail the Farm object fields more, but overall it's adequate.

  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 description coverage is 50% (filter described, top not). The description adds value by providing an example for filter and clarifying top's default and max, supplementing the schema constraints.

  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 'List' and resource 'farms', and distinguishes from sibling get tools by specifying the service 'FarmAndFieldService'. It also lists the return fields (ID, name, description, metadata), making the purpose unambiguous.

  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 an example of the filter parameter but does not explicitly compare this tool to alternatives like sia_get_fields or other list tools. Usage guidance is implied but not direct, scoring a 3.

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

• sia_get_field_characteristicsA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds pagination behavior and metadata expansion option, but does not disclose rate limits or error handling. Adds moderate value 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?

  Concise and well-structured: purpose sentence followed by bulleted args. No unnecessary words or redundancy.

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

  Completeness4/5

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

  Good annotations and schema, but no output schema. Description mentions return type but not fields of FieldCharacteristicValue object. Mostly complete for a read-only tool.

  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 67%; description enhances with example for filter ('field_ID eq <uuid>') and clarifies top as max results. Provides additional context beyond schema descriptions.

  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?

  Clear use of verb 'list' and specific resource 'characteristic values attached to fields'. Distinguishes from sibling tools like sia_create_field_characteristic and sia_get_characteristic_configurations.

  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?

  Describes optional parameters and their defaults, providing clear usage context. No explicit alternatives mentioned, but the description makes it clear this is the read operation for field characteristics.

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

• sia_delete_crop_zoneA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true. The description adds valuable context beyond annotations by warning about prerequisites and clarifying the operation's nature. It appropriately supplements the structured data.

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

  Conciseness5/5

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

  The description is concise (three lines for the main text) and front-loads the critical warning. Every sentence serves a purpose without extraneous detail.

  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 simple one-parameter tool with annotations, the description covers purpose, usage prerequisites, parameter info, and expected return. No gaps remain 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 coverage is 100% with a clear description for the 'id' parameter. The description's Args section mirrors the schema, adding no new semantic value. Baseline 3 is appropriate as the schema already provides full parameter meaning.

  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 ('Delete'), the resource ('crop zone'), and the method ('by ID'). It is unambiguous and well-distinguished from sibling tools like sia_create_crop_zone or sia_get_crop_zones.

  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 explicit prerequisites ('ensure all KPIs and characteristics are removed first') and a warning about destructiveness. It does not explicitly mention when not to use or alternatives, but the guidance is strong enough for proper usage.

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

• sia_get_fieldsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral details: default top=100, OData filter syntax with example, and the list of returned fields. It does not contradict 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 concise and well-structured: one-line purpose, return fields, then parameter details. Every sentence adds value; no 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?

  For a simple list tool with annotations, the description covers return shape, parameter usage, and defaults. It could mention pagination beyond top, but overall complete enough given the complexity.

  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?

  Both parameters are explained: 'filter' includes an example OData expression, and 'top' specifies default and max. Despite schema coverage being 50%, the description adds significant meaning beyond the schema.

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

  Purpose5/5

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

  The description starts with 'List all fields from the SIA FarmAndFieldService', a specific verb-resource pair, and lists the returned fields. It is clearly distinct from sibling tools like sia_get_farms or sia_get_areas.

  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 retrieving fields and mentions OData filter capability, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., sia_get_crop_zones) or when not to use it.

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

• sia_get_location_typesA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds return format (Array of LocationType objects) but no additional behavioral traits beyond annotation coverage.

  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?

  Three concise sentences with no redundancy. Front-loaded purpose, then usage, then return info.

  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 zero parameters and rich annotations, description fully covers tool behavior. Returns array of objects with ID and name, sufficient for a simple list tool without output schema.

  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?

  No parameters present; baseline 4 as per rubric. Description adds no param info but none needed.

  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?

  Description uses specific verb 'List' and resource 'location types', clearly distinguishing from sibling tools that list other entities. Includes practical usage hint about using IDs for creating locations.

  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?

  Explicitly states to use locationType_ID values when creating locations, providing clear context. Lacks exclusionary guidance but suffices for tool purpose.

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

• sia_get_perennialsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the description adds value by detailing the return structure (Perennial objects with fields) and the default/max for top. No contradiction 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.

  Conciseness4/5

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

  The description is fairly concise, with a clear opening line, a brief definition of perennials, and structured args/returns. It avoids unnecessary verbosity, though the docstring style could be slightly more compact.

  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 no output schema, the description includes the return type and fields, which is good. It covers the main functionality (listing, filtering, pagination) but does not mention error handling, rate limits, or additional context needed for effective use.

  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 description must compensate. It explains that filter is an OData $filter string (with an example) and top is max results with a default of 100. This adds meaningful semantics beyond the bare schema properties.

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

  Purpose5/5

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

  The description clearly states the tool lists perennial plants from the SIA PerennialsService, defines what perennials are (long-lived plants linked to fields), and distinguishes it from sibling tools like sia_get_fields or sia_get_areas by specifying the resource.

  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 that the tool is for listing perennials with optional filtering and pagination, but does not explicitly state when to use vs alternatives or when not to use. The sibling tools list is available, but no direct guidance is given.

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

• sia_get_locationsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the return type ('Array of Location objects') and specific fields, providing useful context beyond the annotations without contradiction.

  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 very concise: a single sentence for purpose, followed by clear parameter and return value sections. No redundant information, and the most important details are front-loaded.

  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 low complexity (2 optional params, no output schema), the description fully covers the tool's behavior, parameters, and return format. It leaves no obvious gaps for an agent to infer additional requirements.

  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 description coverage is 0%, but the description thoroughly documents both parameters: 'filter' is described as an OData $filter string, and 'top' as max results with default 100. This significantly adds meaning over the raw schema, which only specifies types and constraints.

  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 'List locations from the SIA LocationService', specifying the verb 'List' and the resource 'locations'. It distinguishes from sibling tools like sia_get_areas or sia_get_crop_zones by naming the specific entity type.

  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 explains the tool's purpose and parameters but does not explicitly state when to use this tool versus alternatives (e.g., when to use sia_get_locations vs. sia_get_areas). The context is adequate but lacks comparative guidance.

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

• sia_get_varietiesA
  4.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds return shape (array of Variety objects with ID, name, crop_ID), providing extra context 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?

  Every sentence is informative: purpose, usage hint, parameter docs, return type. No unnecessary words. Front-loaded with 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?

  For a simple list tool with 2 optional parameters and no output schema, the description covers purpose, parameter usage, return shape, and practical use. Annotations handle safety. Complete.

  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 description coverage is 0%, but the description fully explains both parameters: filter as OData $filter with an example, and top as maximum results with default. This compensates completely for missing schema descriptions.

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

  Purpose5/5

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

  The description clearly states it lists crop varieties from the SIA CropAndVarietyService, and distinguishes from sibling tools (e.g., sia_get_crop_zones, sia_get_fields) by focusing on varieties.

  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?

  Provides explicit guidance: 'Use variety IDs when creating crop zones and perennials.' This tells when to use the data. Could be improved by excluding cases where it shouldn't be used, but context is clear.

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

• sia_create_areaA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate it's a creation (not read-only, not destructive). The description adds that it returns the created Area ID, providing additional behavioral context 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 concise with a brief intro, a clear list of parameters in a code-block style, and a returns statement. Every sentence serves a 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 8 parameters and no output schema, the description thoroughly explains each parameter and the tool's purpose. It is complete for the tool's role.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining the relationship between isAutomaticallyCalculated and areaSize, and providing example values for validFrom.

  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 'Create a new geographic area in the SIA AreaService' and explains that areas define boundary polygons for fields or crop zones. This distinguishes it from sibling tools like sia_create_field or sia_create_crop_zone.

  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 indicates when to use this tool (to create an area defining a boundary polygon). It does not explicitly mention when not to use it, but the sibling list provides context for alternatives.

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

• sia_get_seasonsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that it returns an array of Season objects with specific fields (ID, name, startDate, endDate), providing valuable behavioral detail 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 concise with three clear sentences plus an Args section. Every sentence adds value, and the structure is well-organized with no unnecessary words.

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

  Completeness5/5

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

  For a simple list tool with one optional parameter and no output schema, the description covers purpose, usage, parameter behavior, and return structure completely. It is self-contained and sufficient for an agent to use correctly.

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

  Parameters4/5

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

  The input schema has 0% coverage for parameter descriptions. The description compensates by explaining the 'top' parameter as 'Max results (default: 50)', adding meaning beyond the schema's type and constraints.

  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 explicitly states 'List agricultural seasons' which is a specific verb and resource. It distinguishes from siblings like 'sia_get_farms' by focusing on seasons, and provides context about their use in crop planning.

  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 advises using season IDs when creating crop zones, indicating when this tool is useful. However, it does not explicitly state when not to use it or mention alternatives, though the context implies it's for read-only retrieval.

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