Turf-MCP

by es3154

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. The tools are well-organized into categories (aggregation, booleans, measurement, etc.), and within each category, tools target specific geometric operations or algorithms. Descriptions are detailed and differentiate between similar tools (e.g., DBSCAN vs. K-means clustering, various boolean operations).
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with clear category prefixes (e.g., aggregation_clustersDbscan, booleans_booleanContains, measurement_area). The naming is predictable and readable throughout all 113 tools, with no mixing of conventions or chaotic variations.
Tool Count2/5
With 113 tools, the count is excessive for a single server's scope, even for a comprehensive geospatial library. This many tools can overwhelm agents and make discovery difficult. While the domain (Turf.js geospatial operations) is broad, a more modular approach with fewer, more generalized tools would be more appropriate.
Completeness5/5
The tool set provides complete coverage of the Turf.js geospatial operations domain. It includes aggregation, boolean operations, measurements, transformations, interpolation, joins, and utilities, with no obvious gaps. The surface supports a wide range of geospatial workflows from basic geometry creation to advanced spatial analysis.
Average 4.3/5 across 113 of 113 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal several important behavioral aspects: the tool considers obstacles and terrain factors, returns a GeoJSON LineString, can raise exceptions for various failure modes, depends on Turf.js and Node.js, and has specific coordinate system requirements. However, it doesn't mention performance characteristics, rate limits, or authentication requirements.
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 well-structured with clear sections (Args, Returns, Raises, Example, Notes), but it's quite lengthy. Some information could be more concise, and the purpose statement could be more front-loaded. However, most content serves a clear purpose given the complexity of the tool.
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 3-parameter tool with no annotations but with an output schema, the description provides good coverage. It explains the tool's purpose, detailed parameter semantics, return format, error conditions, dependencies, and includes a complete example. The main gap is lack of usage guidance relative to sibling tools, but otherwise it's quite comprehensive.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. Each parameter (start_point, end_point, options) gets detailed explanations including types, formats, coordinate systems, examples, and for 'options', the specific optional fields available. This adds substantial value beyond the minimal input 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 the tool's purpose: '计算两点之间的最短路径' (calculates the shortest path between two geographic points). It specifies the resource (geographic points) and verb (calculate shortest path), but doesn't explicitly differentiate from siblings like 'measurement_distance' or 'misc_nearest_point_on_line' which might have 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. With many sibling tools in the same domain (geospatial operations), there's no indication of when this specific shortest path calculation is appropriate versus other distance or path-related tools like 'measurement_distance' or 'misc_nearest_point_on_line'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context: it specifies the coordinate system (WGS84 with longitude first), notes dependencies (Turf.js and Node.js), and mentions error conditions (JavaScript execution failures, timeouts, or input format errors). However, it doesn't cover aspects like performance expectations, rate limits, or authentication needs, leaving gaps for a tool with computational geometry operations.
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 well-structured with sections (Args, Returns, Raises, Example, Notes), but it's overly verbose for a tool description. Much of the detail (like full JSON examples and implementation notes) could be moved to documentation or schema descriptions. While informative, it's not front-loaded efficiently, with core purpose stated upfront but buried in extensive parameter details.
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 complexity (geospatial computation with specific formats), 0% schema coverage, and no annotations, the description provides comprehensive context. It fully documents parameters, return values (including output schema details), error conditions, examples, and implementation notes. The presence of an output schema is noted, but the description still explains return values thoroughly, ensuring the agent has complete information for correct tool invocation.
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 schema description coverage is 0%, so the description must fully compensate. It does this excellently: it documents all three parameters (line, point, options) with detailed semantics, including types, formats, coordinate systems, examples, and optional fields with enums for 'units'. This goes far beyond the basic schema, providing the agent with everything needed to construct valid inputs.
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 point on a line to a given point). It specifies the verb ('找到' - find) and resource ('线上...位置' - point on a line), making the function distinct. However, it doesn't explicitly differentiate from sibling tools like 'measurement_pointToLineDistance' or 'booleans_booleanPointOnLine', which reduces the score from 5 to 4.
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 'measurement_pointToLineDistance' (which might return just distance) or 'booleans_booleanPointOnLine' (which checks if a point is on a line), leaving the agent without context for tool selection. Usage is implied only through the function name and description, but no explicit when/when-not instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by specifying: input must be valid JSON strings, coordinate order is [longitude, latitude] in WGS84, it depends on Turf.js and Node.js environment, and exceptions are raised for JavaScript execution failures, timeouts, or malformed input. However, it doesn't mention performance characteristics, rate limits, or authentication requirements.
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 well-structured with clear sections (Args, Returns, Raises, Example, Notes), but it's quite lengthy. Some information could be more concise - for example, the example section includes Python code that may not be necessary. The core purpose is stated upfront, but the overall length could be reduced while maintaining clarity.
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 has 2 parameters, no annotations, 0% schema description coverage, but has an output schema, the description provides substantial context. It thoroughly documents parameters, return format, exceptions, and dependencies. The main gap is lack of comparison with sibling tools, but otherwise it's quite complete for a transformation tool.
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 schema description coverage is 0%, so the description must fully compensate. It provides excellent parameter documentation: 'features' is explained as a JSON string array of GeoJSON features with a detailed example; 'options' is documented as an optional JSON string with specific fields (bbox, id) and examples. This goes far beyond what the bare schema provides.
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: '将多个地理特征组合成一个特征集合' (combine multiple geographic features into a feature collection). It specifies the verb ('组合' - combine) and resource ('地理特征' - geographic features). However, it doesn't explicitly differentiate from sibling tools like 'feature_conversion_combine' or 'aggregation_collect', which appear to have similar aggregation functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions that feature collections are useful for '批量处理和管理多个地理对象' (batch processing and managing multiple geographic objects), but doesn't specify when to use this tool versus alternatives like 'feature_conversion_combine' or 'aggregation_collect'. No explicit when-not-to-use scenarios or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context: it specifies the return format (JSON string with value and units), notes dependencies on Turf.js and Node.js, and mentions error cases (JavaScript execution failures, timeouts, input errors). However, it does not detail rate limits or authentication needs, which could be relevant for completeness.
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 structured with sections (Args, Returns, Raises, Example, Notes), which aids readability, but it is verbose with redundant information (e.g., repeating unit lists). Some sentences could be condensed without losing clarity, making it less front-loaded and efficient than optimal.
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, no annotations, no output schema, and 0% schema coverage, the description is quite complete: it covers purpose, parameters, return format, errors, examples, and dependencies. It lacks only minor details like exact error messages or performance limits, but overall provides sufficient context for effective use.
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 schema description coverage is 0%, so the description must compensate fully. It does so by clearly explaining each parameter (length, original_unit, final_unit), including types, descriptions, valid values with enums, and examples. This adds significant meaning beyond the bare schema, making parameter usage unambiguous.
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 as converting length units, specifying the action (convert) and resource (length values). It distinguishes itself from siblings like unit_conversion_convertArea by focusing on length, but does not explicitly differentiate from other length-related tools (e.g., measurement_length) beyond the title, which is slightly less specific than ideal for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions valid units and dependencies but lacks explicit context, prerequisites, or comparisons to siblings like measurement_length or other unit conversion tools, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well at disclosing behavioral traits. It explains the return format (GeoJSON FeatureCollection), error conditions (JavaScript execution failures, timeouts, input format errors), dependencies (Turf.js and Node.js), coordinate system (WGS84), and default behaviors (global bounding box when unspecified). It doesn't mention performance characteristics or rate limits, but covers most essential operational aspects.
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 well-structured with clear sections (Args, Returns, Raises, Example, Notes) but is quite lengthy. While all information is relevant, some redundancy exists (e.g., multiple mentions of GeoJSON format). The front-loaded purpose statement is clear, but the overall text could be more streamlined while maintaining completeness.
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 tool's moderate complexity (2 parameters, no annotations, but with output schema), the description is remarkably complete. It covers purpose, parameters, return format, errors, examples, dependencies, coordinate systems, and default behaviors. The output schema exists but the description still usefully explains the GeoJSON structure. No significant gaps remain for effective tool use.
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?
With 0% schema description coverage and 2 parameters, the description provides comprehensive parameter documentation beyond the bare schema. It explains 'count' with type, default, and example, and details 'options' with its JSON structure, optional fields (bbox, num_vertices, max_length, max_rotation), their defaults, and examples. This fully compensates for the schema's lack of descriptions.
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: '生成随机线特征集合' (generate random line feature collection) and specifies it operates within a bounding box. It distinguishes from siblings like random_randomPoint and random_randomPolygon by focusing on lines, but doesn't explicitly contrast with them. The verb+resource combination is specific but sibling differentiation is implicit rather than explicit.
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. While it mentions generating random lines, it doesn't explain scenarios where this is preferable to other random generation tools (like random_randomPoint) or when to use it within the broader geospatial workflow. There's no mention of prerequisites, dependencies, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context beyond the input schema by detailing the return format (JSON string with a boolean value), error conditions (JavaScript execution failures, timeouts, input format errors), dependencies (Turf.js library, Node.js environment), and operational notes (e.g., coordinate order, numerical tolerance, parallel relation based on direction vectors). This covers key behavioral aspects without 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 sections for Args, Returns, Raises, Example, and Notes, making it easy to navigate. It is appropriately sized, with each sentence adding value (e.g., explaining dependencies, formats, and examples). However, the Example section includes Python code that might be slightly verbose but remains relevant.
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 tool's complexity (geometric operation with specific dependencies), the description is complete. It covers input requirements, output format (aligned with the output schema), error handling, and environmental dependencies. With no annotations and an output schema present, the description adequately fills all gaps, providing a comprehensive understanding for an AI agent.
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 schema description coverage is 0%, but the description fully compensates by providing detailed parameter semantics. It specifies that 'line1' and 'line2' are JSON strings in GeoJSON format with LineString geometry, includes examples, and notes requirements like valid JSON and coordinate order ([longitude, latitude] in WGS84). This adds substantial meaning beyond the bare 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 the tool's purpose as '检查两条线段是否平行' (checks if two line segments are parallel), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'booleans_booleanClockwise' or 'booleans_booleanCrosses' beyond the general 'booleans_' prefix, though the function name 'booleanParallel' is self-explanatory in context.
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 lacks any mention of prerequisites, context for application (e.g., geometric analysis), or comparisons to sibling tools like 'booleans_booleanEqual' or 'booleans_booleanDisjoint', leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it specifies the coordinate system (WGS84 with longitude-first), notes dependency on Turf.js and Node.js environment, describes error conditions (JavaScript execution failure, timeout, input format errors), and explains the return format. However, it doesn't mention performance characteristics, rate limits, or authentication requirements.
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 appropriately structured with clear sections (Args, Returns, Raises, Example, Notes), but it's quite lengthy with detailed parameter explanations. While all content is valuable given the lack of schema descriptions, it could be more front-loaded with the core purpose before diving into parameter details. Some redundancy exists in the example section.
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 3-parameter tool with no annotations and no output schema, the description provides excellent completeness. It covers input requirements, return format, error conditions, dependencies, and includes a practical example. The main gap is lack of usage guidelines compared to sibling tools, but otherwise it gives the agent sufficient information to invoke the tool correctly.
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?
Given 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It details all three parameters (geojson, radius, options) with types, formats, coordinate systems, examples, optional fields with defaults, and valid enum values for units. This adds substantial meaning beyond the bare 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 ('创建缓冲区' - create buffer) on a specific resource ('GeoJSON 特征' - GeoJSON feature). It distinguishes itself from sibling tools by focusing on buffer creation rather than other geometric operations like transformation, aggregation, or measurement listed in the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions it can buffer points, lines, and polygons, it doesn't specify use cases or compare it to similar transformation tools like transformation_bboxClip or transformation_circle in the sibling list. There are no explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it generates a triangular grid, returns a GeoJSON FeatureCollection, and includes error handling details (e.g., raises exceptions for JavaScript execution failures or input format errors). It also notes dependencies on Turf.js and Node.js, adding useful context beyond basic functionality.
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 structured with sections like 'Args', 'Returns', 'Raises', 'Example', and 'Notes', which aids readability. However, it includes some redundant information (e.g., repeating JSON format details) and could be more front-loaded. The length is appropriate for the complexity, but not all sentences are strictly necessary, reducing efficiency.
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?
The description is highly complete for a tool with no annotations and an output schema. It covers purpose, parameters, return values (including format and example), error handling, dependencies, and usage notes (e.g., coordinate order, JSON string requirements). Given the complexity and lack of structured fields, it provides all necessary context for an agent to invoke the tool correctly.
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?
Given a schema description coverage of 0%, the description compensates fully by providing detailed parameter semantics. It explains each parameter ('bbox', 'cell_size', 'options') with types, formats, examples, and optional fields (e.g., 'units', 'properties', 'mask'). This adds significant value beyond the minimal input schema, ensuring the agent understands how to use the parameters correctly.
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: '在边界框内生成三角形网格' (generate a triangular grid within a bounding box). It specifies the action ('生成' - generate) and resource ('三角形网格' - triangular grid), making it distinct from siblings like 'grid_hexGrid' or 'grid_squareGrid'. However, it doesn't explicitly differentiate from all siblings, such as 'grid_pointGrid', which might also involve spatial grids but with different geometries.
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 spatial analysis and surface modeling, as noted in '用于空间分析和表面建模'. It provides context but lacks explicit guidance on when to choose this tool over alternatives like 'grid_hexGrid' or 'grid_squareGrid'. No exclusions or prerequisites are mentioned, leaving the agent to infer based on the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by: specifying the return type (GeoJSON FeatureCollection), mentioning dependencies ('依赖于 Turf.js 库和 Node.js 环境' - depends on Turf.js library and Node.js environment), and documenting error conditions ('当 JavaScript 执行失败、超时或输入数据格式错误时抛出异常' - throws exceptions for JavaScript execution failure, timeout, or input data format errors). It also notes coordinate system (WGS84) and input format requirements. However, it doesn't mention performance characteristics like computational cost or memory usage.
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 clear sections (Args, Returns, Raises, Example, Notes), making it easy to navigate. It's appropriately sized for a tool with three parameters and complex behavior. However, some information in the Notes section (e.g., about Turf.js dependency) could be integrated earlier, and the Example includes Python code that may not be directly relevant to all users, slightly reducing efficiency.
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 tool's complexity (spatial grid generation with multiple parameters), no annotations, and an output schema present (though not detailed in the context), the description is highly complete. It covers purpose, parameters, return format, errors, examples, and important notes about dependencies and coordinate systems. The presence of an output schema means the description doesn't need to exhaustively explain return values, and it provides all necessary context for effective use.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. It explains all three parameters (bbox, cell_size, options) with types, formats, examples, and for options, lists optional fields with valid values for 'units'. This adds substantial meaning beyond the bare schema, making parameter usage clear despite the schema's lack of descriptions.
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: '在边界框内生成六边形网格' (generate a hexagonal grid within a bounding box). It specifies the verb ('生成' - generate) and resource ('六边形网格' - hexagonal grid), and distinguishes it from siblings like grid_pointGrid, grid_squareGrid, and grid_triangleGrid by specifying the hexagonal shape. However, it doesn't explicitly contrast with these siblings in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the Notes section ('六边形网格提供均匀的空间覆盖，常用于地理分析' - hexagonal grids provide uniform spatial coverage, commonly used in geographic analysis), suggesting it's for spatial analysis and visualization. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like grid_squareGrid or grid_triangleGrid, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining key behaviors: it specifies coordinate system (WGS84 with longitude-first), default scaling origin ('centroid'), mutation behavior via the 'mutate' option, handling of FeatureCollections, and error conditions (JavaScript failures, timeouts, data format errors). However, it doesn't mention performance characteristics or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some sections could be more concise (e.g., the example includes full import statements). Overall, most sentences earn their place by adding valuable information.
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 tool's complexity (geometric transformation with multiple parameters), no annotations, and an output schema present, the description provides excellent completeness. It covers purpose, parameters, return values, errors, examples, and implementation details (Turf.js, Node.js). The output schema handles return format documentation, allowing the description to focus on behavioral context.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation: geojson (format, coordinate system, examples), factor (meaning of values, examples), and options (optional fields, defaults, examples). Each parameter's purpose, format, and constraints are clearly explained beyond what the bare schema provides.
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: '缩放 GeoJSON 对象' (scale GeoJSON objects) using Turf.js transformScale method. It specifies the exact operation (scaling), the resource (GeoJSON objects), and distinguishes it from sibling transformation tools like transformRotate or transformTranslate by focusing specifically on scaling.
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. While it mentions the Turf.js library and Node.js environment, it doesn't explain when scaling is appropriate compared to other geometric transformations available in the sibling tools list, nor does it mention prerequisites or constraints beyond technical requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies the return format (JSON string with a 'value' object), notes default behavior (precision=0 for integer rounding), and mentions dependencies (Turf.js, Node.js) and error conditions (JavaScript failures, timeouts, input errors). However, it doesn't detail performance aspects like rate limits.
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 appropriately sized but not optimally structured: it front-loads the purpose, but includes verbose sections like 'Args', 'Returns', 'Raises', 'Example', and 'Notes' that could be streamlined. Some redundancy exists (e.g., repeating precision details), reducing efficiency.
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 tool's low complexity (2 parameters, no nested objects), no annotations, and an output schema present, the description is complete: it covers purpose, parameters, return values, errors, examples, and dependencies. The output schema handles return structure, so the description needn't explain it further.
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 schema description coverage is 0%, so the description compensates fully by providing detailed parameter semantics: it explains 'num' as the number to round with type, range, and example, and 'precision' as decimal places with type, description, default, range, and example. This adds meaning beyond the basic 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 tool's purpose with specific verbs ('四舍五入', '控制小数位数') and resources ('数字'), distinguishing it from siblings like coordinate_mutation_clean_coords or coordinate_mutation_truncate. It explicitly defines the mathematical rounding operation, making its function 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 implies usage through the 'Args' and 'Example' sections, suggesting it's for numerical precision control, but lacks explicit guidance on when to use this tool versus alternatives (e.g., coordinate_mutation_truncate for truncation). No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses several behavioral traits: it creates a complete geographic feature (not just geometry), requires valid JSON strings as input, uses WGS84 coordinate system with [longitude, latitude] order, returns a GeoJSON Feature string, raises exceptions for execution failures/timeouts/format errors, and depends on Turf.js and Node.js. It doesn't mention performance characteristics or rate limits, but covers core behavior well.
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 well-structured with clear sections (Args, Returns, Raises, Example, Notes), but is quite lengthy with detailed parameter explanations and a full code example. While informative, it could be more concise by reducing some redundancy (e.g., the example repeats format details). Every sentence adds value, but front-loading could be improved.
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 tool's complexity (3 parameters, 0% schema coverage, no annotations, but has output schema), the description is highly complete. It covers purpose, parameters, return values (though output schema exists, it adds clarity), error conditions, dependencies, coordinate system, and provides a working example. For a creation tool with no annotations, this provides comprehensive context.
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?
With 0% schema description coverage (schema only provides types without descriptions), the description fully compensates by providing detailed parameter semantics. It explains each parameter's purpose, format requirements, optional fields, and provides concrete examples. The description adds significant value beyond the bare schema, making parameter usage clear.
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: '创建单个地理特征对象' (create a single geographic feature object). It specifies the verb ('创建' - create) and resource ('地理特征对象' - geographic feature object), and distinguishes from siblings like 'helper_featureCollection' (which creates collections) and geometry helpers (which create only geometry).
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 mentioning it's for '表示具体的地理要素' (representing specific geographic elements) and that features are 'GeoJSON 中的基本数据单元' (basic data units in GeoJSON). However, it doesn't explicitly state when to use this vs. alternatives like 'helper_featureCollection' for multiple features or geometry helpers for geometry-only creation. No explicit exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds significant behavioral context. It discloses dependencies (Turf.js library, Node.js environment), constraints (coordinate order, JSON string requirements, no MultiPolygon support), error conditions (raises Exception on failures), and the effect of the 'propertyName' option. This goes beyond basic functionality to inform the agent about implementation details and limitations.
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 well-structured with sections (Args, Returns, Raises, Example, Notes), but it is verbose with technical details and an extensive example. While informative, some redundancy (e.g., repeating JSON format details) could be trimmed for better conciseness without losing clarity.
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 tool's complexity (geospatial operation with specific constraints), no annotations, and an output schema present, the description is highly complete. It covers purpose, parameters, returns, errors, examples, and notes on dependencies and limitations. The output schema handles return values, so the description appropriately focuses on usage and behavior, leaving no gaps for the agent.
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%, so the description must fully compensate. It provides detailed semantics for both parameters: 'featureCollection' (type, format, coordinate system, example) and 'options' (type, optional fields like 'propertyName', example). This adds substantial meaning beyond the minimal schema, ensuring the agent understands how to structure inputs 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: '合并相邻的多边形' (merge adjacent polygons). It specifies the verb (merge/dissolve) and resource (polygons), and distinguishes from siblings by focusing on polygon merging rather than other geometric operations like union, intersection, or buffering listed in the sibling tools.
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 through technical constraints (e.g., '不支持 MultiPolygon 特征' - does not support MultiPolygon features) and notes about property-based grouping. However, it lacks explicit guidance on when to use this tool versus alternatives like 'transformation_union' or other sibling tools, leaving the agent to infer based on the dissolve operation's specific behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool generates Voronoi polygons from point sets, specifies coordinate system (WGS84), mentions each input point corresponds to an output polygon, and notes dependencies (Turf.js, Node.js). It also covers error conditions (Raises section) and technical constraints (e.g., JSON string format, coordinate order). This provides substantial behavioral context beyond basic functionality.
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 clear sections (Args, Returns, Raises, Example, Notes), making it easy to navigate. It is appropriately sized for a tool with technical complexity, though some sections (like the detailed example) are lengthy. Most sentences earn their place by providing essential technical details, but it could be slightly more concise in the example section.
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 (geometric transformation with specific input/output formats), no annotations, and no output schema, the description does an excellent job of providing context. It covers input requirements, output format, error handling, dependencies, and examples. The only minor gap is the lack of explicit usage guidelines versus alternatives, but overall it is highly complete for effective agent use.
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%, so the description must fully compensate. It provides detailed semantic information for both parameters: 'points' is explained as a GeoJSON FeatureCollection with Point features in WGS84, including format, coordinate order, and an example; 'options' is described as optional with a 'bbox' field for clipping, including default values and an example. This adds comprehensive meaning beyond the bare 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 ('生成 Voronoi 多边形' - generate Voronoi polygons) and resource ('从点集' - from point sets). It distinguishes itself from sibling tools by specifying the geometric transformation it performs, unlike other transformation tools like buffer, simplify, or union. The purpose is precise and 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 implies usage context through technical details (e.g., input format, coordinate system, algorithm source), but does not explicitly state when to use this tool versus alternatives. It mentions the algorithm is from d3-voronoi and depends on Turf.js/Node.js, which provides some technical context, but lacks explicit guidance on scenarios or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the algorithm type (DBSCAN), coordinate system (WGS84 with [longitude, latitude] order), cluster numbering (starting at 0, -1 for noise), dependencies (Turf.js and Node.js), and error conditions (raises Exception for JavaScript failures, timeouts, or input format errors). It also notes input requirements (valid JSON strings) and output format. However, it lacks details on performance, rate limits, or specific permission needs.
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 sections (Args, Returns, Raises, Example, Notes), making it easy to navigate. It is appropriately sized for a complex tool with multiple parameters and output details. Some sections (like the Example and Notes) are lengthy but necessary for clarity. Minor redundancy exists (e.g., repeating JSON format details), but overall, it is efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 0% schema coverage, no annotations, but has output schema), the description is highly complete. It explains the tool's purpose, parameters, return values (with output schema details), error handling, examples, and important notes (e.g., coordinate order, dependencies). The output schema is described in the Returns section, so the description doesn't need to duplicate that. It covers all necessary context for effective use.
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%, so the description must compensate. It provides detailed semantics for all three parameters: 'points' (GeoJSON FeatureCollection format with examples), 'max_distance' (maximum distance in kilometers with units), and 'options' (optional JSON with fields like 'units' and 'minPoints', including valid values and defaults). This adds significant meaning beyond the bare schema, fully documenting parameter usage 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 the tool's purpose: '使用 DBSCAN 算法进行点聚类' (use DBSCAN algorithm for point clustering). It specifies the algorithm (DBSCAN), the resource (points), and the action (clustering). It distinguishes from siblings like 'aggregation_clustersKmeans' by explicitly naming DBSCAN, which is a different clustering method.
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 through the algorithm explanation ('基于密度的空间聚类算法' - density-based spatial clustering algorithm) and notes on DBSCAN capabilities ('能够识别任意形状的聚类，并处理噪声点' - can identify arbitrary-shaped clusters and handle noise points). However, it does not explicitly state when to use this tool versus alternatives like K-means or other aggregation tools, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the aggregation method ('聚合方式为求和' - aggregation method is summation), spatial logic ('仅对位于多边形内部的点' - only points inside polygons), coordinate system ('坐标顺序为 [经度, 纬度] (WGS84 坐标系)' - coordinate order [longitude, latitude] in WGS84), dependencies ('依赖于 Turf.js 库和 Node.js 环境' - depends on Turf.js and Node.js), and error conditions ('Raises: Exception: 当 JavaScript 执行失败、超时或输入数据格式错误时抛出异常' - raises exceptions for JavaScript failures, timeouts, or input format errors). It doesn't mention performance, rate limits, or auth needs, but covers core operational behavior well.
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 sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. It's appropriately sized for a complex tool, but some redundancy exists (e.g., repeating JSON format details). Most sentences earn their place by clarifying parameters, behavior, or usage, though it could be slightly more streamlined.
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 tool's complexity (spatial aggregation with 4 parameters), no annotations, and an output schema provided (Returns section details the output format), the description is highly complete. It covers purpose, parameters, behavior, dependencies, errors, examples, and spatial constraints, leaving minimal gaps for an agent to invoke it correctly. The output schema in the description compensates for the lack of structured output schema.
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%, so the description must compensate fully. It provides detailed semantics for all 4 parameters: 'polygons' and 'points' are explained as GeoJSON FeatureCollections with specific geometry types and examples, 'in_field' as the input attribute field name to aggregate, and 'out_field' as the output field name to create. The description adds substantial meaning beyond the bare schema, including format, examples, 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 the tool's purpose: '将点属性聚合到多边形中' (aggregate point attributes into polygons). It specifies the verb ('聚合' - aggregate) and resource ('点属性' - point attributes, '多边形' - polygons), and distinguishes from siblings like 'joins_pointsWithinPolygon' by focusing on aggregation rather than spatial joins or other operations.
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 through context ('用于统计和汇总分析' - for statistical and summary analysis) and the Notes section clarifies spatial constraints ('仅对位于多边形内部的点进行属性聚合' - only aggregates points inside polygons). However, it doesn't explicitly state when to use this tool versus alternatives like 'joins_pointsWithinPolygon' or other aggregation tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing: the return format (JSON string with boolean value), error conditions (JavaScript execution failure, timeout, malformed input), coordinate system requirements (WGS84 with [longitude, latitude] order), and implementation dependencies (Turf.js and Node.js). It doesn't mention performance characteristics or rate limits, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some sections could be more concise (the example includes full import statements and async code). Overall, most sentences earn their place by providing essential information.
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 tool's complexity (geospatial boolean operation), the description provides complete context: purpose, detailed parameter semantics, return format, error conditions, examples, and implementation notes. With an output schema present, the description appropriately focuses on explaining the boolean relationship rather than repeating return value structure. It covers all essential aspects for correct tool invocation.
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?
With 0% schema description coverage (schema only shows parameter names and types as strings), the description fully compensates by providing detailed parameter documentation: data types (JSON strings), formats (valid GeoJSON objects), examples, and specific requirements (must be valid JSON strings). This adds significant value beyond the bare 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 tool's purpose with specific verbs and resources: '检查两个几何图形是否相交' (checks if two geometries intersect) and elaborates on the specific type of intersection ('交叉但不相交于边界点' - crossing but not intersecting at boundary points). It distinguishes from siblings like 'booleans_booleanContains' and 'booleans_booleanWithin' by specifying the exact topological relationship being tested.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the definition of 'booleanCrosses' and notes about boundary contact not counting as crossing, but doesn't explicitly state when to use this tool versus alternatives like 'booleans_booleanOverlap' or 'booleans_booleanIntersects'. The sibling tool list shows many boolean operations, but no explicit guidance is provided for choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds significant behavioral context beyond basic functionality. It discloses: coordinate system requirements (WGS84), structural equality criteria, that properties don't affect equality, dependency on Turf.js/Node.js, and error conditions (JavaScript execution failures, timeouts, malformed data). This provides good transparency about how the tool behaves and its constraints.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some Notes could be more concise (e.g., the Turf.js dependency might be implied by context). Overall, most sentences earn their place by adding value.
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 tool's complexity (geometric equality comparison with specific coordinate systems and dependencies), no annotations, and an output schema that only indicates a boolean result, the description provides excellent completeness. It covers purpose, parameters, returns, errors, examples, and implementation details, making it fully self-contained for an AI agent.
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?
With 0% schema description coverage (schema only shows parameter names and types), the description fully compensates by providing detailed parameter documentation: data types (JSON strings), formats (valid GeoJSON objects), examples, and specific requirements ('必须是有效的 JSON 字符串'). This adds substantial meaning beyond the minimal input 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 tool's purpose with specific verb ('检查两个几何图形是否相等') and resource ('两个GeoJSON几何图形'), distinguishing it from sibling tools like 'booleans_booleanContains' or 'booleans_booleanWithin' which perform different geometric comparisons. The first sentence directly answers 'what does this tool do?'
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 through the Notes section (e.g., '坐标顺序为 [经度, 纬度]', '属性不同不影响几何相等性判断'), but doesn't explicitly state when to use this tool versus alternatives like 'booleans_booleanContains' for containment checks. There's no 'use this when...' or 'instead of...' guidance, leaving usage context implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing: algorithm used (ray-casting), default boundary behavior (points on boundary considered inside), coordinate system (WGS84), dependencies (Turf.js, Node.js), error conditions (JavaScript failures, timeouts, invalid data), and output format. It provides substantial behavioral context beyond basic functionality.
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?
Well-structured with purpose statement, parameter details, returns, raises, example, and notes sections. Every section adds value, though the example code block is lengthy. The description is appropriately sized for a 3-parameter tool with complex data formats.
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 tool's complexity (spatial analysis with specific data formats), no annotations, 0% schema coverage, but with output schema provided, the description is remarkably complete. It covers purpose, parameters, behavior, errors, examples, and implementation details - everything needed for correct tool invocation.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation: point and polygon require GeoJSON Feature strings with specific geometry types, examples of valid JSON, coordinate order, and options object structure with ignoreBoundary field. This adds comprehensive meaning beyond the bare 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 tool's purpose as '检查点是否在多边形内部' (check if a point is inside a polygon), which is a specific verb+resource action. It distinguishes from siblings like booleans_booleanContains and booleans_booleanWithin by focusing specifically on point-in-polygon testing rather than general spatial relationships.
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 through the example and notes (e.g., coordinate order, boundary handling), but doesn't explicitly state when to use this tool versus alternatives like booleans_booleanWithin or joins_pointsWithinPolygon. It provides technical context but lacks explicit comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool uses a distance algorithm with numerical tolerance, depends on Turf.js and Node.js, raises exceptions for failures or bad input, and returns a JSON boolean result. It covers execution environment and error handling, though it could mention performance or limitations more explicitly.
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 sections for Args, Returns, Raises, Example, and Notes, making it easy to navigate. It is appropriately sized but could be more front-loaded; the purpose is stated upfront, but key details like coordinate order and dependencies are buried in notes. Some redundancy exists (e.g., repeating JSON string format), but overall it's efficient.
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 tool's moderate complexity (3 parameters, no annotations, but has output schema), the description is complete. It explains inputs, outputs, errors, examples, and notes on dependencies and algorithms. The output schema is present, so the description doesn't need to detail return values beyond what's provided. It covers all necessary context for effective use.
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%, so the description must compensate fully. It adds detailed meaning for all three parameters: 'point' and 'line' as GeoJSON features with specific geometry types and examples, and 'options' with the 'ignoreEndVertices' field and default. This provides complete semantic information beyond the basic schema types.
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 as '检查点是否在线上' (check if a point is on a line), specifying the verb '检查' (check) and the resources '点' (point) and '线' (line). It distinguishes from siblings like 'booleans_booleanPointInPolygon' by focusing on line geometries rather than polygons, and from 'measurement_pointToLineDistance' by providing a boolean result rather than a distance measurement.
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 through the example and notes, such as using GeoJSON format and WGS84 coordinates, but does not explicitly state when to use this tool versus alternatives like 'booleans_booleanContains' or 'booleans_booleanWithin'. It provides context on input requirements but lacks explicit guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds significant behavioral context beyond the input schema. It discloses that the tool removes consecutive duplicate coordinates, simplifies geometries, depends on Turf.js and Node.js, and can raise exceptions for execution failures, timeouts, or bad input. It also notes coordinate order and JSON string requirements, though it could mention performance or rate limits.
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 sections for Args, Returns, Raises, Example, and Notes, making it easy to navigate. It is appropriately sized but could be more concise by integrating some details (e.g., coordinate order) into the Args section. Every sentence adds value, though minor redundancies exist.
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 complexity of a mutation tool with no annotations, 2 parameters, and an output schema, the description is highly complete. It covers purpose, parameters, returns, errors, examples, and dependencies. The output schema exists, so the description needn't explain return values in detail, and it provides sufficient context for effective tool use.
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 schema description coverage is 0%, so the description must compensate, which it does effectively. It provides detailed semantics for both parameters: 'geojson' is explained with type, format, coordinate system, and an example; 'options' is described with type, optional fields like 'mutate', and an example. This adds substantial meaning beyond the basic 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 tool's purpose with specific verbs ('清理' meaning 'clean', '移除' meaning 'remove', '简化' meaning 'simplify') and resource ('GeoJSON 数据中的冗余坐标点' meaning 'redundant coordinate points in GeoJSON data'). It distinguishes from siblings like 'coordinate_mutation_flip' or 'coordinate_mutation_round_number' by focusing on coordinate deduplication and simplification rather than transformation or rounding.
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 cleaning redundant coordinates in GeoJSON data, but does not explicitly state when to use this tool versus alternatives like 'transformation_simplify' (which might simplify geometry differently) or other coordinate mutation tools. It provides context about removing consecutive duplicate points, but lacks explicit guidance on exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses that the tool returns a FeatureCollection of Points, specifies coordinate order (longitude, latitude), notes dependencies on Turf.js and Node.js, and mentions potential exceptions for execution failures, timeouts, or bad input. It could improve by detailing performance or memory implications for large inputs.
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 sections (Args, Returns, Raises, Example, Notes), but includes some redundancy (e.g., repeating coordinate order). Most sentences earn their place by clarifying behavior or parameters, though it could be slightly more concise by merging similar points.
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 tool's moderate complexity (geometric conversion), no annotations, and an output schema (though not provided in context, described in Returns), the description is highly complete: it covers purpose, parameters, return format, errors, examples, dependencies, and coordinate specifics, leaving little ambiguity for an AI agent.
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 has 0% description coverage, but the description fully compensates: it defines 'geojson' as a JSON string in GeoJSON format, specifies WGS84 coordinate system with [lng, lat] order, provides a detailed example, and notes it must be valid JSON. This adds significant meaning beyond the bare 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 tool's purpose: '将几何图形分解为单独的点特征' (decompose geometric shapes into separate point features). It specifies the verb (decompose/explode) and resource (geometric shapes/GeoJSON features), and distinguishes from siblings by focusing on vertex extraction rather than aggregation, conversion to other formats, or boolean operations listed in sibling tools.
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 when needing point features from geometric vertices, but does not explicitly state when to use this tool versus alternatives like 'feature_conversion_combine' or 'feature_conversion_flatten'. It provides context about input format and coordinate system, but lacks explicit comparisons or exclusions for sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: the tool automatically closes line segments, accepts optional configuration parameters (properties, autoComplete, orderCoords, mutate), specifies the return format (GeoJSON Polygon/MultiPolygon as JSON string), and mentions error conditions (JavaScript execution failure, timeout, invalid input). It also notes dependencies on Turf.js and Node.js environment, which is valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises, Example, Notes), making it easy to parse. It's appropriately sized for a tool with 2 parameters and no annotations. Some sections like the example are detailed but necessary for clarity. Minor redundancy in notes (e.g., repeating JSON string requirement) slightly reduces efficiency.
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 tool's complexity (geometric conversion with options), no annotations, and an output schema present, the description is highly complete. It covers purpose, parameters, return values, errors, examples, and dependencies. The output schema handles return structure, so the description appropriately focuses on semantics and usage context without duplicating schema details.
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%, so the description must fully compensate. It provides comprehensive parameter details: 'line' is described with type, format, coordinate system, and an example; 'options' is detailed with type, optional fields, and an example. This adds significant meaning beyond the bare schema, covering all 2 parameters thoroughly.
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: '将线转换为多边形' (convert line to polygon). It specifies the exact transformation (line geometry to polygon geometry) and mentions automatic closure of start and end points. This distinguishes it from sibling tools like 'feature_conversion_polygon_to_line' which performs the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the example and notes (e.g., input must be valid JSON strings, coordinate order, dependency on Turf.js/Node.js). However, it doesn't explicitly state when to use this tool versus alternatives like 'feature_conversion_polygonize' or 'feature_conversion_combine', nor does it provide exclusion criteria or prerequisites beyond format requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses that the tool creates new features (implying mutation), specifies coordinate order ([longitude, latitude]), minimum point requirements (at least two), JSON format constraints, dependencies (Turf.js, Node.js), and error conditions (exceptions for failures). It doesn't mention rate limits or authentication needs, but covers essential behavioral aspects.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. However, it's moderately long due to comprehensive parameter details, which are justified given the 0% schema coverage. Some redundancy exists (e.g., repeating JSON string requirements), but overall it's efficient.
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 tool's complexity (3 parameters, no annotations, 0% schema coverage) and the presence of an output schema, the description is highly complete. It covers purpose, parameters, return values, errors, examples, and technical notes. The output schema is described in detail, making the tool fully understandable for an AI agent.
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%, so the description must fully compensate. It provides detailed semantics for all 3 parameters: coordinates (format, example), properties (format, example), and options (optional fields, examples). Each parameter's type, format, and usage are clearly explained beyond the basic 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 tool's purpose: '创建线特征对象' (create line feature object) with specific details about creating linear geographic features from coordinate arrays. It distinguishes itself from siblings like helper_point or helper_polygon by focusing exclusively on LineString features.
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 through examples and notes (e.g., '用于表示路径、边界等线性地理要素'), but doesn't explicitly state when to use this tool versus alternatives like helper_multiLineString or random_randomLineString. It provides technical prerequisites 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool creates GeoJSON MultiLineString features, requires valid JSON string inputs, uses [longitude, latitude] order in WGS84, includes error handling ('Raises: Exception: 当 JavaScript 执行失败、超时或输入数据格式错误时抛出异常' - raises exceptions for JavaScript execution failure, timeout, or input format errors), and has dependencies on Turf.js and Node.js. It does not cover rate limits, authentication needs, or performance characteristics, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Args, Returns, Raises, Example, Notes), making it easy to navigate. It is appropriately sized for a tool with three parameters and complex data formats. Some redundancy exists (e.g., repeating JSON string format in multiple places), but overall, sentences earn their place by providing essential details without unnecessary fluff.
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 complexity (3 parameters with 0% schema coverage, no annotations, but has output schema), the description is complete. It explains the tool's purpose, parameters in detail, return format (GeoJSON Feature with MultiLineString geometry), error conditions, dependencies, and includes a full example. The output schema existence means the description doesn't need to redundantly explain return values, but it still provides a clear return example and format, ensuring the agent has all necessary context.
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%, so the description must fully compensate. It adds comprehensive meaning beyond the schema: for 'coordinates', it specifies the JSON string format, nested array structure with examples, and coordinate order; for 'properties', it describes it as a key-value object JSON string or null with an example; for 'options', it details optional fields (bbox, id) with examples. This fully documents all three parameters with clear semantics and usage examples.
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: '创建多线特征对象' (create multi-line feature object) and elaborates with '根据多组坐标点数组创建多线特征，用于表示包含多条线的复杂线性要素' (create multi-line features based on multiple coordinate point arrays, used to represent complex linear elements containing multiple lines). It distinguishes from siblings like helper_lineString by specifying it handles multiple lines, not single lines.
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 through context (e.g., '用于表示包含多条线的复杂线性要素' - used for complex linear elements with multiple lines) and notes dependencies ('依赖于 Turf.js 库和 Node.js 环境' - depends on Turf.js library and Node.js environment). However, it lacks explicit guidance on when to use this tool versus alternatives like helper_lineString or helper_multiPolygon, and does not specify prerequisites or exclusions beyond format requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool creates a GeoJSON MultiPoint Feature, requires valid JSON strings for inputs, uses [longitude, latitude] order in WGS84, and raises exceptions for failures, timeouts, or bad input. It also notes dependencies on Turf.js and Node.js. However, it doesn't mention rate limits, authentication needs, or side effects beyond creation.
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 sections (Args, Returns, Raises, Example, Notes), making it easy to navigate. It is appropriately sized but could be more front-loaded; the purpose is clear early, but some details (like dependencies) are in Notes. Most sentences earn their place, though minor trimming is possible.
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 tool with 3 parameters, 0% schema coverage, no annotations, but an output schema (implied by Returns section), the description is complete. It covers purpose, parameters, return values, errors, examples, and notes on dependencies and formats. The output schema is described in detail, so no gaps exist 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?
Given schema description coverage is 0%, the description compensates fully by detailing all three parameters (coordinates, properties, options) with types, formats, examples, and optional fields. It adds meaning beyond the basic schema by specifying JSON string formats, coordinate arrays, property key-value pairs, and option fields like bbox and id, which are not 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 tool's purpose: '创建多点特征对象' (create a multipoint feature object) and elaborates that it '根据坐标点数组创建多点特征，用于表示一组相关的点要素' (creates a multipoint feature based on a coordinate point array, used to represent a set of related point features). This specifies the verb ('创建' - create), resource ('多点特征对象' - multipoint feature object), and distinguishes it from sibling tools like helper_point (single point) or helper_lineString (line).
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 explaining the tool's purpose for representing related point features, but does not explicitly state when to use this tool versus alternatives (e.g., helper_point for single points, helper_featureCollection for collections). It provides technical context (e.g., coordinate format, JSON string requirements) but lacks explicit guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it creates a GeoJSON MultiPolygon Feature, specifies input requirements (valid JSON strings, coordinate order [lng, lat] in WGS84), notes dependencies (Turf.js and Node.js), and mentions error conditions (raises Exception for execution failure, timeout, or format errors). However, it lacks details on performance aspects like rate limits or resource usage.
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 sections (Args, Returns, Raises, Example, Notes), making it easy to navigate. It is appropriately sized, with each sentence adding value (e.g., explaining coordinate order, dependencies). However, some redundancy exists (e.g., repeating JSON string details), slightly reducing efficiency, but overall it remains front-loaded and informative.
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 complexity (3 parameters, no annotations, 0% schema coverage, but has output schema), the description is complete. It explains inputs, outputs (GeoJSON format with example), error handling, dependencies, and usage notes. The output schema is present, so the description correctly focuses on input semantics and behavioral context without needing to detail return values, covering all necessary aspects for effective tool use.
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 schema description coverage is 0%, so the description must fully compensate. It adds comprehensive meaning beyond the schema by detailing each parameter: coordinates (type, format, example), properties (type, format, example), and options (type, optional fields, example). This includes JSON string formats, coordinate structures, and usage notes, providing clear semantics that the schema alone does not.
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: '创建多多边形特征对象' (creates a multi-polygon feature object), specifying the verb ('创建') and resource ('多多边形特征对象'). It distinguishes from siblings by focusing on multi-polygon creation, unlike other helper tools (e.g., helper_polygon for single polygons), making it specific and 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 implies usage through context (e.g., '用于表示包含多个多边形的复杂区域要素' - for representing complex area features with multiple polygons), but does not explicitly state when to use this tool versus alternatives like helper_polygon or other geometry tools. No exclusions or prerequisites are mentioned, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it creates a GeoJSON Point Feature, specifies input/output formats, notes dependencies (Turf.js, Node.js), lists exceptions (JavaScript execution failure, timeout, input format errors), and provides an example. However, it doesn't mention rate limits, authentication needs, or side effects beyond creation.
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 sections (Args, Returns, Raises, Example, Notes), front-loading the purpose. It is appropriately sized but includes some redundant details (e.g., repeating JSON string format in multiple places). Every sentence adds value, though it could be slightly more concise.
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 tool's complexity (3 parameters, creation operation), no annotations, and an output schema exists (implied by Returns section), the description is complete. It covers purpose, parameters, return values, errors, examples, and notes, providing all necessary context for an agent to use the tool correctly.
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%, so the description must compensate. It fully documents all 3 parameters (coordinates, properties, options) with types, formats, examples, and optional fields. This adds significant meaning beyond the basic schema, providing clear semantics and usage details for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '创建点特征对象' (create point feature object) and elaborates that it '根据坐标点创建点特征，用于表示具体的地理位置点' (creates point features based on coordinate points, used to represent specific geographic location points). This is specific (verb+resource), distinguishes it from sibling tools like helper_featureCollection or helper_lineString, and avoids tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through examples and notes (e.g., coordinates in WGS84, JSON string requirements), but does not explicitly state when to use this tool versus alternatives. It mentions dependencies (Turf.js, Node.js) and basic use cases, but lacks explicit guidance on when to choose this over other helper_* tools 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it performs spatial interpolation using inverse distance weighting, outputs GeoJSON FeatureCollections, handles specific input formats (JSON strings), and raises exceptions for failures. It also notes dependencies (Turf.js, Node.js) and assumptions (closer points have more influence). However, it lacks details on performance, rate limits, or specific error conditions beyond generic exceptions.
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 clear sections (Args, Returns, Raises, Example, Notes), making it easy to navigate. It is appropriately sized for a complex tool with 3 parameters, though some sections (like the detailed example) are lengthy. Every sentence adds value, but it could be slightly more front-loaded by moving key usage notes earlier.
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 tool's complexity (spatial interpolation with 3 parameters), no annotations, and an output schema present, the description is highly complete. It covers purpose, parameters, return values, errors, examples, and notes on dependencies and assumptions. The output schema handles return format details, so the description focuses on operational context, making it sufficient for effective use.
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%, so the description must fully compensate. It provides comprehensive parameter semantics: 'points' is explained as a GeoJSON FeatureCollection with examples, 'cell_size' as grid cell distance with units, and 'options' as a JSON string with detailed optional fields (gridType, property, units, weight, bbox), including defaults and examples. This adds significant meaning beyond the bare 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 tool's purpose: '使用反距离权重法进行空间插值' (performs spatial interpolation using inverse distance weighting). It specifies the method (inverse distance weighting), the resource (known points' attribute values), and the output (estimated values on a grid). This distinguishes it from sibling interpolation tools like 'interpolation_isobands', 'interpolation_isolines', and 'interpolation_tin' by explicitly naming the algorithm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the method explanation and parameter details, such as when to use certain grid types or properties. However, it does not explicitly state when to choose this tool over alternatives like 'interpolation_tin' or 'interpolation_planepoint', nor does it provide prerequisites or exclusions. The guidance is present but not direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it generates MultiPolygon features from point grids, handles JSON inputs, uses WGS84 coordinates, depends on Turf.js and Node.js, and raises exceptions for failures or malformed data. It also notes constraints like grid shape requirements and coordinate order, providing good context beyond basic functionality.
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 sections (Args, Returns, Raises, Example, Notes) and uses bullet points efficiently. It is appropriately sized for a complex tool with 3 parameters and no annotations, though some sections (like the detailed example) are lengthy but necessary for clarity. Every sentence adds value, such as explaining dependencies and constraints.
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 tool's complexity (3 parameters, no annotations, 0% schema coverage, but has an output schema), the description is highly complete. It covers input requirements, output format, error handling, examples, and technical notes. The output schema is described in detail, so the agent understands the return values without needing additional explanation. This provides all necessary context for correct tool invocation.
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?
Given the schema description coverage is 0%, the description compensates fully by detailing all three parameters (point_grid, breaks, options) with types, formats, examples, and optional fields. It explains that point_grid must be a GeoJSON FeatureCollection of Points in a grid, breaks is an array of breakpoints, and options includes properties like zProperty. This adds significant meaning beyond the minimal 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 tool's purpose: '从点网格生成等值带' (generate isobands from a point grid). It specifies the exact operation (generating filled isobands from a grid with z-values) and distinguishes it from sibling tools like 'interpolation_interpolate' or 'interpolation_isolines' by focusing on area representation rather than interpolation or isolines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through notes (e.g., '等值带用于可视化连续数据的范围' - isobands are for visualizing continuous data ranges) and technical constraints (e.g., point grid must be square/rectangular). However, it does not explicitly state when to use this tool versus alternatives like 'interpolation_isolines' or other interpolation tools, leaving the agent to infer based on the description of isobands as area representations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing what the tool does, including input requirements (JSON strings, specific GeoJSON formats, grid arrangement constraints), output format (GeoJSON FeatureCollection with LineString features), dependencies (Turf.js, Node.js), and error conditions (JavaScript execution failures, timeouts, data format errors). The only minor gap is it doesn't mention performance characteristics or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, it's appropriately sized for a complex tool with 3 parameters and no annotations. Every section adds value, though some redundancy exists between the Args section and the Notes section regarding JSON string requirements.
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 tool's complexity (3 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is remarkably complete. It covers purpose, parameters, return values, error conditions, examples, and important constraints. The output schema existence means the description doesn't need to exhaustively document return values, and it provides exactly the right level of contextual information for effective tool use.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. Each parameter (point_grid, breaks, options) gets detailed explanations including types, formats, examples, and optional fields. The description adds significant value beyond the bare schema, explaining JSON string requirements, GeoJSON structure, coordinate systems, and configuration options.
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 with a specific verb ('生成等值线' - generate isolines) and resource ('从点网格' - from a point grid). It distinguishes itself from sibling tools like 'interpolation_interpolate' or 'interpolation_isobands' by focusing specifically on creating line representations of continuous values from point grids, not other interpolation methods.
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 this tool (for creating continuous value line representations from point grids) but doesn't explicitly state when NOT to use it or name alternatives. It mentions the tool is for '等值线用于可视化连续数据的等值边界' (isolines for visualizing continuous data boundaries), which provides some context, but lacks explicit comparison with other interpolation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behavioral traits: it specifies input data formats (JSON strings, GeoJSON features), coordinate system (WGS84), triangle requirements (three vertices, closed loop), dependency on Turf.js and Node.js, and error conditions (JavaScript failures, timeouts, data format errors). It does not mention performance or rate limits, but covers essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Args, Returns, Raises, Example, Notes), front-loading the purpose. It is appropriately sized but includes some redundancy (e.g., repeating JSON string format in multiple sections). Most sentences earn their place by providing critical information, though it could be slightly more streamlined.
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 complexity (interpolation with specific geometric constraints), no annotations, and an output schema exists (implied by Returns section), the description is complete enough. It covers input requirements, output format, errors, examples, and environmental dependencies, providing all necessary context for an agent to use the tool correctly without needing additional structured data.
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%, so the description must compensate fully. It adds detailed meaning beyond the basic schema: it explains that 'point' and 'triangle' are JSON strings in GeoJSON format, provides examples, specifies geometry types (Point for point, Polygon for triangle), notes coordinate order [longitude, latitude], and describes triangle properties ('a', 'b', 'c' as z-values). This comprehensively documents both parameters.
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 verb ('计算' - calculate) and resource ('点在三角形平面上的z值' - z-value of a point on a triangle plane). It distinguishes from siblings by focusing on interpolation within a triangle plane rather than other geometric operations like boolean checks, measurements, or transformations listed in the sibling tools.
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 through the example and notes (e.g., for interpolation on a triangle plane with specific data formats), but does not explicitly state when to use this tool versus alternatives like 'interpolation_interpolate' or 'interpolation_tin' from the sibling list. It provides context on data requirements but lacks direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well by disclosing key behaviors: distance truncation at endpoints for out-of-range values, automatic handling of negative distances, JSON format requirements, coordinate order, and dependency on Turf.js/Node.js. It also notes error conditions, adding valuable context beyond basic functionality.
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 clear sections (Args, Returns, Raises, Example, Notes), but is somewhat lengthy due to detailed parameter explanations. Every sentence adds value, though it could be more front-loaded; the core purpose is stated upfront, but technical details dominate.
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 tool with 3 parameters, 0% schema coverage, no annotations, and an output schema, the description is highly complete. It covers purpose, parameters, return format, error handling, examples, and behavioral notes, providing all necessary context for effective use despite the lack of structured metadata.
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?
Given 0% schema description coverage, the description fully compensates by detailing all three parameters: 'line' (format, coordinate system, example), 'distance' (range, truncation behavior, example), and 'options' (optional fields, default units, valid values, example). It adds essential meaning not present in the bare 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 tool's purpose with specific verbs ('计算', '找到') and resources ('点位置', '坐标点位置'), and distinguishes it from siblings by focusing on distance-based point calculation along a line, unlike other measurement tools like 'measurement_distance' or 'measurement_length'.
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 calculating points at specified distances along lines, but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'misc_nearest_point_on_line' or 'measurement_midpoint'). It provides context on input requirements but no comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing what the tool does (calculates area), the return format (JSON with value and units), error conditions (JavaScript execution failures, timeouts, input format errors), dependencies (Turf.js and Node.js), and supported geometry types (Polygon and MultiPolygon). The only minor gap is it doesn't mention performance characteristics or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded with the core purpose. While comprehensive, some sections like the detailed coordinate specification and dependencies could be slightly more concise. Overall, most sentences earn their place by adding valuable information beyond basic functionality.
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 tool's complexity (geospatial calculation with specific format requirements), no annotations, 0% schema coverage, but with an output schema (implied by Returns section), the description is remarkably complete. It covers input format, coordinate system, return format, error conditions, examples, dependencies, and supported geometry types. The agent has all necessary context to use this tool correctly without needing additional documentation.
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 has 0% description coverage (just 'type': 'string'), so the description must fully compensate. It provides extensive parameter semantics: the 'polygon' parameter must be a JSON string in GeoJSON Polygon format, using WGS84 coordinates with longitude-first ordering, and includes a complete example. This goes far beyond what the schema provides and gives the agent everything needed to construct valid input.
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 with a specific verb ('计算' meaning 'calculate') and resource ('多边形区域的面积' meaning 'area of a polygon region'). It distinguishes itself from sibling tools like 'measurement_length' or 'measurement_distance' by focusing specifically on area calculation for polygons, not linear measurements or other geometric properties.
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 specifying it calculates polygon area, but doesn't explicitly state when to use this tool versus alternatives like 'measurement_square' or other measurement tools. It provides technical constraints (e.g., GeoJSON format, WGS84 coordinate system) which give some context, but lacks explicit guidance on scenarios where this tool is preferred over others or when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing: the tool uses Turf.js bearing method, requires valid JSON strings, uses WGS84 coordinate system with longitude-first order, measures bearing clockwise from north, returns JSON with value and units, raises exceptions for execution failures/timeouts/format errors, and depends on Node.js environment. This covers most behavioral aspects beyond basic functionality.
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?
Well-structured with clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. Some technical details in the Notes section could be more integrated, but overall the information is efficiently organized with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, 0% schema coverage, but with output schema present, the description provides complete coverage: clear purpose, detailed parameter specifications, return format documentation, error conditions, examples, and implementation dependencies. The output schema handles return structure, allowing the description to focus on semantics and usage.
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?
With 0% schema description coverage (schema only shows point1/point2 as strings), the description fully compensates by providing comprehensive parameter documentation: exact JSON format requirements, GeoJSON Point specification, coordinate system (WGS84), coordinate order (longitude, latitude), and concrete examples for both parameters. This adds substantial meaning beyond the bare 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 verb '计算' (calculate) and resource '两点之间的地理方位角' (geographic bearing between two points). It distinguishes from siblings by focusing on bearing calculation specifically, unlike other measurement tools like measurement_distance or measurement_rhumbBearing which have different purposes.
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 through the technical specifications (GeoJSON format, WGS84 coordinates) but doesn't explicitly state when to use this tool versus alternatives like measurement_rhumbBearing or unit_conversion_bearingToAzimuth. It provides necessary context for correct usage 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It effectively discloses key behavioral traits: the tool uses Turf.js library and Node.js environment, requires valid JSON strings as input, uses WGS84 coordinate system with longitude-first ordering, and raises exceptions for execution failures, timeouts, or malformed data. It also explains what the tool calculates ('质心是基于几何形状的质量分布计算的中心点').
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. While comprehensive, some sections like the detailed example could be slightly more concise, but overall the information earns its place given the technical nature of the tool.
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 tool's complexity (geospatial calculation), lack of annotations, and 0% schema coverage, the description provides excellent completeness. It covers purpose, parameters, return format, error conditions, examples, and technical dependencies. The existence of an output schema reduces the need to explain return values in detail, which the description handles appropriately.
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?
With 0% schema description coverage, the description fully compensates by providing rich parameter semantics. It clearly explains both parameters: 'geojson' as a JSON string with format requirements, coordinate system, and examples; 'options' as an optional JSON string with specific fields and examples. The description adds significant value beyond the bare 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 ('计算质心' - calculate center of mass) on a specific resource ('GeoJSON 对象' - GeoJSON object). It explicitly mentions using the Turf.js library's centerOfMass method, which distinguishes it from other measurement tools like 'measurement_center' or 'measurement_centroid' in the sibling list.
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 through the function's purpose (calculating center of mass for GeoJSON objects) but doesn't explicitly state when to use this tool versus alternatives like 'measurement_center' or 'measurement_centroid'. It provides technical context about coordinate systems and dependencies, but lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers substantial behavioral information. It discloses: coordinate system requirements (WGS84 with longitude-first), input format constraints (valid JSON strings), dependency on Turf.js and Node.js, error conditions (JavaScript execution failures, timeouts, malformed data), and return format details. The only gap is lack of performance/rate limit information.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. While comprehensive, some sections could be more concise - the example includes unnecessary Python import statements and the Notes section repeats coordinate information already stated in Args. Overall, most content earns its place.
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 tool's complexity (geometric calculation with specific coordinate system requirements), no annotations, and 0% schema coverage, the description provides excellent completeness. It covers purpose, parameters, return format, error conditions, examples, dependencies, and technical constraints. The presence of an output schema reduces need for return value explanation, which the description appropriately supplements rather than duplicates.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It details both parameters: 'geojson' (type, format, coordinate system, examples) and 'options' (type, optional fields, examples). The description adds significant value beyond the bare schema, explaining JSON string requirements, coordinate ordering, and property passing mechanisms.
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: '计算几何对象的中心点' (calculates the centroid of a geometric object). It specifies the exact method ('通过平均所有顶点坐标确定中心位置' - determines center position by averaging all vertex coordinates) and distinguishes it from sibling tools like 'measurement_center' and 'measurement_centerOfMass' by focusing specifically on geometric centroid calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through parameter details and examples, but doesn't explicitly state when to use this tool versus alternatives like 'measurement_center' or 'measurement_centerOfMass'. It provides technical prerequisites (valid JSON strings, WGS84 coordinate system) but lacks explicit guidance on tool selection scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it specifies the coordinate system (WGS84), input format requirements (valid JSON strings), angle measurement convention (clockwise from north), dependencies (Turf.js and Node.js), and error conditions (exceptions for execution failure, timeout, or bad input). However, it doesn't mention performance characteristics or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. While comprehensive, it could be more concise by reducing some redundancy in parameter explanations, but every sentence adds value.
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 tool with 4 parameters, 0% schema coverage, no annotations, but with output schema (implied by Returns section), the description is complete: it covers purpose, all parameters, return format, error conditions, examples, and implementation notes. The output schema in the Returns section eliminates need to explain return values separately.
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?
Given 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation: detailed type information, format specifications, value ranges, examples, and optional field explanations for all 4 parameters. It adds significant meaning beyond what the bare schema provides.
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 ('从起点计算指定距离和方位角的目标点' - calculate a destination point from a starting point given distance and bearing), identifies the resource (GeoJSON Point), and distinguishes it from siblings by focusing on destination calculation rather than other geometric operations like measurement_bearing or measurement_distance.
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 through parameter explanations and examples, but does not explicitly state when to use this tool versus alternatives like measurement_rhumbDestination or other sibling tools. It provides context for the calculation but lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool returns a GeoJSON LineString or MultiLineString, depends on Turf.js and Node.js, handles date line crossings, and raises exceptions for failures or invalid input. However, it does not mention performance characteristics like execution time or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. It is appropriately sized for a tool with three parameters and complex behavior, though some redundancy exists (e.g., repeating JSON string format in multiple places).
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?
The description is highly complete for a tool with no annotations, 0% schema coverage, and an output schema. It covers purpose, parameters, return values, error handling, examples, dependencies, and edge cases (e.g., date line crossings). The presence of an output schema reduces the need to explain return formats in detail, but the description still provides useful context.
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?
Given 0% schema description coverage, the description compensates fully by providing detailed parameter semantics. It specifies the format, type, coordinate system, examples, and optional fields for all three parameters (start, end, options), including default values and valid JSON requirements. This adds significant value beyond the minimal input 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 tool's purpose: '计算两点之间的大圆路径' (calculates the great circle path between two points). It specifies the exact operation (great circle calculation) and resource (GeoJSON points), distinguishing it from sibling tools like measurement_distance (which calculates straight-line distance) or measurement_bearing (which calculates direction).
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 through the function's purpose and parameter details, but does not explicitly state when to use this tool versus alternatives. It mentions that the result may be a MultiLineString when crossing the date line, which provides some context, but lacks explicit guidance on when to choose this over other measurement tools like measurement_distance or measurement_rhumbDistance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it returns a JSON string with value and units, raises exceptions for failures/timeouts/input errors, depends on Turf.js and Node.js, and calculates spherical lengths. It could improve by mentioning performance or rate limits, but covers essential operational aspects.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. It's appropriately sized but could be slightly more concise by integrating some Notes into Args or reducing repetition in examples. Every sentence adds value, though minor trimming is possible.
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 tool's moderate complexity (2 parameters, no annotations, but with output schema), the description is highly complete. It covers purpose, parameters, return format, errors, dependencies, and examples. The output schema exists, so the description correctly doesn't re-explain return values, focusing instead on usage context and input details.
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%, so the description must compensate fully. It provides detailed semantics for both parameters: 'geojson' is explained with type, format, coordinate system, and an example; 'options' is detailed with type, optional fields, valid units, default, and an example. This adds significant value beyond the bare 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 ('计算线或多线的长度' - calculates length of lines or multilines) and resource ('线或多线几何图形' - line or multiline geometries). It distinguishes from sibling tools like 'measurement_distance' (which measures distance between points) and 'measurement_area' (which calculates area), establishing a unique purpose within the measurement category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it calculates '实际长度, 考虑地球曲率' (actual length, considering Earth's curvature), suggesting it's for geospatial applications. However, it lacks explicit guidance on when to use this tool versus alternatives like 'unit_conversion_convertLength' (which converts length units) or 'measurement_distance' (which measures point-to-point distance), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses the tool's dependencies (Turf.js, Node.js), computational method (spherical midpoint), error conditions (JavaScript execution failures, timeouts, malformed data), and output format. It doesn't mention performance characteristics or rate limits, but covers essential behavioral aspects.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some sections could be more concise (e.g., the example includes full import and execution code). Overall, most sentences earn their place by providing essential information.
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 tool's moderate complexity, no annotations, 0% schema coverage, but presence of an output schema, the description is complete. It covers purpose, parameters, return values, errors, dependencies, and provides a working example. The output schema existence means the description doesn't need to fully document return format, though it helpfully does.
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?
With 0% schema description coverage (schema only shows string types), the description fully compensates by providing detailed parameter semantics. It specifies the exact GeoJSON format, coordinate system, coordinate order, and provides concrete examples for both point1 and point2 parameters, adding significant value beyond the minimal 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 tool's purpose with a specific verb ('计算' - calculate) and resource ('两点之间的中点' - midpoint between two points). It distinguishes from siblings by focusing on midpoint calculation rather than other geometric operations like distance, bearing, or clustering.
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 through the example and notes about input requirements (valid JSON strings, coordinate order, WGS84 system), but doesn't explicitly state when to use this tool versus alternatives like 'measurement_center' or 'measurement_centroid'. It provides technical prerequisites but not comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it specifies the underlying library (Turf.js), coordinate system (WGS84), input format requirements (valid JSON string), output format, error conditions (JavaScript execution failures, timeouts, data format errors), and dependencies (Node.js environment). It doesn't mention performance characteristics like computational complexity.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some sections like the detailed example could be slightly condensed, but overall it's efficient with minimal waste.
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 tool's complexity (geospatial computation), no annotations, and 0% schema coverage, the description is remarkably complete. It covers purpose, parameters, return values (though output schema exists, it elaborates), error conditions, examples, dependencies, and technical constraints. For a single-parameter tool with rich geospatial context, this provides all necessary information.
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?
With 0% schema description coverage (schema only says geojson is a string), the description fully compensates by providing rich parameter semantics: it specifies the parameter must be a JSON string in GeoJSON format, provides the coordinate system (WGS84 with longitude first), gives a detailed example, and explains format requirements. This adds substantial value beyond the bare 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 tool's purpose with a specific verb ('找到最近的点' - find the nearest point) and resource ('在 GeoJSON 特征上' - on GeoJSON features). It distinguishes from siblings by specifying it finds the nearest point on a feature, unlike classification_nearestPoint which finds nearest points between features or misc_nearest_point_on_line which is line-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the example and notes (e.g., '输入参数 geojson 必须是有效的 JSON 字符串'), but doesn't explicitly state when to use this tool versus alternatives like classification_nearestPoint or misc_nearest_point_on_line. The context is clear but lacks explicit comparison guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses the underlying library (Turf.js), computational method (shortest spherical distance), dependencies (Node.js environment), error conditions (JavaScript execution failure, timeout, input format errors), and return format. It doesn't mention performance characteristics or rate limits, but covers key behavioral aspects.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. It's appropriately sized for a 3-parameter tool with complex requirements, though some redundancy exists (e.g., repeating coordinate order in multiple places).
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 tool's complexity (geospatial calculation with specific input/output formats), no annotations, and an output schema present, the description is highly complete: it covers purpose, parameters, return values, errors, examples, and implementation details. The output schema handles return structure, so the description appropriately focuses on usage context.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics: it explains each parameter's type, format, coordinate system, examples, and for options, lists valid values for units and method with defaults. This adds substantial value beyond the bare 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 verb '计算' (calculate) and resource '点到线的最短距离' (shortest distance from point to line). It distinguishes from siblings by specifying it's for point-to-line distance calculation, unlike other measurement tools like measurement_distance (general distance) or measurement_pointOnFeature (finds point on feature).
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 through the example and notes (e.g., coordinates must be WGS84, JSON strings required), but doesn't explicitly state when to use this tool versus alternatives like measurement_distance or misc_nearest_point_on_line. It provides context about input formats but lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses the Turf.js/Node.js dependency, coordinate system (WGS84), input format requirements (valid JSON strings), error conditions (JavaScript execution failures, timeouts, format errors), and return format. It doesn't mention performance characteristics or rate limits, but covers most behavioral aspects.
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?
Well-structured with clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. Some technical details in the Notes section could be more concise, but overall information density is high with minimal waste.
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 4-parameter tool with no annotations and 0% schema coverage, the description provides complete context: clear purpose, detailed parameter semantics, return format (though output schema exists), error conditions, examples, and important technical notes about dependencies and coordinate systems. Nothing essential appears missing.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation: origin (format, coordinate system, examples), distance (type, description), bearing (type, description, range), and options (structure, valid values, defaults). Each parameter gets clear semantic meaning beyond just type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('计算目标点' - calculate destination point) using a specific method ('沿恒向线' - along rhumb line) with the Turf.js library. It distinguishes itself from sibling tools like 'measurement_destination' (which likely uses great circle) by specifying the rhumb line method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through technical details (rhumb line vs great circle, Turf.js dependency) but doesn't explicitly state when to choose this tool over alternatives like 'measurement_destination'. It mentions the method but not comparative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it explains the tool creates a GeoJSON LineString, specifies coordinate system (WGS84), mentions dependencies (Turf.js, Node.js), and documents error conditions (Raises section). However, it doesn't mention performance characteristics like execution time or resource usage.
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?
Well-structured with clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. Some redundancy exists (e.g., coordinate order mentioned multiple times), but overall efficient for a complex tool with many parameters.
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 tool's complexity (5 parameters, geometric operations) and the presence of an output schema, the description is complete: it explains what the tool does, documents all parameters thoroughly, shows return format, provides examples, and notes dependencies. The output schema handles return value documentation, so the description focuses appropriately on usage context.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation: detailed descriptions of all 5 parameters including types, formats, examples, coordinate systems, and optional fields with defaults. The Args section adds significant value beyond the bare 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 tool's purpose: '创建圆弧线段' (create arc line segment) with specific details about using a center point, radius, and bearing angles. It distinguishes itself from siblings like 'misc_sector' (which might create filled areas) and other line tools by focusing specifically on arc creation with geometric parameters.
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 through parameter explanations (e.g., '以给定点为中心，创建指定半径和方位角范围的圆弧线段'), but doesn't explicitly state when to use this tool versus alternatives like 'misc_sector' or other geometric creation tools. It provides technical context but lacks explicit comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it returns a GeoJSON FeatureCollection of LineString features, handles edge cases (returns original line if shorter than segment length), specifies coordinate order and coordinate reference system (WGS84), and mentions dependencies and error conditions (JavaScript execution failures, timeouts, input format errors). It does not cover rate limits or authentication needs, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises, Example, Notes), front-loading the core purpose. It is appropriately sized for a tool with three parameters and complex behavior, though some sections (like the detailed example) are lengthy but necessary for clarity. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (geospatial processing with multiple parameters), no annotations, and an output schema (implied by Returns section), the description is highly complete. It covers input requirements, output format, error handling, examples, dependencies, and edge cases, providing all necessary context for an AI agent to invoke the tool correctly without relying on external documentation.
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%, so the description must fully compensate. It provides detailed semantics for all three parameters: geojson (type, format, coordinate system, examples), segment_length (type, description, example), and options (type, optional fields with defaults and valid values, example). This adds significant value beyond the bare schema, fully documenting parameter usage 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 the tool's purpose with specific verbs ('分割' meaning 'split' or 'divide') and resources ('线或多线几何图形' meaning 'line or multi-line geometry'), distinguishing it from siblings like misc_line_split (which likely splits at points) or misc_line_slice (which slices between points). It explicitly mentions segmenting into specified lengths for processing and analysis.
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 specifying it handles LineString or MultiLineString geometries, but does not explicitly state when to use this tool versus alternatives like misc_line_split or misc_line_slice. It provides context on input formats and dependencies (Turf.js, Node.js), but lacks explicit guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it specifies the return format (GeoJSON FeatureCollection), error conditions (JavaScript execution failures, timeouts, input format errors), dependencies (Turf.js, Node.js), and coordinate system (WGS84). However, it lacks details on performance or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and is appropriately sized for a complex tool. However, some redundancy exists (e.g., repeating coordinate system info), and the example could be more concise, slightly reducing efficiency.
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 tool with no annotations, 0% schema coverage, but an output schema, the description is highly complete: it covers purpose, parameters, return values, errors, examples, and notes on dependencies and constraints. The output schema handles return structure, so the description focuses on semantic context, leaving no significant gaps.
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?
Given 0% schema description coverage, the description fully compensates by providing detailed semantics for all three parameters: it explains data types, formats (GeoJSON with specific geometry types), coordinate systems, examples, and optional configurations for 'options', including the 'tolerance' field. This adds significant value beyond the minimal input 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 tool's purpose with specific verbs ('查找', '计算') and resources ('两条线的重叠部分', '重叠线段'), distinguishing it from siblings like 'misc_line_intersect' or 'booleans_booleanOverlap' by focusing on geometric overlap calculation rather than intersection detection or boolean checks.
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?
Usage is implied through the description of what the tool does (e.g., '计算两条线几何图形之间的重叠线段'), but there is no explicit guidance on when to use this tool versus alternatives like 'misc_line_intersect' or 'booleans_booleanOverlap', nor are any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool decomposes geometries into independent line segments, returns a GeoJSON FeatureCollection of LineString features, raises exceptions for execution failures or input errors, and depends on Turf.js and Node.js. It covers output format, error conditions, and dependencies, though it lacks details on performance or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. It is appropriately sized for a tool with one parameter and detailed requirements, though the example and notes could be slightly condensed. Every sentence adds value, with no redundant information.
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 tool's complexity (geometric decomposition), no annotations, 0% schema coverage, and the presence of an output schema, the description is highly complete. It covers purpose, input details, output format, error handling, dependencies, and provides an example. The output schema handles return values, so the description appropriately focuses on behavioral context and parameter semantics.
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 schema description coverage is 0%, so the description must fully compensate. It provides comprehensive semantics for the single parameter 'geojson': type (JSON string), supported formats (LineString, MultiLineString, Polygon, MultiPolygon), coordinate system (WGS84 with longitude first), and an example. This adds significant value beyond the basic schema, which only indicates it's a required string.
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: '将几何图形分解为线段' (decompose geometric shapes into line segments). It specifies the input (GeoJSON objects) and output (independent line segments with two vertex coordinates each), distinguishing it from siblings like 'feature_conversion_explode' or 'feature_conversion_polygon_to_line' by focusing on segment-level decomposition rather than feature conversion.
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 through the Args section, which lists supported GeoJSON types (LineString, MultiLineString, Polygon, MultiPolygon) and coordinate system (WGS84). However, it does not explicitly state when to use this tool versus alternatives like 'misc_line_slice' or 'feature_conversion_polygon_to_line', nor does it provide exclusions or prerequisites beyond input format requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses behavioral traits such as input validation requirements (valid JSON strings, WGS84 coordinate order), output format (GeoJSON LineString feature), error conditions (raises Exception on failures), and dependencies (Turf.js and Node.js). However, it does not mention performance aspects like rate limits or computational complexity.
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 sections for Args, Returns, Raises, Example, and Notes, making it easy to navigate. It is appropriately sized but includes some redundancy (e.g., repeating JSON format details). Most sentences earn their place, though minor trimming could improve conciseness.
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 tool's moderate complexity (4 parameters, geometric operations), no annotations, and an output schema present, the description is complete. It covers purpose, detailed parameter semantics, output format, error handling, examples, and dependencies, providing all necessary context for an AI agent to use the tool effectively.
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?
Given 0% schema description coverage, the description fully compensates by providing detailed semantics for all 4 parameters: 'line' (GeoJSON format, coordinate system, example), 'start_distance' and 'stop_distance' (definitions, examples), and 'options' (optional JSON with units field and valid values). This adds significant value beyond the bare 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 tool's purpose with specific verbs ('截取' meaning 'slice/extract') and resources ('线段' meaning 'line segment'), specifying it extracts a portion along a line segment based on distance ranges. It distinguishes itself from siblings like 'misc_line_slice' (which might slice based on points) and 'misc_line_segment' (which might create segments differently), making the purpose explicit and 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 implies usage by stating it's for '按长度分割线段' (splitting line segments by length), but does not explicitly say when to use this tool versus alternatives like 'misc_line_slice' or 'misc_line_segment'. It provides context about input formats and dependencies, but lacks explicit guidance on tool selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it creates a GeoJSON Polygon, specifies coordinate systems (WGS84), details error conditions (raises exceptions for failures), and notes dependencies. However, it does not mention performance aspects like rate limits or computational complexity.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. However, it is moderately verbose due to detailed parameter explanations, which are necessary given the 0% schema coverage. Some redundancy exists (e.g., repeating coordinate order in multiple places), but overall it earns its length.
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 tool's complexity (5 parameters, geometric operations) and the presence of an output schema (specified in Returns), the description is highly complete. It covers input semantics, output format, error handling, dependencies, and usage examples. The output schema details reduce the need for return value explanations, making the description adequately comprehensive.
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 schema description coverage is 0%, so the description must fully compensate. It provides comprehensive semantic details for all parameters: center (GeoJSON format, coordinate order), radius (units implied via options), bearing1/bearing2 (measurement from north), and options (units, steps, properties). Examples and format specifications add significant value beyond the basic 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 tool's purpose with specific verbs ('创建扇形多边形区域') and resources ('以给定点为中心，创建指定半径和方位角范围的扇形多边形区域'). It distinguishes itself from sibling tools by focusing on sector polygon creation, unlike other geometric operations in the list such as buffers, circles, or transformations.
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 through parameter explanations and examples, but does not explicitly state when to use this tool versus alternatives. It mentions dependencies (Turf.js, Node.js) which provides some context, but lacks direct guidance on scenarios or comparisons with sibling tools like 'transformation_circle' or 'misc_line_arc'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it describes the transformation behavior (eliminates self-intersections, returns multiple polygons), technical dependencies (Turf.js, Node.js), error conditions (JavaScript execution failures, timeouts, format errors), and output format details. However, it doesn't mention performance characteristics like execution time or resource usage.
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 clear sections (purpose, Args, Returns, Raises, Example, Notes) and front-loaded with the core functionality. While comprehensive, some sections could be more concise (e.g., the example is quite detailed). Every sentence adds value, but there's minor redundancy in format specifications.
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 tool's complexity (geometric processing with dependencies), 0% schema coverage, no annotations, but with output schema provided, the description is remarkably complete. It covers purpose, parameters, returns, errors, examples, dependencies, and technical constraints. The output schema handles return structure, so the description appropriately focuses on behavioral context.
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?
With 0% schema description coverage (schema only says 'polygon' is a string), the description fully compensates by providing rich parameter semantics: it explains the parameter must be a JSON string in GeoJSON Polygon format with WGS84 coordinates, provides a detailed example, and specifies coordinate order. This adds substantial value beyond the minimal 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 tool's purpose with specific verbs ('消除' meaning 'eliminate') and resources ('多边形中的自相交部分' meaning 'self-intersecting parts of polygons'), distinguishing it from siblings like 'misc_kinks' (which likely detects but doesn't fix kinks) and polygon transformation tools. It explicitly describes the core functionality of detecting and removing self-intersections to return clean polygon collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through technical specifications (GeoJSON format, WGS84 coordinate system) and notes about dependencies (Turf.js, Node.js), but doesn't explicitly state when to use this tool versus alternatives like 'misc_kinks' or polygon cleaning tools. It provides necessary constraints but lacks comparative guidance with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing: coordinate system (WGS84 with [lng, lat] order), default behavior (global bounding box if unspecified), dependencies (Turf.js and Node.js), error conditions (JavaScript execution failures, timeouts, input format errors), and return format details. It doesn't mention performance characteristics like rate limits or computational cost.
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?
Well-structured with clear sections (Args, Returns, Raises, Example, Notes), but somewhat verbose. The Python example and detailed JSON format specifications could be simplified. Most sentences earn their place by providing necessary information, though some redundancy exists in the Returns section.
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 tool's moderate complexity (2 parameters, no annotations, but has output schema), the description is highly complete. It covers purpose, parameters, return format, errors, examples, and implementation notes. The output schema exists, so the description appropriately focuses on explaining the GeoJSON format rather than just restating it.
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%, so the description must fully compensate. It provides comprehensive parameter documentation: 'count' with type, default, and example; 'options' with type details, optional fields (bbox with format and default), and JSON string requirement. The description adds significant value beyond the minimal input 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 tool's purpose with specific verb ('生成随机点特征集合' - generate random point feature collection) and resource ('在指定边界框内' - within specified bounding box). It distinguishes from siblings like random_randomLineString and random_randomPolygon by specifying it generates points, not lines or polygons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through parameter explanations (e.g., '如果未指定边界框，默认在全球范围内生成随机点' - if no bounding box specified, defaults to global range), but doesn't explicitly state when to use this tool versus alternatives like random_randomPosition or grid_pointGrid. No explicit when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: it returns GeoJSON FeatureCollection, uses WGS84 coordinates, auto-closes polygons, has a global default bbox, and depends on Turf.js/Node.js. It also mentions error conditions (JavaScript failures, timeouts, input errors). However, it does not cover rate limits or authentication needs, though these may not apply.
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 sections (Args, Returns, Raises, Example, Notes), making it easy to navigate. It is appropriately sized but could be more front-loaded; the core purpose is stated first, but some details are buried in notes. Most sentences earn their place, though the example is lengthy.
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 tool's complexity (generating random polygons with configurable parameters), no annotations, 0% schema coverage, and an output schema provided, the description is highly complete. It covers purpose, parameters, return format, errors, examples, and notes on dependencies and defaults, leaving no significant gaps for the agent.
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%, so the description must compensate. It fully documents both parameters: 'count' with type, default, and example, and 'options' with type, optional fields (bbox, num_vertices, max_radial_length), defaults, examples, and validation rules (must be valid JSON or None). This adds significant meaning beyond the basic 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 tool's purpose: '生成随机多边形特征集合' (generate random polygon feature collection). It specifies the verb ('生成' - generate) and resource ('随机多边形特征集合' - random polygon feature collection), and distinguishes it from sibling tools like random_randomPoint or random_randomLineString by focusing on polygons.
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 detailing parameters like count and options, but does not explicitly state when to use this tool versus alternatives. It mentions dependencies (Turf.js, Node.js) and coordinate system (WGS84), which provide some context, but lacks explicit guidance on scenarios or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: the tool smooths line paths, depends on Turf.js and Node.js, raises exceptions for execution failures or input errors, and returns a GeoJSON LineString. It also notes coordinate order and JSON string requirements, though it lacks details on performance or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. However, it includes some redundancy (e.g., repeating JSON format details) and could be more concise by eliminating minor repetitions while maintaining clarity.
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 tool's complexity (geometric transformation with two parameters), no annotations, and an output schema present, the description is highly complete. It covers input requirements, parameter semantics, return format, error handling, dependencies, and provides a practical example, leaving no significant gaps for the agent.
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 schema description coverage is 0%, so the description must fully compensate. It provides comprehensive parameter details: 'line' requires a GeoJSON LineString in WGS84 with longitude-first coordinates, and 'options' includes resolution and sharpness fields with defaults and examples. This adds significant meaning beyond the basic schema types.
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: '将直线转换为平滑的贝塞尔曲线' (convert straight lines to smooth Bézier curves). It specifies the exact transformation (line to curve) and distinguishes itself from sibling tools like transformation_simplify or transformation_buffer, which perform different geometric operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the example and notes (e.g., input must be valid JSON, coordinate order is WGS84). However, it does not explicitly state when to use this tool versus alternatives like transformation_simplify or interpolation tools, nor does it mention prerequisites or exclusions beyond format requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing: the tool generates a circular polygon, depends on Turf.js and Node.js, raises exceptions for execution failures/timeouts/input errors, and returns a GeoJSON Polygon feature. It covers behavioral aspects like coordinate system (WGS84), input format requirements (valid JSON strings), and output format details. No contradictions with annotations since none exist.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. While comprehensive, some details in the Notes section (e.g., dependency on Turf.js/Node.js) could be integrated more tightly. Overall efficient with minimal waste, though slightly verbose in parameter examples.
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 tool's moderate complexity (3 parameters, geometric operations), no annotations, and an output schema exists (though not detailed in context), the description provides excellent completeness. It covers purpose, detailed parameter semantics, return format with examples, error conditions, usage notes, and dependencies. This fully compensates for the lack of annotations and schema descriptions.
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%, so the description must fully compensate. It provides extensive parameter details beyond the basic schema: center requires GeoJSON Point or coordinate array with format examples and coordinate order; radius is a float value; options includes optional fields (steps, units with valid values, properties) with defaults and examples. This adds significant semantic meaning not present 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 tool's purpose as '根据中心点和半径创建圆形区域' (create a circular area based on center point and radius), which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'transformation_buffer' or 'transformation_convex' by focusing specifically on circular polygon generation with geometric parameters.
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 through parameter explanations (e.g., '可以控制圆形的平滑度和单位' - can control circle smoothness and units) but doesn't explicitly state when to use this tool versus alternatives like 'transformation_buffer' for buffering operations or 'grid_hexGrid' for grid generation. No explicit when-not-to-use guidance or named alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds significant behavioral context: it discloses that the tool returns null if concave hull cannot be computed, depends on Turf.js and Node.js, raises exceptions on failures, and notes internal use of turf-tin. This goes beyond basic functionality, though it could mention performance or limitations more explicitly.
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 sections (Args, Returns, Raises, Example, Notes), front-loading the purpose. It is appropriately sized but could be slightly more concise by reducing redundancy in examples or notes, though every sentence adds value for clarity and usability.
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 tool's complexity (geometric computation), no annotations, and an output schema present, the description is highly complete: it covers purpose, parameters, return values, errors, examples, and dependencies. The output schema handles return format, so the description focuses on behavioral and usage aspects, leaving no significant gaps.
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%, so the description compensates fully by detailing both parameters: 'points' as a GeoJSON FeatureCollection string with format, coordinate system, and examples, and 'options' as a JSON string with fields like maxEdge and units, including valid values and defaults. This adds comprehensive meaning beyond the bare 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 tool's purpose: '计算点集的凹包' (computes concave hull of point sets) and specifies it uses Turf.js's concave method. It distinguishes from sibling tools like 'transformation_convex' by focusing on concave hulls, making the verb+resource specific and 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 implies usage for generating concave hulls from point sets but does not explicitly state when to use this tool versus alternatives like 'transformation_convex' or other geometric tools. It provides context on input requirements but lacks explicit guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it uses Turf.js and Node.js, specifies input/output formats (GeoJSON strings), coordinate system (WGS84), and error conditions (exceptions for execution failures, timeouts, or bad data). However, it does not mention performance aspects like computational complexity or limitations on point count.
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 sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. It is appropriately sized but includes some redundancy (e.g., repeating coordinate order in multiple sections), slightly reducing efficiency.
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 complexity (geometric computation), no annotations, and an output schema exists, the description is complete. It covers purpose, input details, output format, errors, examples, and dependencies, providing sufficient context for an agent to invoke the tool correctly without needing the output schema explained.
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%, so the description must fully compensate. It provides detailed semantics for the single parameter 'points': type (JSON string), format (GeoJSON FeatureCollection with Points), coordinate system (WGS84 with longitude-first), and an example. This adds substantial meaning beyond the bare 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 a clear, specific statement: '计算点集的凸包' (computes the convex hull of a point set). It explicitly names the resource (point set) and the verb (compute convex hull), and distinguishes from siblings by focusing on convex hull generation rather than other geometric transformations like 'transformation_concave' or 'transformation_union'.
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 through the definition of convex hull ('包含所有点的最小凸多边形') and notes on input format, but does not explicitly state when to use this tool versus alternatives like 'transformation_concave' for concave hulls or other geometric operations. It provides context but lacks explicit comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it returns a GeoJSON Feature or null if no intersection, specifies coordinate order and coordinate reference system (WGS84), mentions possible output geometry types (Polygon, MultiPolygon, etc.), and notes dependencies on Turf.js and Node.js. It also outlines error conditions (JavaScript execution failure, timeout, or invalid input). The only minor gap is lack of explicit rate limits or performance characteristics.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. However, it includes an extensive Python code example that may be overly detailed for an AI agent, slightly reducing conciseness. Most sentences earn their place by providing essential information.
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 tool's complexity (geometric intersection with specific data formats), no annotations, 0% schema coverage, but with an output schema present, the description is highly complete. It covers purpose, input requirements, output behavior, error conditions, dependencies, and provides examples. The output schema handles return value structure, so the description appropriately focuses on semantics and usage context.
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%, so the description must fully compensate. It provides comprehensive details for the single parameter 'featureCollection': type (string/JSON), format (GeoJSON FeatureCollection with two Polygon features), coordinate system (WGS84 with longitude-first), and a detailed example. This adds significant meaning beyond the bare schema, which only indicates it's a required string.
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: '计算多边形的交集' (calculates the intersection of polygons). It specifies the exact operation (intersection), the resource (polygons), and the implementation method (Turf.js intersect). This distinguishes it from sibling tools like transformation_difference or transformation_union, which perform different geometric operations.
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 through the Args and Notes sections, specifying that input must be a valid GeoJSON FeatureCollection with two polygons in WGS84 coordinates. However, it does not explicitly state when to use this tool versus alternatives like transformation_difference or transformation_union, nor does it provide exclusions or prerequisites beyond data format requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses behavioral traits: it specifies the underlying library (Turf.js lineOffset), dependencies (Node.js environment), error conditions (raises Exception on failure, timeout, or bad input), and operational details (negative distance for opposite direction, coordinate system WGS84). This covers key aspects like implementation, constraints, and failure modes, though it could mention performance or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. It is appropriately sized for a tool with 3 parameters and complex behavior. Some redundancy exists (e.g., repeating JSON string info), but overall it is efficient and easy to navigate.
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 tool's complexity (geometric operation with 3 parameters, no annotations, but has output schema), the description is highly complete. It covers purpose, parameters, return values (though output schema exists, it still explains format), errors, examples, and notes on dependencies and constraints. This provides all necessary context for an agent to use the tool correctly.
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%, so the description must compensate fully. It does so excellently: for each of the 3 parameters, it provides detailed semantics including types, formats, examples, valid values (for options.units), and constraints (e.g., line must be valid GeoJSON, distance can be negative). This adds substantial meaning beyond the bare schema, making parameters well-understood.
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 '计算线的偏移' (calculates line offset), which is a specific verb+resource statement. It clearly distinguishes this tool from siblings like 'transformation_buffer' (which creates buffers) or 'transformation_transformTranslate' (which translates geometries) by focusing on offsetting lines specifically. The purpose is immediately apparent and 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 implies usage through the example and notes (e.g., for offsetting lines with Turf.js), but does not explicitly state when to use this tool versus alternatives like 'transformation_buffer' or other geometric transformations. It provides technical context (e.g., coordinate order, JSON format) but lacks explicit guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it uses Turf.js and Node.js, specifies input/output formats (JSON strings, GeoJSON), coordinate system (WGS84), error conditions (JavaScript failures, timeouts, bad data), and notes coverage of the original polygon area. However, it lacks details on performance, rate limits, or side effects like memory usage.
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 sections (Args, Returns, Raises, Example, Notes), making it easy to scan. It is appropriately sized but includes some redundancy (e.g., repeating JSON format details). Most sentences add value, though it could be slightly more concise in the example and notes.
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 complexity (geometric operation with specific dependencies), no annotations, and an output schema exists, the description is complete. It covers purpose, input details, output format, errors, example, and technical notes (dependencies, coordinate system). The output schema handles return values, so no need to duplicate that in the description.
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%, so the description must compensate fully. It provides extensive semantic details for the single parameter 'polygon': type (string), format (JSON string, GeoJSON Polygon), coordinate system (WGS84), example, and validation notes (must be valid JSON). This goes well beyond the basic schema, ensuring the agent understands how to format the input 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 specific action ('将多边形分割为三角形' - tessellate polygons into triangles) and resource (GeoJSON Polygon). It distinguishes itself from siblings by focusing on tessellation, unlike other transformation tools like simplify, buffer, or union, which perform different geometric operations.
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 when tessellating polygons into triangles, but does not explicitly state when to use this tool versus alternatives (e.g., other transformation tools like triangulation or grid methods). It provides technical constraints (e.g., input format, coordinate system) but lacks comparative guidance with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers substantial behavioral information. It explains the coordinate system (WGS84, longitude-first), direction measurement convention (degrees clockwise from north), that negative distance reverses direction, the optional mutate parameter behavior, and dependencies on Turf.js/Node.js. It also documents error conditions (JavaScript execution failure, timeout, malformed input) and return format. The only missing behavioral aspects might be performance characteristics or specific edge cases.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some information could be more concise - the example includes full import/execution code that might be verbose. However, every section adds value, and the organization helps the agent quickly find needed information.
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 tool's complexity (geospatial transformation with multiple parameters), no annotations, and 0% schema coverage, the description provides exceptional completeness. It covers purpose, all parameters in detail, return values (even though an output schema exists), error conditions, dependencies, coordinate system conventions, and includes a working example. The Notes section adds crucial implementation details about JSON string requirements and measurement conventions.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. Each parameter (geojson, distance, direction, options) gets detailed explanations including types, formats, constraints, examples, and for options, all sub-parameters with their valid values and defaults. This goes far beyond what the bare schema provides and gives the agent complete understanding of how to use each parameter 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 starts with a clear, specific statement: '平移 GeoJSON 对象' (translate GeoJSON objects). It specifies the exact method used ('Turf.js 库的 transformTranslate 方法') and the movement type ('沿恒向线移动' - move along a rhumb line). This clearly distinguishes it from other transformation tools like transformRotate or transformScale in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through technical details (coordinate system, direction measurement, dependency on Turf.js/Node.js), but doesn't explicitly state when to use this tool versus alternatives. It doesn't provide comparative guidance against other transformation tools like transformRotate or buffer, nor does it mention prerequisites or typical use cases beyond the technical operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it specifies the return format as JSON string, mentions exception conditions (JavaScript execution failure, timeout, input format errors), and notes dependencies on Turf.js and Node.js environment. However, it doesn't mention performance characteristics like rate limits or whether the operation is stateless.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some sections like the detailed parameter documentation could be more concise, but overall it's appropriately sized for a tool with 3 parameters and no annotations.
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 tool's moderate complexity, 3 parameters with no schema descriptions, no annotations, and no output schema, the description provides complete context. It covers purpose, parameters, return format, error conditions, examples, and implementation dependencies, leaving no significant gaps for agent understanding.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation including types, descriptions, valid values with enums, and examples for all three parameters. It adds substantial meaning beyond the bare schema, making parameter usage clear and unambiguous.
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 as converting area values between units, with specific verb ('转换' meaning convert) and resource ('面积单位' meaning area units). It distinguishes itself from sibling tools like unit_conversion_convertLength by focusing specifically on area conversion, not length or other unit types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through parameter documentation and notes about valid unit identifiers, but doesn't explicitly state when to use this tool versus alternatives. It mentions sibling tools like unit_conversion_convertLength exist but provides no comparative guidance on choosing between area and length conversion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing: the conversion formula, dependencies on Turf.js and Node.js, return format details, and error conditions (JavaScript execution failures, timeouts, input format errors). It doesn't mention performance characteristics or rate limits, but provides substantial behavioral context beyond basic functionality.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded with the core purpose. Some sections like the Python example could be more concise for an MCP context, but overall the information density is high with minimal waste.
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 single-parameter mathematical conversion tool with no annotations and no output schema, the description provides excellent completeness: clear purpose, detailed parameter documentation, explicit return format specification, error conditions, usage examples, mathematical formula, and implementation dependencies. Nothing essential appears to be missing for this type of tool.
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?
With 0% schema description coverage (schema only shows 'degrees' as a number type), the description fully compensates by providing detailed parameter documentation: type (float), description, example value (180.0), and context about what the parameter represents. This adds significant value beyond the minimal schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('将角度转换为弧度' - convert degrees to radians) and resource (angle values). It distinguishes from sibling tools like 'unit_conversion_radiansToDegrees' by specifying the exact conversion direction. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the 'Notes' section ('常用于数学计算和三角函数' - commonly used in mathematical calculations and trigonometric functions), but doesn't explicitly state when to use this tool versus alternatives like 'unit_conversion_radiansToDegrees' or other unit conversion tools. No explicit when-not-to-use guidance or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a mutation tool (implied by '修正' and '调整'), specifies input/output formats (GeoJSON strings), notes dependencies (Turf.js and Node.js), and mentions error conditions (JavaScript execution failures, timeouts, data format errors). However, it lacks details on performance, rate limits, or authentication needs, which could be relevant 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. It starts with a clear purpose, but includes extensive sections (Args, Returns, Raises, Example, Notes) that, while informative, could be more streamlined. Some redundancy exists (e.g., coordinate order mentioned multiple times). Every sentence adds value, but the organization could be more front-loaded for quick scanning by an agent.
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 tool's complexity (mutation of geometric data), no annotations, and an output schema present, the description is highly complete. It covers purpose, usage context, parameter details, return values, error handling, examples, and technical notes (dependencies, coordinate systems). The output schema handles return structure, so the description need not duplicate that, allowing focus on behavioral and semantic aspects.
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%, so the description must fully compensate. It provides detailed semantics for both parameters: 'geojson' is explained with type, format, coordinate system, and an example; 'options' is described with type, optional fields ('reverse' and 'mutate'), defaults, and an example. This adds substantial value beyond the bare schema, covering all parameter aspects comprehensively.
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: '修正多边形的环方向，确保外环逆时针、内环顺时针' (corrects polygon ring orientation to ensure outer rings are counterclockwise and inner rings are clockwise). It specifies the exact operation (orientation correction) and target resource (polygons), and distinguishes from siblings like 'coordinate_mutation_flip' or 'coordinate_mutation_clean_coords' by focusing on ring orientation rather than coordinate transformation or cleaning.
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 ensuring polygon ring orientation complies with GIS standards for correct area calculations. However, it does not explicitly state when NOT to use it or name specific alternatives among the many sibling tools, such as 'booleans_booleanPointInPolygon' for point-in-polygon checks or 'transformation_union' for combining polygons, which might be relevant in related workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: random nature of sampling (may yield different results each time), constraints on input (must be valid JSON), dependencies (Turf.js and Node.js), error conditions (JavaScript failures, timeouts, bad input), and special cases (num=0 returns empty collection). It doesn't mention performance characteristics or rate limits, but covers most essential behavioral aspects.
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 appropriately sized but not optimally structured. While it contains valuable information, it mixes purpose, parameters, returns, raises, example, and notes in a somewhat unstructured way. The front-loaded purpose statement is clear, but the subsequent sections could be better organized for quick scanning.
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 tool's moderate complexity, no annotations, and the presence of an output schema, the description is remarkably complete. It covers purpose, parameters, return values, error conditions, examples, and important notes about constraints and dependencies. The output schema handles return format documentation, allowing the description to focus on operational context.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. It explains both parameters thoroughly: feature_collection (JSON string format, GeoJSON FeatureCollection type, examples) and num (sampling count, integer type, constraints). The description adds substantial value beyond the bare 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 tool's purpose with specific verb ('随机采样' - random sampling) and resource ('特征集合' - feature collection). It distinguishes from siblings by focusing on random sampling rather than aggregation, classification, or transformation operations listed among sibling tools.
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 about when to use this tool (random sampling from feature collections) and includes important constraints (sampling count cannot exceed total features, returns empty collection if num=0). However, it doesn't explicitly mention when NOT to use it or name specific alternative tools for different sampling needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by describing the return format (GeoJSON Polygon Feature), error conditions (JavaScript execution failures, timeouts, input format errors), dependencies (Turf.js library and Node.js environment), and specific constraints (coordinates must form closed rings, WGS84 coordinate system).
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 comprehensive but quite long with multiple sections (Args, Returns, Raises, Example, Notes). While well-structured, it could be more front-loaded with the core purpose. Some information in the Example section duplicates what's already in the Returns section, reducing efficiency.
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 tool's complexity (3 parameters, 0% schema coverage, no annotations), the description provides complete context. It explains the tool's purpose, parameters, return values, error conditions, examples, and important constraints. The presence of an output schema reduces the need to explain return values, but the description still provides valuable format details.
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 schema description coverage is 0%, so the description must fully compensate. It does this excellently by providing detailed parameter documentation including types, formats, examples, optional fields, and constraints for all three parameters (coordinates, properties, options). The description adds significant value beyond the minimal input 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 tool's purpose: '创建多边形特征对象' (creates polygon feature objects) with specific details about representing regional/areal geographic features. It distinguishes itself from sibling tools like 'helper_point', 'helper_lineString', and 'helper_feature' by focusing specifically on polygon creation with coordinate arrays.
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 about when to use this tool: for creating polygon features representing areas/regions. It doesn't explicitly state when NOT to use it or name specific alternatives, but the context is sufficiently clear given the sibling tools list which includes other geometry creation tools like 'helper_point' and 'helper_lineString'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (creates TIN from points), mentions dependencies (Turf.js and Node.js), specifies coordinate system (WGS84 with [longitude, latitude] order), and documents error conditions (JavaScript execution failures, timeouts, input format errors). However, it doesn't mention performance characteristics like computational complexity or memory usage.
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 well-structured with clear sections (Args, Returns, Raises, Example, Notes), but it's quite lengthy with multiple detailed examples and technical notes. While all content is relevant, it could be more front-loaded with the core purpose. The structure helps navigation but the overall length reduces conciseness.
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 tool's complexity (geospatial triangulation), no annotations, and 0% schema coverage, the description provides comprehensive documentation. It covers purpose, parameters, return format, error conditions, examples, coordinate system, dependencies, and use cases. With an output schema present, the description appropriately focuses on behavioral context rather than repeating return value details.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. It explains both parameters thoroughly: 'points' as a GeoJSON FeatureCollection string with format details and examples, and 'z_property' as an optional attribute name for elevation data with clear examples. The description adds significant value beyond the bare 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 tool's purpose: '从点集创建不规则三角网' (create an irregular triangular network from point sets). It specifies the exact action (创建/create) and resource (不规则三角网/irregular triangular network), and distinguishes from siblings by mentioning its use for surface modeling and terrain analysis, unlike other interpolation tools like 'interpolation_interpolate' or 'interpolation_isolines'.
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 surface modeling and terrain analysis using point sets. It doesn't explicitly state when not to use it or name alternatives among siblings, but the specific application context is well-defined, making it clear this is for triangulation tasks rather than other interpolation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it calculates a rhumb bearing, returns a JSON object with value and units, requires valid JSON strings as input, uses WGS84 coordinates, and raises exceptions on failures. It also notes dependencies (Turf.js, Node.js) and coordinate order. This covers most behavioral aspects well, though it could mention performance or rate limits.
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 well-structured with sections (Args, Returns, Raises, Example, Notes), but it is verbose and includes redundant information (e.g., repeating JSON string format details). Some sentences could be more concise, and the front-loading is moderate—the core purpose is clear early, but details are extensive. It earns its place but could be tighter.
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 tool's complexity (geospatial calculation), no annotations, 0% schema coverage, but with an output schema (implied by Returns section), the description is highly complete. It covers purpose, usage, parameters, return values, errors, examples, and notes, providing all necessary context for an AI agent to use the tool correctly. The output schema is effectively described in the Returns section.
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%, so the description must fully compensate. It does so excellently: it explains all three parameters (point1, point2, options) in detail, including types, formats, coordinate systems, examples, and optional fields. This adds significant meaning beyond the bare schema, making the parameters fully understandable.
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: '计算两点之间的恒向线方位角' (calculates the rhumb bearing between two points). It specifies the exact operation (rhumb bearing calculation), distinguishes it from siblings like 'measurement_bearing' (which likely calculates great-circle bearing), and mentions the underlying Turf.js method. This is specific and differentiated.
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 calculating rhumb bearings (constant bearing) between two points, as opposed to great-circle bearings. It mentions the dependency on Turf.js and Node.js, which is useful. However, it does not explicitly state when not to use it or name alternatives (e.g., 'measurement_bearing'), though the distinction is implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool finds nearest points on the line to the given start/end points, returns a GeoJSON LineString feature, raises exceptions for failures or bad input, and depends on Turf.js and Node.js. It covers mutation behavior (slicing), output format, error conditions, and dependencies, though it could mention performance or rate limits.
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 appropriately sized but not optimally structured. It starts with a clear purpose, but includes extensive parameter details (Args, Returns, Raises, Example, Notes) that, while valuable, could be more front-loaded. Every sentence earns its place, but the organization could be improved for quick scanning, with key usage info earlier.
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 tool's complexity (geospatial slicing), no annotations, 0% schema coverage, and an output schema present, the description is complete. It explains the operation, parameters, return values, errors, examples, and dependencies. The output schema handles return structure, so the description need not duplicate that, making it well-rounded for agent understanding.
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%, so the description must compensate fully. It provides detailed semantics for all three parameters: types (JSON strings), formats (GeoJSON Point/LineString), coordinate system (WGS84 with longitude first), and examples. This adds significant meaning beyond the basic schema, fully documenting parameter requirements and usage.
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: '在线段上截取指定起点和终点之间的部分' (extract the segment between specified start and end points on a line). It uses specific verbs ('截取' - slice/extract) and resources ('线段' - line segment), and distinguishes from sibling tools like 'misc_line_slice_along' (which slices by distance) and 'misc_line_segment' (which might create segments differently).
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 through the example and notes (e.g., requires valid GeoJSON strings, WGS84 coordinates). However, it does not explicitly state when to use this tool versus alternatives like 'misc_line_slice_along' or 'misc_line_segment', nor does it mention prerequisites or exclusions beyond format requirements. The guidance is clear but lacks explicit comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing: the tool modifies geometry through clipping, requires specific coordinate order (longitude first), has a default mask behavior, depends on Turf.js/Node.js, and raises exceptions for failures. It doesn't mention rate limits or authentication needs, but covers key behavioral aspects for a geometry processing tool.
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 well-structured with clear sections (Args, Returns, Raises, Example, Notes) but is quite lengthy. While all content is valuable given the complex parameters, some sections like the detailed example could be more concise. The purpose statement is front-loaded effectively.
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 complex geometry processing tool with 3 parameters, 0% schema coverage, and no annotations, the description provides exceptional completeness: detailed parameter semantics, return format specification, error conditions, examples, and implementation dependencies. The output schema exists but the description still usefully explains the return format.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation: detailed format requirements (GeoJSON types, coordinate systems, examples), optional parameters with defaults, and clear data type specifications. It adds substantial value beyond the minimal schema that only indicates string/null types.
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 ('使用掩膜多边形裁剪几何图形' - use mask polygon to clip geometric shapes) and resource (polygons). It distinguishes itself from siblings like 'transformation_bboxClip' or 'transformation_intersect' by specifying the mask-based clipping approach rather than bounding box or intersection operations.
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 about when to use this tool (for clipping polygons with a mask polygon) and includes helpful notes about default behavior (using world extent if no mask provided). However, it doesn't explicitly contrast with alternative clipping tools like 'transformation_bboxClip' or 'transformation_intersect' that might serve similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a deep copy operation (non-destructive), includes all properties and '外成员' (foreign members), uses WGS84 coordinate system, is faster than JSON.parse+JSON.stringify, depends on Turf.js and Node.js, and raises exceptions for failures. This covers most aspects an agent needs, though it doesn't detail performance limits or auth requirements.
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 well-structured with sections (Args, Returns, Raises, Example, Notes), but it's verbose with redundant information (e.g., the example repeats the input in the output). Some details like '依赖于 Turf.js 库和 Node.js 环境' could be more concise. It's front-loaded with the core purpose, but could be tighter.
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 tool's complexity (a single-parameter transformation), no annotations, 0% schema coverage, but with an output schema (implied by 'Returns' section), the description is highly complete. It covers purpose, usage, parameters, behavior, returns, errors, examples, and technical notes, leaving no gaps for an agent to operate effectively.
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%, so the description must fully compensate. It provides extensive parameter semantics: geojson must be a JSON string, valid GeoJSON object, in WGS84 with longitude-first coordinate order, and includes a detailed example. This adds significant meaning beyond the bare schema, fully documenting the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '创建 GeoJSON 对象的完整副本' (creates a complete copy of a GeoJSON object). It specifies it's a deep copy including all properties and geometry, which distinguishes it from sibling transformation tools that modify geometry (like buffer, simplify, union) rather than copying.
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 through the 'Args' and 'Notes' sections, explaining the input must be a valid JSON string with specific coordinate order. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., when needing a copy vs. direct manipulation), nor does it mention sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses key behavioral traits: the normalization behavior ('输出方位角始终在0到360度范围内'), error conditions ('当 JavaScript 执行失败、超时或输入数据格式错误时抛出异常'), dependencies ('依赖于 Turf.js 库和 Node.js 环境'), and the exact return format. It doesn't mention performance characteristics like execution time or rate limits, but covers the essential operational behavior.
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 appropriately front-loaded with the core purpose, but contains some redundancy (the first two sentences essentially say the same thing). The structured sections (Args, Returns, Raises, Example, Notes) are helpful but make the description longer than necessary for a single-parameter tool. Some information in Notes could be integrated more efficiently.
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 single-parameter tool with no annotations and no output schema, the description provides complete context. It covers the transformation logic, input requirements, return format with examples, error conditions, dependencies, and use cases. The agent has everything needed to understand when and how to use this tool correctly, despite the lack of structured metadata.
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?
With 0% schema description coverage (the schema only shows 'bearing' as a number with no description), the description fully compensates by providing comprehensive parameter documentation. It explains the parameter type, purpose ('输入方位角（可以是任意角度）'), and provides an example. The description adds significant value beyond the bare schema by clarifying that any angle value is acceptable as input.
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: '将方位角转换为方位角（0-360度范围）' (convert bearing to azimuth in 0-360 degree range). It specifies the exact transformation (normalization to 0-360) and distinguishes itself from sibling unit conversion tools like 'unit_conversion_degreesToRadians' or 'unit_conversion_convertLength' by focusing specifically on bearing normalization rather than unit conversion or coordinate transformation.
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 about when to use this tool: '常用于标准化方位角表示' (commonly used for standardizing bearing representation). It implies usage for normalizing any bearing angle to the 0-360 range. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the many sibling tools, though the purpose clearly differentiates it from other unit conversion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it describes the return format (JSON string with value and units), mentions dependencies (Turf.js and Node.js environment), and outlines error conditions (JavaScript execution failures, timeouts, or input format errors). This provides good transparency for a tool with no annotations.
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 well-structured with clear sections (Args, Returns, Raises, Example, Notes), but it is somewhat verbose. Some information (like the full example and detailed notes) could be more concise. However, all content is relevant and adds value, avoiding redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is highly complete. It covers purpose, parameter details, return format, error handling, examples, and implementation notes. This provides all necessary context for an AI agent to understand and use the tool effectively.
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 has 0% description coverage (only type information), but the description fully compensates by providing detailed parameter documentation: it defines 'radians' as a float value to be converted, gives an example (3.14159), and explains its role in the conversion. This adds significant meaning beyond the bare 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 tool's purpose: '将弧度转换为角度' (convert radians to degrees). It specifies the exact transformation (radians to degrees) and distinguishes itself from sibling tools like 'degreesToRadians' and other unit conversion tools by focusing on this specific direction of conversion.
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 mathematical calculations and trigonometry involving radian-to-degree conversion. It mentions the conversion formula and typical use cases, but does not explicitly state when NOT to use it or name specific alternatives among siblings (e.g., 'degreesToRadians' for the reverse operation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses important behavioral traits: algorithm uses random initialization (results may vary), cluster numbering starts at 0, coordinate system (WGS84), dependencies (Turf.js, Node.js), and error conditions (JavaScript execution failures, timeouts, format errors). It also mentions the 'mutate' option that can modify original features.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some sections like the detailed example could be slightly condensed. Most sentences earn their place by providing essential information.
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 tool's complexity (clustering algorithm with 3 parameters), no annotations, and the presence of an output schema, the description is remarkably complete. It covers purpose, parameters, return format, errors, example usage, and important behavioral notes. The output schema existence means the description doesn't need to explain return values in detail, which it respects while still providing helpful context.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. Each parameter (points, number_of_clusters, options) gets comprehensive explanations including types, formats, examples, and for 'options', the specific optional fields. The description adds substantial meaning beyond the bare 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 ('使用 K-means 算法进行点聚类' - uses K-means algorithm for point clustering) and resource ('点' - points). It distinguishes from sibling tools like 'aggregation_clustersDbscan' by specifying the algorithm used (K-means vs DBSCAN). The purpose is unambiguous and algorithm-specific.
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 (clustering points with K-means algorithm) and mentions it requires pre-specified cluster count. However, it doesn't explicitly state when NOT to use it or compare it with alternatives like the DBSCAN sibling tool, which would be helpful for algorithm selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing: the tool's dependency on Turf.js and Node.js environment, potential exceptions for JavaScript execution failures/timeouts/input errors, coordinate system (WGS84 with [longitude, latitude] order), and return format. It doesn't mention performance characteristics or rate limits, but covers essential behavioral aspects.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. Some redundancy exists between the initial statement and the expanded explanation, but overall it's efficiently organized with each section earning its place.
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 tool's moderate complexity (geometric orientation check), no annotations, 0% schema coverage, but presence of output schema, the description is remarkably complete. It covers purpose, parameters, returns, errors, examples, dependencies, coordinate systems, and geometric semantics - providing everything needed for correct tool invocation.
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?
With 0% schema description coverage (schema only says 'ring' is a string), the description fully compensates by providing comprehensive parameter documentation: exact JSON string format with array structure [[x1, y1], ...], coordinate order, example, and validation requirements. This adds substantial meaning beyond the minimal 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 tool's purpose as '检查环是否为顺时针方向' (check if a ring is clockwise), specifying both the verb (check) and resource (ring). It distinguishes from siblings like 'booleans_booleanContains' or 'booleans_booleanWithin' by focusing specifically on ring orientation rather than spatial relationships between geometries.
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 about when to use this tool through the 'Notes' section, explaining that clockwise rings represent external polygon boundaries and counterclockwise rings represent internal holes. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a read-only boolean check (implied by '检查' - check), specifies that boundary contact is not considered containment ('边界接触不被视为包含'), notes coordinate order requirements ('坐标顺序为 [经度, 纬度]'), and mentions dependencies ('依赖于 Turf.js 库和 Node.js 环境'). It also covers error conditions ('Raises: Exception...'). The only gap is lack of explicit rate limit or performance info, but this is reasonable for a geometric operation.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. It is appropriately sized for a tool with 2 parameters and detailed requirements. Some redundancy exists (e.g., repeating 'JSON 字符串格式'), but overall it's efficient with zero fluff—every sentence provides necessary technical details.
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 tool's complexity (spatial boolean operation), no annotations, 0% schema coverage, but with an output schema (implied by Returns section), the description is highly complete. It covers purpose, parameters, return format, errors, examples, and critical notes (coordinate order, containment definition, dependencies). The output schema is clearly described in the Returns section, so no additional return value explanation is needed. This provides all necessary context for correct tool invocation.
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%, so the description must fully compensate. It does so excellently: for both parameters (geojson1, geojson2), it provides type (str/JSON string), format (valid GeoJSON object), and concrete examples with detailed syntax. It also explains the spatial relationship context ('第一个几何图形是否完全包含第二个几何图形') and coordinate system (WGS84). This adds substantial meaning beyond the bare 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 tool's purpose: '检查第一个几何图形是否包含第二个几何图形' (Check if the first geometry contains the second geometry). It specifies the exact operation (contains check) and resources (GeoJSON geometries), and distinguishes from siblings like 'booleans_booleanWithin' (which checks the inverse relationship) and 'booleans_booleanPointInPolygon' (which is a specific case).
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 checking if one GeoJSON geometry fully contains another. It implies usage by specifying the spatial relationship ('完全包含' - fully contains) and notes that boundary contact is not considered containment. However, it does not explicitly state when not to use it or name alternatives (e.g., 'booleans_booleanWithin' for the inverse check), though the sibling list allows for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it explains the return format (JSON with boolean value), error conditions (Raises section), dependencies (Turf.js, Node.js), and specific behavioral details like coordinate order [longitude, latitude] and that boundary contact is considered intersection. It doesn't mention performance or rate limits, but covers core behavior adequately.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the purpose. It could be slightly more concise as some information in Notes (e.g., coordinate order) might be integrated earlier, but overall it's efficient with minimal waste.
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 tool's moderate complexity (2 parameters, boolean operation), no annotations, but with output schema (implied by Returns section), the description is complete: it covers purpose, parameters, return format, errors, examples, and implementation notes. The output schema existence means the description doesn't need to explain return values in detail, which it handles appropriately.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation: it defines both parameters (geojson1, geojson2), specifies their type (JSON strings), format requirements (valid GeoJSON), and provides concrete examples. This adds substantial value beyond the bare 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 verb ('检查是否不相交' - checks if disjoint) and resource ('两个几何图形' - two geometries), distinguishing it from siblings like 'booleanContains' or 'booleanOverlap' by focusing on the disjoint relationship. The first sentence directly answers what the tool does.
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 ('检查两个几何图形是否完全不相交' - checks if two geometries are completely disjoint), but does not explicitly state when not to use it or name specific alternatives among the many sibling boolean tools. The Notes section adds usage constraints (e.g., boundary contact counts as intersection).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses: the tool performs a spatial computation (not destructive), requires valid JSON strings as input, uses WGS84 coordinate system, has specific overlap semantics, excludes boundary contact, depends on Turf.js/Node.js, and can raise exceptions for execution failures or bad input. This covers most behavioral aspects needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. Most sentences earn their place by providing essential information. However, some details in the Notes section could be more concise, and the Python example might be slightly verbose for a tool description.
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 tool's moderate complexity (spatial computation with specific semantics), no annotations, and an output schema present, the description is remarkably complete. It covers purpose, parameters, return format, error conditions, examples, and implementation dependencies. The output schema handles return values, so the description appropriately focuses on behavioral context and input 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 fully compensates with detailed parameter documentation. It explains both parameters are GeoJSON objects as JSON strings, provides format requirements ('任何有效的 GeoJSON 对象'), gives concrete examples with proper syntax, and specifies coordinate order as [longitude, latitude]. This adds substantial meaning beyond the bare 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 tool's purpose: '检查两个几何图形是否重叠' (check if two geometries overlap). It specifies the exact spatial relationship ('有共同区域但不完全包含' - have common area but not fully contained) and distinguishes it from siblings like booleans_booleanContains and booleans_booleanWithin by explicitly defining overlap as distinct from containment.
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 about when to use this tool: for checking spatial overlap where geometries share area but don't fully contain each other. It explicitly states boundary contact is not considered overlap, helping differentiate from other boolean operations. However, it doesn't explicitly name alternative tools or provide 'when-not-to-use' guidance beyond the overlap definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context: it specifies that calculations use spherical distance in kilometers, returns a point with a distance property, depends on Turf.js and Node.js, and raises exceptions for failures. This covers key traits like output format, dependencies, and error handling, though it could mention performance or rate limits.
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 sections like Args, Returns, Raises, Example, and Notes, making it easy to navigate. It is appropriately sized but includes some redundancy (e.g., repeating JSON format details), slightly reducing efficiency.
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 complexity (2 parameters, no annotations, 0% schema coverage, but has output schema), the description is complete: it explains inputs, outputs, errors, examples, and notes on dependencies and coordinate systems. The output schema is covered by the Returns section, ensuring the agent has all necessary context.
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%, so the description must compensate. It provides detailed semantics for both parameters: 'target_point' and 'points' are described as JSON strings in GeoJSON format with examples, including geometry types and coordinate order. This adds significant meaning beyond the basic 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 tool's purpose: '查找距离目标点最近的点特征' (find the nearest point feature to a target point). It specifies the verb ('查找' - find) and resource ('点特征' - point feature), and distinguishes from siblings by focusing on nearest-point calculation, unlike other tools for clustering, measurement, or transformation.
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 through examples and notes, such as requiring valid JSON strings and using WGS84 coordinates. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'measurement_distance' for distance between two points or 'misc_nearest_point_on_line' for nearest point on a line), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses that the tool converts geometric objects to feature objects, depends on Turf.js and Node.js, has JSON string requirements, and can throw exceptions for execution failures or bad input. It also explains the optional 'mutate' parameter behavior. The only gap is lack of explicit rate limits or performance characteristics.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. However, it's somewhat lengthy with detailed examples and implementation notes that could potentially be condensed while maintaining clarity.
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 tool's moderate complexity, no annotations, 0% schema coverage, but presence of an output schema, the description is remarkably complete. It covers purpose, parameters, return values, errors, examples, and implementation dependencies. The output schema existence means the description doesn't need to fully document return structure, yet it still provides helpful examples.
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?
With 0% schema description coverage, the description fully compensates by providing rich parameter documentation. It explains both parameters in detail: 'geojson' as a JSON string with format, coordinate system, and examples; 'options' as optional JSON with the 'mutate' field behavior. This adds substantial meaning beyond the bare 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 tool's purpose: '交换坐标的经度和纬度位置' (swap longitude and latitude positions). It specifies the exact transformation from [longitude, latitude] to [latitude, longitude] format and distinguishes it from sibling tools like 'coordinate_mutation_clean_coords' or 'coordinate_mutation_rewind' by focusing on coordinate order flipping rather than other geometric operations.
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: '适用于不同系统的坐标约定' (suitable for different coordinate system conventions). It implies usage when converting between systems with different coordinate order conventions. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing key behaviors: it explains the underlying Turf.js implementation, specifies coordinate system (WGS84 with longitude-first ordering), describes the mutation option ('mutate' parameter), documents error conditions (JavaScript execution failure, timeout, input format errors), and notes JSON string requirements. The only minor gap is lack of explicit rate limit or performance characteristics.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. While comprehensive, it's appropriately sized for a tool with complex parameter semantics and no schema descriptions. Some sections could be slightly more concise, but every sentence adds value given the context.
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 tool's complexity (coordinate transformation with multiple options), zero schema description coverage, no annotations, but with output schema provided, the description is remarkably complete. It covers purpose, parameters with examples, return format with example, error conditions, implementation details, dependencies, and important notes about coordinate ordering and JSON requirements. The output schema handles return type documentation, allowing the description to focus on semantic context.
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?
With 0% schema description coverage (schema only shows parameter names and types without descriptions), the description fully compensates by providing comprehensive parameter documentation. It details both parameters: 'geojson' with format requirements, coordinate system, and examples; 'options' with all optional fields, defaults, and examples. This adds substantial value beyond the bare 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 tool's purpose: '截断 GeoJSON 几何图形的坐标精度' (truncate coordinate precision of GeoJSON geometries). It specifies the verb ('截断' - truncate), the resource ('GeoJSON 几何图形' - GeoJSON geometries), and distinguishes from siblings by focusing on coordinate precision truncation rather than other coordinate mutations like 'clean_coords', 'flip', 'rewind', or 'round_number'.
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 reducing coordinate decimal precision and optionally removing Z coordinates in GeoJSON geometries. It mentions the Turf.js library dependency and Node.js environment, which are important prerequisites. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for different coordinate manipulation needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it specifies the coordinate system (WGS84 with longitude-first), notes dependencies on Turf.js and Node.js, and mentions error conditions (JavaScript execution failure, timeouts, input format errors). However, it doesn't detail performance aspects like rate limits or memory usage, which keeps it from a perfect score.
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 sections (Args, Returns, Raises, Example, Notes), making it easy to parse. It's front-loaded with the core purpose. However, it includes some redundancy (e.g., repeating JSON format details) and could be slightly more concise without losing clarity, hence not a perfect 5.
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 complexity (geometric operations), no annotations, and an output schema present, the description is highly complete. It covers input requirements, output format, error handling, dependencies, and provides a clear example. The output schema handles return value details, so the description doesn't need to reiterate them, making it appropriately comprehensive.
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 schema description coverage is 0%, so the description must fully compensate. It provides extensive parameter semantics: defines 'feature_collection' as a JSON string in GeoJSON FeatureCollection format, specifies the coordinate system, gives an example, and notes validation requirements (must be valid JSON). This adds significant meaning beyond the bare 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 a clear, specific statement: '将特征集合合并为复合几何图形' (Combine feature collections into composite geometries). It distinguishes from siblings like 'feature_conversion_explode' (which does the opposite) and 'feature_conversion_flatten' by specifying it creates MultiPoint, MultiLineString, or MultiPolygon geometries from corresponding feature types. The purpose is unambiguous and differentiated.
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 when to use it: for converting collections of points, lines, or polygons into their multi-geometry counterparts. It doesn't explicitly state when not to use it or name alternatives, but the context is clear from the tool's name and the sibling list (e.g., use 'feature_conversion_explode' for the reverse operation). This provides adequate guidance without being exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing behavioral traits: it specifies the coordinate system (WGS84), notes dependencies (Turf.js and Node.js), and mentions error conditions (JavaScript execution failure, timeout, or input format errors). However, it does not detail rate limits, authentication needs, or side effects, leaving some gaps for a mutation-like tool.
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 sections for Args, Returns, Raises, Example, and Notes, making it easy to navigate. However, it is somewhat lengthy due to the detailed example and notes; while informative, some sentences could be more condensed without losing clarity, slightly reducing efficiency.
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 tool's complexity (geometric conversion), no annotations, and an output schema present, the description is complete: it explains the purpose, parameter details, return format (GeoJSON FeatureCollection), error handling, dependencies, and includes an example. This provides all necessary context for an AI agent to understand and use the tool effectively.
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 schema description coverage is 0%, but the description compensates fully by detailing the 'geojson' parameter: it specifies the type (string in JSON format), format (any valid GeoJSON object), coordinate system (WGS84 with longitude first), and provides an example. This adds significant meaning beyond the basic schema, making the parameter semantics clear and comprehensive.
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 with specific verbs ('展平' meaning flatten) and resources ('复合几何图形' meaning composite geometries, '简单几何图形' meaning simple geometries), and it distinguishes from siblings by focusing on conversion of multi-geometries to simple features, unlike other conversion tools like 'feature_conversion_explode' or 'feature_conversion_combine' which handle different operations.
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 flattens multi-geometries (e.g., MultiPolygon) into simple geometry feature collections, but it does not explicitly state when to use this tool versus alternatives like 'feature_conversion_explode' or other geometric tools. It provides clear input requirements (valid GeoJSON string) but lacks explicit exclusions or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool creates polygons from closed line regions, requires specific input formats (GeoJSON with WGS84 coordinates), and can raise exceptions for execution failures, timeouts, or data errors. It also notes dependencies on external libraries. While comprehensive, it could mention performance aspects like processing time or limitations with non-closed lines.
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 sections for purpose, args, returns, raises, example, and notes, making it easy to navigate. It is appropriately sized with no redundant information. However, the example and notes sections are slightly verbose, and the front-loading could be improved by placing the core purpose more prominently, but overall it is efficient.
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 tool's complexity (geometric conversion), no annotations, 0% schema coverage, and the presence of an output schema, the description is complete. It covers input requirements, output format, error handling, dependencies, and provides an example. The output schema details the return type, so the description doesn't need to explain return values further, making it fully adequate for the context.
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 schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for the 'geojson' parameter: type (JSON string), format (GeoJSON FeatureCollection/Geometry/Feature with LineString/MultiLineString), coordinate system (WGS84), and an example. This adds significant value beyond the basic schema, ensuring the agent understands parameter requirements 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 the tool's purpose: '将线几何图形转换为多边形' (convert line geometries to polygons). It specifies the exact transformation (lines to polygons) and distinguishes it from sibling tools like 'feature_conversion_line_to_polygon' by providing additional context about handling closed regions and using Turf.js, making it specific and differentiated.
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 on when to use this tool: for converting LineString or MultiLineString geometries to polygons based on closed regions. It mentions dependencies (Turf.js, Node.js) and input requirements (valid JSON, WGS84). However, it does not explicitly state when not to use it or compare it to alternatives like 'feature_conversion_line_to_polygon', which is a sibling tool, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral traits: the tool extracts polygon boundaries, requires valid JSON input, uses WGS84 coordinate system, depends on Turf.js/Node.js, and can raise exceptions for execution failures, timeouts, or bad input. It doesn't mention performance characteristics or rate limits, but covers the essential behavior well.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. Some redundancy exists (e.g., coordinate order mentioned multiple times), but every section adds value. The example is particularly helpful for understanding usage.
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 single-parameter tool with no annotations but with output schema (implied by the Returns section), the description is remarkably complete. It covers purpose, usage, parameters, return values, error conditions, dependencies, and provides a working example. The Notes section adds important implementation details about JSON format and coordinate systems.
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?
With 0% schema description coverage (the schema only says 'polygon' is a string), the description fully compensates. It provides detailed semantics: the parameter must be a JSON string in GeoJSON Polygon/MultiPolygon format, with WGS84 coordinates in [longitude, latitude] order, and includes a concrete example. This adds substantial value beyond the bare 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 tool's purpose: '将多边形转换为线几何图形' (convert polygon to line geometry). It specifies the exact transformation (polygon/multi-polygon to line/multi-line) and distinguishes from siblings like 'feature_conversion_line_to_polygon' (which does the reverse) and 'feature_conversion_polygonize' (which creates polygons).
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 you need to extract polygon boundaries as lines. It doesn't explicitly mention when NOT to use it or name specific alternatives, but the sibling tool 'feature_conversion_line_to_polygon' is clearly the inverse operation, providing implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool creates a rule-distributed point grid, returns a GeoJSON FeatureCollection, depends on Turf.js and Node.js, and raises exceptions for failures. It also notes input requirements (JSON strings, coordinate order) and typical use cases, though it lacks details on performance or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and is appropriately sized for the tool's complexity. It is front-loaded with the core purpose, but some sections (like the detailed parameter explanations) are lengthy, though necessary given the lack of schema descriptions.
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 tool's complexity (3 parameters, spatial operations) and the presence of an output schema (implied by the detailed Returns section), the description is highly complete. It covers purpose, parameters, return format, errors, examples, dependencies, and usage notes, providing all necessary context for an AI agent to use the tool effectively.
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%, so the description must fully compensate. It provides detailed semantics for all three parameters (bbox, cell_size, options), including types, formats, examples, optional fields with defaults, and valid values for enums (e.g., units). This adds significant value beyond the minimal input schema, ensuring parameters are well-understood.
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: '在边界框内生成点网格' (generate a point grid within a bounding box). It specifies the verb ('生成' - generate) and resource ('点网格' - point grid), and distinguishes it from sibling tools like grid_hexGrid, grid_squareGrid, and grid_triangleGrid by focusing on point generation rather than other grid 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 provides clear context for when to use this tool: '用于空间采样和插值' (for spatial sampling and interpolation). It implies usage in spatial analysis scenarios but does not explicitly state when not to use it or name specific alternatives among siblings, though the sibling list includes other grid tools that serve different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by explaining the return format (GeoJSON FeatureCollection), error conditions (JavaScript execution failure, timeout, input format errors), dependencies (Turf.js and Node.js environment), and coordinate system details (WGS84, longitude-latitude order). It also notes that the grid provides regular rectangular areas for statistics and aggregation.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded with the core purpose. While comprehensive, it's appropriately sized for a tool with three parameters and complex output. Some sentences in the Notes section could be more concise, but overall it's efficient.
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 tool's complexity (spatial grid generation with three parameters), no annotations, and an output schema present, the description is complete. It covers purpose, parameters, return values, errors, examples, and important notes about JSON format, coordinate system, and dependencies. The output schema is described in detail, making the description fully adequate.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. It explains all three parameters (bbox, cell_size, options) with types, formats, examples, and for 'options', it lists all optional fields with their valid values and defaults. This adds substantial meaning beyond what the bare schema provides.
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: '在边界框内生成正方形网格' (generate a square grid within a bounding box). It specifies the verb ('生成' - generate) and resource ('正方形网格' - square grid), and distinguishes from siblings like 'grid_hexGrid' and 'grid_triangleGrid' by explicitly mentioning '正方形' (square).
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 spatial analysis and regional division ('用于空间分析和区域划分'). It doesn't explicitly mention when not to use it or name alternatives, but the context is sufficient for an agent to understand its application in grid-based spatial operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing key behaviors: it explains the return format in detail, mentions error conditions (JavaScript execution failure, timeout, input format errors), specifies coordinate order requirements, notes JSON string requirements for inputs, and discloses the dependency on Turf.js and Node.js. This provides comprehensive behavioral context beyond basic functionality.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, it maintains efficiency with no wasted sentences - each section serves a clear purpose. The length is appropriate for a tool with complex parameters and no annotations.
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 tool's complexity (3 parameters, no annotations, 0% schema coverage), the description provides complete context. It thoroughly documents parameters, return values, error conditions, dependencies, and usage notes. The presence of an output schema reduces the need to explain return values, but the description still adds valuable context about the GeoJSON format and examples.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. Each parameter (geometries, properties, options) gets clear explanations of type, format, examples, and optional fields. The description adds substantial semantic value beyond the bare schema, making parameter usage completely understandable.
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: '创建几何图形集合特征' (create a geometry collection feature). It specifies the verb ('创建' - create) and resource ('几何图形集合特征' - geometry collection feature), and distinguishes it from siblings like helper_feature or helper_featureCollection by focusing specifically on GeometryCollection type features.
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: '适用于包含多种几何类型的复杂场景' (suitable for complex scenarios containing multiple geometry types). It doesn't explicitly mention when not to use it or name specific alternatives, but the context is sufficiently clear for an agent to understand its application domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses that the tool returns a bounding box array, specifies coordinate system (WGS84), format requirements (JSON string), and implementation dependencies (Turf.js, Node.js). It also mentions error conditions (JavaScript execution failures, timeouts, invalid data). However, it doesn't cover performance characteristics like computational complexity.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. It's appropriately sized for a single-parameter tool with detailed requirements. The only minor inefficiency is the inclusion of Python example code in what appears to be a JavaScript/Node.js context.
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 tool with 1 parameter, no annotations, 0% schema coverage, but with output schema (implied by Returns section), the description is complete: it covers purpose, parameter details, return format, error conditions, examples, and implementation notes. The output schema equivalent in the Returns section eliminates the need to describe return values in the main description.
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 has 0% description coverage (just 'geojson' as a string type), but the description comprehensively documents the single parameter: it explains geojson must be a valid JSON string, specifies the coordinate system (WGS84), provides format details (any valid GeoJSON), and gives a concrete example. This fully compensates for the schema's lack of documentation.
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: '计算地理对象的边界范围' (calculates the bounding box of geographic objects). It specifies the verb ('计算' - calculate) and resource ('地理对象的边界范围' - bounding box of geographic objects), and distinguishes itself from sibling tools like 'measurement_bboxPolygon' by focusing on coordinate arrays rather than polygon representations.
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 calculating bounding boxes from GeoJSON objects. It doesn't explicitly state when not to use it or name alternatives, but the sibling list shows 'measurement_bboxPolygon' as a potential alternative for polygon-based bounding boxes, which is implied but not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well at disclosing behavioral traits. It specifies input format requirements (JSON strings), coordinate system (WGS84), dependencies (Turf.js, Node.js), error conditions (JavaScript execution failure, timeout, data format errors), and output format (GeoJSON Polygon feature). It doesn't mention performance characteristics like rate limits, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. While comprehensive, some sections could be more concise - the example includes full import and execution code that might be simplified. Overall, most sentences earn their place by providing valuable information.
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 tool's complexity (coordinate transformation), lack of annotations, and 0% schema coverage, the description provides complete context. It explains inputs, outputs (though an output schema exists), error conditions, dependencies, coordinate systems, and includes a working example. The description successfully compensates for the lack of structured metadata.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. It explains both parameters (bbox and options) with type information, format specifications, examples, and optional fields for options. The description adds comprehensive meaning beyond the minimal input schema, making parameter usage clear.
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 verb ('将边界框转换为' - converts bounding box to) and resource ('多边形特征' - polygon feature), distinguishing it from sibling tools like 'measurement_bbox' (which likely measures bounding boxes) or 'feature_conversion_polygonize' (which creates polygons from other geometries). The purpose is precise and unambiguous.
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 ('便于进行多边形操作和可视化' - facilitates polygon operations and visualization), but doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools. The context is helpful but lacks explicit exclusion criteria or comparison to similar tools like 'feature_conversion_line_to_polygon'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job. It discloses critical behavioral traits: coordinate system (WGS84 with longitude-first), return format (GeoJSON Point feature), error conditions (JavaScript execution failures, timeouts, input format errors), dependencies (Turf.js and Node.js environment), and that it calculates the center of bounding boxes specifically. No contradictions exist since annotations are absent.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. While comprehensive, some sections could be more concise - the example includes import statements that aren't strictly necessary. Overall, most sentences earn their place by providing essential information.
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 tool's complexity (geometric calculations with specific dependencies), no annotations, and 0% schema coverage, the description provides complete context. It covers purpose, parameters, return values, error conditions, examples, and implementation dependencies. The presence of an output schema reduces the need to explain return values in the description, but the description still provides useful format details.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It explains both parameters in detail: 'geojson' with format requirements, coordinate system, and examples; 'options' with optional fields, data types, and examples. The description adds substantial meaning beyond the bare schema, covering format constraints and usage examples.
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: '计算特征集合的中心点' (calculates the geometric center of a feature collection). It specifies the exact resource (GeoJSON feature collection) and verb (calculate center point), and distinguishes itself from sibling tools like 'measurement_centerOfMass' and 'measurement_centroid' by explicitly stating it returns the center of the bounding box rather than other center 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 provides clear context for when to use this tool: for calculating the geometric center of bounding boxes in GeoJSON feature collections. It doesn't explicitly state when NOT to use it or name specific alternatives, but the distinction from other center-related tools is implied through the specific behavior description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses the tool's dependency on Turf.js and Node.js environment, mentions error conditions (JavaScript execution failure, timeout, input format errors), and specifies coordinate system (WGS84) and ordering (longitude first). It doesn't mention performance characteristics or rate limits, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some sections like the full Python example might be slightly verbose for a tool description, but all content serves clear documentation purposes.
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 complexity of geographic distance calculation, no annotations, and 0% schema coverage, the description provides complete context: purpose, detailed parameter semantics, return format (though output schema exists), error conditions, dependencies, and practical examples. It addresses all necessary aspects for proper tool usage.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation: detailed format requirements for GeoJSON points, coordinate system specifications, examples for all parameters, optional parameter behavior, and valid unit values. This adds significant meaning beyond the bare 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 ('计算两点之间的球面距离' - calculates spherical distance between two points) and resource (GeoJSON points on Earth). It distinguishes from siblings like 'measurement_bearing' (direction) or 'measurement_length' (line length) by emphasizing spherical distance calculation considering Earth's curvature.
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 needing actual Earth distance between two geographic points with spherical calculations. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the many measurement siblings (like 'measurement_rhumbDistance' for rhumb line distance).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses that the tool calculates the minimal bounding box, converts to polygon geometry, depends on Turf.js/Node.js, and raises exceptions for execution failures, timeouts, or malformed input. It doesn't mention performance characteristics or rate limits, but covers key behavioral aspects.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. While comprehensive, some details in the Notes could be more concise, but every sentence adds value for understanding the tool's behavior and constraints.
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 tool's moderate complexity (geospatial transformation), no annotations, 0% schema coverage, but with output schema provided, the description is remarkably complete. It covers purpose, parameters, return format, error conditions, examples, dependencies, and coordinate system details - everything needed for correct tool invocation.
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%, so the description must compensate fully. It provides extensive parameter semantics: geojson must be a valid JSON string in WGS84 coordinate system with [longitude, latitude] order, includes format requirements, and gives a concrete example. This goes far beyond the basic schema type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '将地理对象转换为边界框多边形' (convert geographic objects to bounding box polygons). It specifies the exact transformation (bounding box calculation and polygon conversion) and distinguishes from siblings like 'measurement_bbox' (which likely returns just the bbox coordinates) by emphasizing the polygon output format.
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 converting geographic objects to polygon geometries for polygon operations. It doesn't explicitly mention when NOT to use it or name specific alternatives among siblings, but the purpose inherently suggests it's for polygon output rather than raw bbox coordinates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool returns two tangent points as a FeatureCollection, specifies coordinate system requirements (WGS84 with longitude-first), mentions dependency on Turf.js and Node.js, and documents error conditions (exceptions for execution failure, timeout, or invalid input). It doesn't cover performance characteristics like computational complexity or rate limits, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While somewhat lengthy due to detailed parameter documentation, every section serves a clear purpose. The example is particularly helpful for understanding usage.
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 tool's complexity (geometric calculation with specific format requirements), no annotations, and 0% schema coverage, the description provides excellent completeness. It covers purpose, parameters, return format, error conditions, dependencies, and includes a working example. The output schema exists but the description still usefully explains the return value structure.
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?
With 0% schema description coverage (schema only declares parameters as strings), the description fully compensates by providing comprehensive parameter documentation. It specifies exact GeoJSON types required (Point for 'point', Polygon/MultiPolygon for 'polygon'), coordinate format, coordinate system, and provides clear examples. This adds significant value beyond the minimal 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 tool's purpose: '计算多边形上的切线点' (calculate tangent points on a polygon). It specifies the exact mathematical operation (tangent calculation), the inputs (point and polygon), and distinguishes it from sibling tools by focusing on this specific geometric measurement rather than boolean operations, transformations, or other measurements.
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 calculating tangent points from a point to a polygon using Turf.js. It doesn't explicitly mention when not to use it or name alternatives, but the specificity of the operation (tangent calculation vs. distance, bearing, etc.) implies appropriate usage scenarios among the many sibling measurement tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains the coordinate system (WGS84 with longitude-first), input format requirements (valid JSON strings), dependencies (Turf.js and Node.js), error conditions (JavaScript execution failures, timeouts, format errors), and output format. The only minor gap is lack of explicit rate limit or performance characteristics, but overall provides comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some sections like the detailed parameter documentation could be slightly more concise, but every sentence adds value. The example is particularly helpful for understanding usage.
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 tool's complexity (geospatial calculation with specific format requirements), no annotations, and 0% schema coverage, the description provides complete context. It covers purpose, parameters, return values (though output schema exists, the description clarifies the structure), error conditions, dependencies, coordinate system, and includes a practical example. Nothing essential appears missing for effective tool use.
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?
With 0% schema description coverage (schema only specifies string types), the description fully compensates by providing extensive parameter documentation. It explains each parameter's purpose, format requirements (GeoJSON Point specification), coordinate order, valid units with enumeration, examples, and default values. The description adds significant value beyond the minimal schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '计算两点之间的恒向线距离' (calculates the rhumb line distance between two points). It specifies the exact mathematical operation (rhumb distance), distinguishes it from other measurement tools like 'measurement_distance' (great-circle distance) and 'measurement_greatCircle', and mentions the underlying Turf.js library. This provides specific verb+resource differentiation from siblings.
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 calculating rhumb line distances between GeoJSON points in WGS84 coordinates. It doesn't explicitly state when NOT to use it or name alternatives like 'measurement_distance', but the specificity of '恒向线距离' (rhumb distance) versus other distance calculations implies appropriate usage scenarios. No misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses implementation details (uses Turf.js library, Node.js environment), error conditions (JavaScript execution failure, timeout, input format errors), and output format specifics. It doesn't mention performance characteristics like rate limits, but covers key behavioral aspects.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. It could be slightly more concise in the Notes section, but every sentence adds value. The bilingual presentation (Chinese with English code) is efficient for its context.
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 tool's moderate complexity (geometric transformation), no annotations, and an output schema present, the description is complete. It explains the transformation logic, input/output formats, dependencies, error conditions, and provides a working example. The output schema existence means return values don't need detailed explanation in the description.
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?
With 0% schema description coverage (input schema only shows 'bbox' as a string type), the description fully compensates. It provides detailed parameter semantics: format requirements (JSON string), coordinate order [minX, minY, maxX, maxY], coordinate system (WGS84), and examples. This adds substantial value beyond the minimal 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 tool's purpose: '计算包含边界框的最小正方形边界框' (calculates the minimum square bounding box containing a given bounding box). It specifies the exact operation (calculate), resource (bounding box), and distinguishes from siblings like 'measurement_bbox' (which likely returns the original bounding box) by focusing on square transformation.
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 you need a square bounding box from an input bounding box. It doesn't explicitly state when not to use it or name alternatives among siblings, but the specific purpose implies usage scenarios well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (detects and returns self-intersection points), specifies the coordinate system (WGS84 with longitude first), mentions dependencies (Turf.js and Node.js), and documents error conditions (JavaScript execution failures, timeouts, or invalid input). It also clarifies that it returns ALL self-intersection points, which is useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns, Raises, Example, Notes) and front-loads the core functionality. While somewhat lengthy due to the detailed parameter and example information, every sentence serves a purpose in clarifying the tool's behavior and usage, with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (geometric analysis with specific dependencies), no annotations, and an output schema (which the description references but doesn't need to fully explain), the description is complete. It covers purpose, parameter details, return format, error conditions, dependencies, and provides an example, leaving no significant gaps for a tool of this nature.
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?
With 0% schema description coverage (the schema only indicates 'geojson' is a required string), the description fully compensates by providing comprehensive parameter semantics. It details the parameter type (JSON string), supported formats (specific GeoJSON types), coordinate system, and includes a concrete example. This adds significant value beyond the minimal schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('查找' meaning 'find/detect') and resource ('几何图形中的自相交点' meaning 'self-intersection points in geometric shapes'). It distinguishes from siblings by focusing on kink detection rather than other geometric operations like boolean checks, transformations, or measurements listed among the many sibling tools.
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 detect self-intersections in line or polygon geometries) and specifies the supported GeoJSON types (LineString, MultiLineString, Polygon, MultiPolygon). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the sibling list includes related tools like 'misc_unkink_polygon' that might serve different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does an excellent job. It clearly explains what the tool does (returns all intersection points), discloses dependencies (Turf.js and Node.js environment), error conditions (JavaScript execution failures, timeouts, input format errors), and output format. The only minor gap is lack of information about performance characteristics or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, some information could be more concise - the parameter documentation is quite detailed, and the example includes unnecessary import statements. However, every sentence adds value, and the structure helps navigation.
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 tool's complexity (geometric calculations with multiple parameter types), no annotations, and 0% schema coverage, the description provides exceptional completeness. It covers purpose, parameters, return values, error conditions, dependencies, coordinate systems, and includes a working example. The presence of an output schema helps, but the description still provides valuable context about the GeoJSON format and specific return structure.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. Each parameter (line1, line2, options) gets detailed explanations including types, formats, coordinate systems, examples, and for options - specific fields with defaults. This goes far beyond what the bare schema provides and gives the agent complete understanding of how to use the parameters 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 with specific verbs ('计算两条线的交点' - calculates intersection points of two lines) and resources (GeoJSON features/geometries). It distinguishes itself from siblings by focusing specifically on line intersection calculation, unlike other tools like 'booleans_booleanCrosses' or 'transformation_intersect' which handle different geometric operations.
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 about when to use this tool (for calculating intersection points between lines/polygons) and includes technical prerequisites (valid JSON strings, WGS84 coordinate system). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool performs a geometric operation (splitting), returns a FeatureCollection of LineString features, specifies coordinate system (WGS84), and notes dependencies (Turf.js and Node.js). It also mentions error conditions (JavaScript execution failures, timeouts, input format errors). While comprehensive, it could improve by detailing performance aspects or side effects more explicitly.
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 clear sections (Args, Returns, Raises, Example, Notes), making it easy to parse. It is appropriately sized, with each sentence adding necessary information (e.g., coordinate order, dependencies). However, some redundancy exists (e.g., repeating coordinate system info), and it could be slightly more front-loaded by emphasizing the core purpose earlier without sacrificing clarity.
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 complexity of a geometric splitting operation with no annotations, 0% schema coverage, and an output schema present, the description is highly complete. It covers purpose, parameters, return values, error handling, examples, and technical notes (e.g., JSON format, coordinate system, dependencies). The output schema handles return structure, so the description focuses on operational context, leaving no significant gaps for the agent to understand and use the tool effectively.
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%, so the description must fully compensate. It provides detailed semantics for both parameters: 'line' and 'splitter'. For each, it specifies the type (JSON string), format (GeoJSON LineString for line, any valid GeoJSON feature for splitter), coordinate system (WGS84 with longitude-first), and includes examples. This adds significant value beyond the minimal schema, ensuring the agent understands parameter requirements thoroughly.
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: '用分割器将线段分割为多段' (split a line segment into multiple parts using a splitter). It specifies the exact operation (splitting), the resource (line segment), and the method (using a splitter geometry). Among siblings like misc_line_slice or misc_line_segment, this tool is distinguished by its focus on geometric splitting with a separate splitter feature.
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 you need to split a line segment into multiple parts using a geometric splitter. However, it does not explicitly state when not to use it or name specific alternatives among siblings (e.g., misc_line_slice for slicing along a line, misc_line_segment for creating segments). The usage is implied but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses that the tool returns coordinates in [lng, lat] format, uses WGS84 coordinate system, has a default global bounding box, and depends on Turf.js and Node.js. It also mentions potential exceptions for JavaScript execution failures, timeouts, or input format errors. The only gap is lack of information about randomness characteristics or performance.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded with the core purpose. However, it includes some implementation details (Turf.js, Node.js) that may not be essential for tool selection, and the Python example might be overly specific for an MCP context. Overall efficient but could be slightly more concise.
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 single-parameter tool with no annotations but with output schema, the description is remarkably complete. It covers purpose, parameter semantics, return format, error conditions, examples, and implementation dependencies. The output schema exists, so the description appropriately focuses on explaining the coordinate format rather than duplicating schema information. Nothing essential appears missing.
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%, so the description must fully compensate - which it does excellently. It provides detailed semantics for the single parameter 'bbox': format requirements (JSON string array [minX, minY, maxX, maxY]), default value (global [-180, -90, 180, 90]), examples, and validation rules (must be valid JSON or None). This goes far beyond what the minimal schema provides.
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: '生成随机的地理坐标位置' (generate random geographic coordinate positions). It specifies the verb ('生成随机' - generate random) and resource ('地理坐标位置' - geographic coordinate positions), and distinguishes itself from siblings like random_randomPoint or random_randomPolygon by focusing specifically on coordinate generation rather than geometric features.
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 about when to use this tool: when needing random geographic coordinates within a bounding box. It mentions the default global range and the coordinate system (WGS84). However, it doesn't explicitly contrast with alternatives like random_randomPoint (which generates random point features rather than raw coordinates) or specify 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses that the tool may produce degenerate edges when clipping polygons, depends on Turf.js and Node.js, and can raise exceptions for execution failures, timeouts, or input errors. It doesn't mention rate limits or auth needs, but covers key behavioral aspects adequately.
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 sections (Args, Returns, Raises, Example, Notes), but could be more front-loaded; the core purpose is stated first, but details are extensive. Every sentence adds value, though it's slightly verbose due to comprehensive parameter documentation.
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 2 parameters, 0% schema coverage, no annotations, and an output schema exists, the description is highly complete. It covers input formats, output details, error conditions, dependencies, and examples, leaving no gaps for the agent to understand tool behavior and usage.
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%, so the description must compensate fully. It adds extensive meaning: for 'feature', it specifies GeoJSON types, coordinate order, and provides an example; for 'bbox', it defines the array format and example. This goes far beyond the basic schema, making parameters clear and actionable.
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 with specific verbs ('裁剪' meaning 'clip') and resources ('GeoJSON 特征' meaning 'GeoJSON feature'), specifying it works on lines or polygons. It distinguishes from siblings by focusing on bounding box clipping, unlike other transformation tools like buffer, simplify, or union.
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 input types (GeoJSON features like LineString, Polygon) and coordinate system (WGS84), but does not explicitly state when to use this tool versus alternatives like 'transformation_mask' or 'transformation_intersect' from the sibling list. It provides prerequisites (valid JSON strings) but lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job. It discloses: the underlying library (Turf.js), execution environment (Node.js), error conditions (JavaScript failures, timeouts, format errors), mathematical behavior (first polygon minus second polygon), and output format details. The only minor gap is lack of explicit performance characteristics or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. Every sentence adds value, though the Python example (with asyncio) might be slightly verbose for a tool description. The Chinese/English mixing is efficient for the intended audience.
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 single-parameter geometric transformation tool with no annotations but with output schema, this description is exceptionally complete. It covers purpose, usage, parameters, return values, errors, examples, dependencies, and mathematical behavior. The output schema existence means the description doesn't need to exhaustively document return structure, but it still provides helpful format details.
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?
With 0% schema description coverage (schema only says 'featureCollection' is a string), the description fully compensates. It provides comprehensive parameter documentation: type (JSON string), format (GeoJSON FeatureCollection), coordinate system (WGS84), ordering (longitude first), validation requirements, and a complete example. This adds substantial value beyond the bare 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 tool's purpose: '计算两个多边形的差异' (calculates the difference between two polygons). It specifies the exact operation (difference calculation using Turf.js), distinguishes it from siblings like 'transformation_intersect' or 'transformation_union' by focusing on geometric difference, and provides the mathematical definition ('返回第一个多边形中不在第二个多边形中的部分').
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 calculating geometric differences between two polygons. It specifies input requirements (GeoJSON FeatureCollection with two polygons) and coordinate system (WGS84). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling transformation tools, though the mathematical operation itself implies differentiation from union/intersect tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it explains the tool modifies geometry (implied by '简化'), specifies coordinate system (WGS84), describes algorithm behavior (tolerance and highQuality effects), and notes dependencies (Turf.js, Node.js). It also mentions error conditions (JavaScript failures, timeouts, bad input). No contradictions exist as annotations are absent.
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 sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. However, it includes an extensive example and detailed notes that, while informative, could be slightly verbose. Most sentences earn their place by clarifying usage.
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 complexity (a transformation tool with 2 parameters), no annotations, 0% schema coverage, and an output schema present, the description is highly complete. It covers purpose, parameters, return values, errors, examples, and technical notes, providing all necessary context for an agent to use the tool correctly.
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%, so the description must compensate fully. It does: it details both parameters (geojson and options) with types, formats, examples, and for options, lists optional fields with defaults and effects. This adds significant meaning beyond the basic schema, fully documenting parameter usage.
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: '简化 GeoJSON 几何' (simplify GeoJSON geometry) and specifies it uses Turf.js's simplify method. It distinguishes from siblings by focusing on simplification rather than other transformations like buffer, union, or clipping listed in the sibling tools.
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 simplify GeoJSON geometry) and includes technical prerequisites (valid JSON strings, WGS84 coordinate order). However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools for different geometric operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the conversion formula ('转换公式: 角度 = 距离 / (地球半径 × π / 180)'), dependencies ('依赖于 Turf.js 库和 Node.js 环境'), error conditions ('Raises: Exception: 当 JavaScript 执行失败、超时或输入数据格式错误时抛出异常'), and the return format ('Returns: str: JSON 字符串格式的角度结果'). It lacks details on rate limits or authentication needs, but covers essential operational aspects well.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose. It is appropriately sized for a tool with two parameters and complex behavior, though the example and notes sections are somewhat verbose. Every sentence adds value, such as explaining the formula and dependencies, but it could be slightly more concise in the notes.
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 tool's complexity (involving geographic calculations and external dependencies), no annotations, and no output schema, the description is highly complete. It covers purpose, parameters, return format, errors, examples, and implementation details (formula, dependencies). This provides all necessary context for an agent to invoke the tool correctly without relying on structured fields.
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?
Given 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explicitly documents both parameters: 'distance' with type, description, and example, and 'units' with type, description, valid values, default, and example. This adds significant meaning beyond the minimal input schema, ensuring the agent understands how to use the parameters 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: '将长度转换为角度距离' (convert length to angular distance). It specifies the exact transformation (ground distance to angular distance based on Earth's radius) and distinguishes itself from sibling tools like 'unit_conversion_convertLength' or 'unit_conversion_radiansToLength' by focusing specifically on length-to-degrees conversion for geographic calculations.
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: '常用于地理坐标计算' (commonly used for geographic coordinate calculations). It implies usage in geographic contexts but does not explicitly state when not to use it or name specific alternatives among the many sibling unit conversion tools, such as 'unit_conversion_lengthToRadians' for a similar conversion to radians instead of degrees.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so well. It explains the calculation method ('基于地球半径计算地面距离', '转换公式: 距离 = 弧度 × 地球半径'), dependencies ('依赖于 Turf.js 库和 Node.js 环境'), error conditions ('当 JavaScript 执行失败、超时或输入数据格式错误时抛出异常'), and return format. It doesn't mention rate limits or authentication needs, but those seem unnecessary for this type of calculation tool.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. However, it includes some redundant information like the Python import example which may not be necessary for an MCP tool description, and the Notes section could be more concise. Overall efficient but with minor verbosity.
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 2-parameter calculation tool with no annotations and no output schema, the description provides complete context. It explains the tool's purpose, parameters, return format, error conditions, calculation method, dependencies, and includes a practical example. The description fully compensates for the lack of structured metadata, making the tool's behavior and usage clear.
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?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It clearly explains both parameters: 'radians' as the radian value to convert with type, description, and example, and 'units' as the output distance unit with type, description, valid values, default, and example. This adds significant value beyond the bare schema which only shows types and default.
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: converting radian distances to ground lengths based on Earth's radius. It specifies the verb ('将弧度距离转换为长度' - converts radian distances to lengths) and resource (radian values to length values), distinguishing it from sibling tools like unit_conversion_degreesToRadians or unit_conversion_convertLength by focusing specifically on radian-to-length conversion with Earth radius calculation.
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 spherical geometry calculations where radian distances need to be converted to ground distances. It mentions being '常用于球面几何计算' (commonly used in spherical geometry calculations). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, though the context implies it's for radian-based conversions specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it converts coordinates, specifies input/output formats with examples, notes dependencies (Turf.js and Node.js), and lists error conditions (JavaScript execution failure, timeout, or bad input data). This covers key aspects like transformation logic, dependencies, and error handling.
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 sections for Args, Returns, Raises, Example, and Notes, making it easy to parse. It is appropriately sized with no wasted sentences, though the inclusion of a Python code example might be slightly verbose for a general tool description, but it adds practical value.
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 tool's complexity (coordinate transformation), no annotations, and no output schema, the description is complete. It covers purpose, usage, parameters, return values, errors, examples, and technical notes (dependencies, coordinate systems). This provides all necessary context for an AI agent to use the tool correctly without relying on external structured data.
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 has 0% description coverage, but the description fully compensates by detailing the 'geojson' parameter: it explains the type (string in JSON format), format (any valid GeoJSON object), and provides an example. This adds significant meaning beyond the bare schema, ensuring the agent understands the parameter's purpose 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 the tool's purpose: converting geographic coordinates to Mercator projection coordinates. It specifies the input (WGS84 geographic coordinates) and output (Web Mercator projection coordinates, EPSG:3857), and distinguishes itself from sibling tools like 'unit_conversion_toWgs84' by focusing on projection conversion rather than coordinate system conversion.
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 Web map display (e.g., Google Maps, OpenStreetMap). It implies usage by stating the tool's application, but does not explicitly mention when not to use it or name specific alternatives among siblings, such as other unit conversion tools like 'unit_conversion_convertLength'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it converts coordinates, specifies input/output formats, mentions dependencies (Turf.js and Node.js), and lists error conditions (JavaScript execution failure, timeout, or incorrect input data). This covers key aspects like transformation logic, error handling, and technical dependencies, though it lacks details on performance or rate limits.
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 clear sections (Args, Returns, Raises, Example, Notes), making it easy to navigate. It is appropriately sized with no redundant information. However, some sections like the example could be slightly more concise, but overall, it efficiently conveys necessary details without waste.
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 tool's complexity (coordinate transformation), no annotations, 0% schema coverage, and no output schema, the description provides complete context. It explains the transformation process, input/output formats, examples, error handling, dependencies, and usage notes. This covers all essential aspects for an AI agent to understand and use the tool correctly.
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%, so the description must fully compensate. It provides comprehensive parameter semantics: defines 'geojson' as a JSON string in GeoJSON format with Mercator coordinates, gives an example, and specifies the coordinate system (EPSG:3857). This adds significant meaning beyond the basic schema, ensuring the parameter is well-understood.
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: '将墨卡托投影坐标转换为地理坐标' (converts Mercator projection coordinates to geographic coordinates). It specifies the exact transformation (EPSG:3857 to WGS84) and distinguishes itself from sibling tools like 'unit_conversion_toMercator' which performs the inverse operation, making the purpose specific and differentiated.
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 converting Web Mercator coordinates to WGS84 geographic coordinates. It mentions '常用于坐标系统转换' (commonly used for coordinate system conversion), which gives general usage context. However, it does not explicitly state when not to use it or name specific alternatives, though the sibling list suggests related tools like 'unit_conversion_toMercator'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses key behavioral traits: the calculation is based on Earth's radius, it returns JSON string format, it depends on Turf.js and Node.js environment, and it raises exceptions for JavaScript execution failures, timeouts, or input format errors. This covers important operational context beyond basic functionality.
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 well-structured with clear sections (Args, Returns, Raises, Example, Notes) and every sentence adds value. It's appropriately sized for a tool with 2 parameters and no annotations, with no redundant information. The structure helps quickly locate key information.
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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is complete. It explains what the tool does, how to use parameters, what it returns (including format and example), error conditions, dependencies, and typical use cases. No significant gaps exist for understanding and invoking this tool correctly.
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%, so the description must compensate fully. It provides detailed parameter information: 'distance' is a float value with an example, 'units' is a string with valid values, default value, and example. This adds complete meaning beyond the bare schema, effectively documenting both parameters with type, description, constraints, and examples.
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: '将长度转换为弧度距离' (convert length to radian distance) with specific context of being based on Earth's radius. It distinguishes from sibling tools like 'unit_conversion_convertLength' (general length conversion) and 'unit_conversion_lengthToDegrees' (converts to degrees instead of radians), making the scope and differentiation explicit.
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: '常用于球面几何计算' (commonly used for spherical geometry calculations). It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for understanding its application domain. No misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly describes the tool's behavior: the spatial relationship logic ('完全位于第二个几何图形内部' meaning 'completely inside'), coordinate system requirements ('坐标顺序为 [经度, 纬度] (WGS84 坐标系)' meaning 'coordinate order [longitude, latitude] (WGS84 coordinate system)'), boundary handling, dependencies ('依赖于 Turf.js 库和 Node.js 环境' meaning 'depends on Turf.js library and Node.js environment'), error conditions ('Raises: Exception'), and output format. No contradictions exist.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loaded purpose statement. It's appropriately sized for a tool with 2 parameters and complex behavior. Some redundancy exists (e.g., repeating JSON string format in multiple sections), but overall it's efficient with most sentences adding value.
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 tool's complexity (spatial analysis with specific constraints), no annotations, and 0% schema description coverage, the description is remarkably complete. It covers purpose, parameters, return values (though output schema exists, it still explains the format), error handling, examples, and important behavioral notes (coordinate system, boundary rules, dependencies). Nothing essential appears missing for an agent to use this correctly.
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?
With 0% schema description coverage (schema only shows parameter names and types as strings), the description fully compensates by providing detailed parameter documentation: types, formats, examples, and constraints for both geojson1 and geojson2. It explains they must be valid JSON strings in GeoJSON format with specific coordinate ordering, adding significant value beyond the bare 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 verb ('检查' meaning 'check') and resource ('第一个几何图形是否在第二个几何图形内部' meaning 'whether the first geometry is inside the second geometry'), and distinguishes it from siblings by specifying it's about spatial containment relationships. The title 'booleanWithin' also aligns with this purpose.
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 about when to use this tool (checking if one geometry is completely inside another), and the Notes section clarifies boundary conditions ('边界接触不被视为内部' meaning 'boundary contact is not considered inside'). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools (like booleans_booleanContains or booleans_booleanPointInPolygon).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It thoroughly describes: the exact return format (GeoJSON FeatureCollection), edge case behavior (points on boundaries may be treated as inside or outside depending on implementation), dependencies (Turf.js and Node.js), error conditions (JavaScript execution failures, timeouts, malformed input), and coordinate system requirements (WGS84 with [longitude, latitude] order). This provides comprehensive behavioral context beyond basic functionality.
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core functionality. While comprehensive, it's appropriately sized for a complex spatial operation with many implementation details. Some redundancy exists (e.g., repeating GeoJSON format details), but overall it's efficient given the information density required.
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 tool's complexity (spatial join operation), lack of annotations, and 0% schema coverage, the description provides exceptional completeness. It covers: purpose, parameters with detailed semantics, return format (though output schema exists), error conditions, dependencies, coordinate system, edge cases, and a working example. This fully compensates for the minimal structured metadata available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (schema only shows 'points' and 'polygons' as strings), the description fully compensates by providing detailed parameter documentation. It specifies: exact GeoJSON types required (FeatureCollection with Point features vs Polygon/MultiPolygon features), JSON string format requirements, coordinate order, and concrete examples. This adds substantial value beyond the minimal schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查找多边形内部的点' (find points within polygons). It specifies the exact operation (identifying point features inside polygon features) and distinguishes itself from siblings like 'booleans_booleanPointInPolygon' by performing a spatial join rather than a boolean test, returning actual point features instead of a true/false result.
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 you need to filter points based on polygon containment. It implicitly distinguishes from siblings by focusing on feature extraction rather than boolean evaluation or other spatial operations. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains: the spatial logic ('仅对位于多边形内部的点添加属性'), edge cases ('如果一个点位于多个多边形内，将使用最后一个匹配的多边形属性'), coordinate system requirements ('坐标顺序为 [经度, 纬度] (WGS84 坐标系)'), dependencies ('依赖于 Turf.js 库和 Node.js 环境'), input format requirements ('输入参数 points 和 polygons 必须是有效的 JSON 字符串'), and error conditions ('当 JavaScript 执行失败、超时或输入数据格式错误时抛出异常').
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 clear sections (Args, Returns, Raises, Example, Notes) and front-loads the core purpose. While comprehensive, it's appropriately sized for a complex spatial operation with 4 parameters and no annotations. Every section adds value, though the Example section is quite detailed.
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 tool's complexity (spatial join operation), lack of annotations, and 4 parameters with 0% schema coverage, the description provides complete context. It covers purpose, parameters, return values (with output schema), error conditions, examples, and important behavioral notes. The presence of an output schema helps, but the description still adds valuable context about the spatial logic and edge cases.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. Each of the 4 parameters gets: name, type, format description, examples, and clear explanations of their purpose. The description adds substantial meaning beyond what the bare schema provides, including GeoJSON format specifications and field mapping logic.
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: '为点特征添加多边形属性' (add polygon attributes to point features) and '此功能将多边形特征的属性值关联到位于多边形内部的点特征上' (this function associates polygon feature attribute values to point features inside polygons). It specifies the exact operation (spatial join) and distinguishes it from sibling tools like 'joins_pointsWithinPolygon' by focusing on attribute transfer rather than just spatial containment.
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 you need to transfer attributes from polygons to points based on spatial containment. It doesn't explicitly mention when NOT to use it or name specific alternatives, but the context is sufficiently clear given the sibling tool list includes 'joins_pointsWithinPolygon' which might serve a similar but distinct purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits. It explains the rotation behavior (clockwise positive degrees, around centroid or pivot), mutation options, coordinate system (WGS84), dependencies (Turf.js, Node.js), error conditions (JavaScript failures, timeouts, bad input), and output format. This covers safety, side effects, and operational context comprehensively.
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 sections (Args, Returns, Raises, Example, Notes), making it easy to scan. It is appropriately sized for a complex tool, though some details in the Notes could be integrated earlier for better front-loading. Every sentence adds value.
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 tool's complexity (3 parameters, no annotations, 0% schema coverage), the description is highly complete. It explains inputs, outputs (with output schema present), errors, examples, and notes on dependencies and constraints. This provides all necessary context for an agent to use the tool correctly.
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 schema has 0% description coverage, so the description compensates fully. It details each parameter: geojson (JSON string format, coordinate order, example), angle (float, degrees, direction), and options (JSON string with pivot and mutate fields, defaults, example). This adds essential meaning beyond the bare schema types.
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: '旋转 GeoJSON 对象' (rotate GeoJSON objects). It specifies the method used (Turf.js transformRotate) and distinguishes from siblings by focusing on rotation, unlike other transformation tools like scale, translate, buffer, or simplify in the sibling list.
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 rotating GeoJSON objects, with context on coordinate systems and defaults. However, it lacks explicit guidance on when to use this tool versus alternatives like transformScale or transformTranslate, or when rotation is preferred over other transformations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job. It discloses: the tool uses Turf.js library and Node.js environment, requires valid JSON string input, specifies coordinate system (WGS84 with longitude first), describes what happens (geometric union of two polygons), and mentions potential exceptions (JavaScript execution failures, timeouts, input format errors). This provides comprehensive behavioral context beyond basic functionality.
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 clear sections (Args, Returns, Raises, Example, Notes) but could be more concise. Some information in the Notes section overlaps with earlier content. However, every sentence adds value, and the structure helps navigation. The front-loaded purpose statement is clear.
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 1 parameter with 0% schema coverage, no annotations, and no output schema, the description provides complete context. It explains the tool's purpose, parameter requirements, return format with examples, error conditions, dependencies, and coordinate system details. For a transformation tool with minimal structured metadata, this description is comprehensive.
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?
With 0% schema description coverage (schema only says featureCollection is a string), the description fully compensates. It provides detailed parameter semantics: featureCollection must be a JSON string in GeoJSON FeatureCollection format containing exactly two Polygon features, specifies coordinate order, provides a complete example, and notes it must be valid JSON. This adds substantial meaning beyond the bare 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 tool's purpose: '合并两个多边形' (merge two polygons) and specifies it uses Turf.js union method. It distinguishes from siblings like transformation_difference or transformation_intersect by focusing on union/merge operations. The description is specific about the verb (merge/union) and resource (polygons).
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 about when to use this tool: for merging two polygons into their geometric union. It doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools, but the context is sufficiently clear for an agent to understand this is for polygon union operations rather than intersection, difference, or other transformations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![turf-mcp MCP server](https://glama.ai/mcp/servers/es3154/turf-mcp/badges/card.svg)](https://glama.ai/mcp/servers/es3154/turf-mcp)

Score Badge

Copy to your README.md:

[![turf-mcp MCP server](https://glama.ai/mcp/servers/es3154/turf-mcp/badges/score.svg)](https://glama.ai/mcp/servers/es3154/turf-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/es3154/turf-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server