aggregation_clustersDbscan

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.

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.

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.

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.

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.

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.