cesium-mcp

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

Annotations indicate idempotentHint=false, but the description doesn't explain failure modes (e.g., duplicate ID errors), persistence guarantees, or coordinate system details. With safety flags covered by annotations, the description adds minimal 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.

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

Single sentence with zero redundancy. However, extreme brevity leaves gaps for a 6-parameter creation tool with nested objects.

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?

Incomplete for a creation tool with no output schema. The description doesn't indicate return values (entity ID? success boolean?), visibility scope, or interaction with the optional 'id' parameter.

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 coverage is 83%, so parameters like 'color' (overlay), 'scale', and position coordinates are well-documented in the schema. The description implicitly references 'position' and 'image' but adds no syntax guidance beyond the schema.

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 states a clear action ('添加'/'add') and resource ('图片图标'/'image icon') at a specific location. It loosely distinguishes from siblings like addLabel (text) and addModel (3D), though it could clarify the difference from addMarker.

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?

No guidance on when to use this versus similar tools like addMarker or addLabel. Given the crowded sibling namespace of entity-creation tools, explicit differentiation criteria are missing.

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

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

Annotations indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false), but the description adds minimal behavioral context beyond this. It fails to disclose idempotency characteristics, error conditions (e.g., duplicate IDs), or whether the box persists as an entity in the scene graph.

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 extremely concise (9 characters), which avoids verbosity but is underweight for a tool with 8 parameters including nested geospatial objects. The information density is high but insufficient for the complexity of the operation.

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?

For a complex 3D geospatial tool with nested coordinate objects and no output schema, the description is incomplete. It lacks coordinate system context (WGS84 implied by schema but not stated), return value information, and scene graph persistence details that are critical for correct agent operation.

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?

With schema coverage at only 13% (material parameter only), the description partially compensates by highlighting '尺寸' (dimensions) and '材质' (material) as key concepts. However, it omits critical required parameter 'position' (a complex geospatial object with longitude/latitude/height) and optional parameters like orientation, leaving significant semantic gaps.

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 '添加带尺寸和材质的3D盒体' (Add a 3D box with dimensions and material) uses a specific verb (添加/add) and identifies the specific geometric primitive (盒体/box), distinguishing it from sibling shape tools like addCylinder or addCorridor. However, it lacks explicit contrast with these alternatives.

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 provides no guidance on when to use this tool versus other geometric primitives (addCorridor, addWall, etc.), nor does it mention prerequisites like coordinate system requirements or the relationship to updateEntity/removeEntity for lifecycle management.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, which the description doesn't contradict. It adds semantic context that a corridor represents a 'path with width' (helping agents understand the spatial model), but fails to mention side effects, return values, or coordinate reference systems.

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?

Extremely compact single sentence with parenthetical clarification. Front-loaded with action verb. While efficient, the brevity is insufficient for a 6-parameter tool with complex nested coordinates, lacking structural room for parameter hints.

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?

Inadequate for tool complexity. With 6 parameters including coordinate arrays and extrusion height, plus no output schema, the description should explain the 3D geometry behavior (e.g., how width extrudes along the path) and return values. Currently leaves critical implementation details to speculation.

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 low (33%). The description partially compensates by stating this is a 'path' (路径), which helps interpret the positions array structure, and emphasizes width. However, it doesn't explain extrudedHeight (vertical extension), material application, or ID semantics, leaving critical parameters undocumented.

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?

States specific action (添加/add) and resource (走廊/corridor), with parenthetical clarification distinguishing it from a simple path by emphasizing 'with width' (带宽度的). This provides basic differentiation from sibling addPolyline, though could explicitly contrast with wall or polygon siblings.

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?

Provides no guidance on when to prefer addCorridor over geometrically similar siblings like addPolyline (line without volume), addWall (vertical plane), or addPolygon (filled area). No mention of prerequisites like requiring a specific coordinate system or entity hierarchy.

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

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

Annotations already indicate this is a write operation (readOnlyHint: false, destructiveHint: false) and non-idempotent (idempotentHint: false), but the description adds no behavioral context—such as what entity gets created, whether it persists to a scene graph, or that multiple invocations create duplicate objects. With low schema coverage, the description fails to carry its share of the behavioral disclosure burden.

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 single-sentence description is grammatically concise and front-loaded, but severely undersized for the tool's complexity (9 parameters, nested objects, no output schema). Conciseness here manifests as under-specification rather than efficient communication—every word earns its place, but too few words are present.

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?

For a 9-parameter tool with nested geospatial coordinates (longitude/latitude), low schema coverage, and no output schema, the description is materially incomplete. It lacks explanation of the coordinate reference system, the entity ID lifecycle, the outline feature, and what distinguishes a cylinder from a cone in parameter terms (beyond the vague mention of both shapes).

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?

With only 44% schema coverage (descriptions present only for length, topRadius, bottomRadius, and material), the description must compensate but does not. It fails to explain the critical id/name parameters for entity identification, the outline boolean, or the nested position object structure (longitude/latitude/height). Mentioning 'cone' implies the radius relationship but insufficiently compensates for the undocumented parameters.

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 Chinese description '添加圆柱体或圆锥体' (Add cylinder or cone) provides a specific verb and resource, clearly distinguishing this from sibling shape tools like addBox or addBillboard. It accurately indicates the tool creates both cylinders and cones (via radius parameters), which is essential functionality. However, it omits the 3D/geospatial context implied by the coordinate system in the schema.

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 provides no guidance on when to select this tool versus other geometry primitives (e.g., addBox for rectangular shapes, addCorridor for path-based volumes). With 40+ sibling tools including many add* variants, the absence of selection criteria or prerequisites leaves the agent without decision support.

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

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

While annotations indicate this is a write operation (readOnlyHint:false) and non-destructive, the description adds no behavioral context beyond the name. It does not disclose if the created ellipse persists in a scene graph, what coordinate system is used, or return value semantics despite the lack of output schema.

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 2-character description is technically brief, but this represents under-specification rather than efficient conciseness. No structural organization or front-loaded critical information—just a minimal label.

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?

For a tool with 9 parameters including nested objects and no output schema, the description is grossly incomplete. It omits expected behavior (e.g., whether ID is auto-generated or required), rendering constraints, and interaction with the globe/3D scene.

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?

With only 33% schema description coverage (only semiMajorAxis and semiMinorAxis defined), the description fails to compensate for undocumented parameters like 'extrudedHeight', 'outline', or the nested 'position' object requirements. No syntax guidance or unit clarifications beyond the schema.

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 '添加椭圆' (Add Ellipse) provides a basic verb+resource statement but is essentially a translation of the tool name. It fails to distinguish from geometric siblings (addBox, addCylinder, addPolygon, etc.) or clarify when an ellipse is the appropriate choice over other shapes.

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?

No guidance provided on when to use this tool versus other 'add' shape tools, prerequisites for the position coordinates, or whether the ellipse is filled vs. outlined by default. The description offers zero contextual cues for tool selection.

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

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

Annotations cover safety profile (readOnly=false, destructive=false). Description adds valuable behavioral context about supported geometry types (Point/Line/Polygon) and rendering modes (color/choropleth/category) that annotations don't provide. Does not mention idempotency behavior (covered by annotation idempotentHint=false).

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?

Single, compact sentence with parenthetical details. Front-loaded with core action ('添加 GeoJSON 图层'), followed by capability specifications. Zero redundancy - every character conveys specific capability or constraint.

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 tool's complexity (4 params, nested objects, no output schema), the description adequately covers the layer creation behavior, auto-generation of ID (implied by schema), and rendering capabilities. Could mention return value or layer lifecycle management reference.

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 has 100% description coverage (baseline 3). Description adds semantic value by specifying which geometry types the data parameter accepts (Point/Line/Polygon) and clarifying the rendering capabilities of the style parameter (分级/choropleth, 分类/category) beyond the schema's field listing.

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?

Description clearly states the specific action (添加/add), target resource (GeoJSON layer), and distinguishes from siblings by specifying it handles GeoJSON data with Point/Line/Polygon geometries, unlike primitive-specific tools like addBox or addMarker.

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 GeoJSON specificity but lacks explicit when-to-use guidance versus alternatives like addPolygon or addPolyline for individual geometries. No prerequisites or exclusions are mentioned.

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

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

Annotations indicate this is a write operation (readOnlyHint: false) and non-destructive (destructiveHint: false). The description adds valuable semantic context that this generates a visualization layer (热力可视化), clarifying the rendering behavior. It does not address idempotency (whether multiple calls create duplicate layers) or persistence details, but covers the core behavioral trait of the visualization generation.

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 a single, dense sentence in Chinese with a parenthetical clarification. It front-loads the primary action ('添加热力图图层') and efficiently packs the technical specification (GeoJSON point basis, heat visualization output) into the parenthetical. No redundant words or phrases.

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 tool's medium complexity (adding a visualization layer), the 100% schema coverage, and present annotations indicating safety profile, the description provides sufficient context. It appropriately omits return value documentation (no output schema exists per rules), though it could mention whether the operation creates a named layer reference or handles updates.

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?

With 100% schema description coverage, the schema already documents both parameters (data as GeoJSON Point FeatureCollection, radius in pixels). The description reinforces the GeoJSON point data requirement but does not add syntax details, format constraints, or usage examples beyond what the schema provides, meeting the baseline for high-coverage schemas.

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 action (添加/add), resource (热力图图层/heatmap layer), and specific input type (GeoJSON point data). It distinguishes from siblings like addGeoJsonLayer or addMarker by specifying the heat visualization output (热力可视化), clarifying this is for density visualization rather than raw geometry rendering.

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 context by specifying GeoJSON point data as the input format, suggesting when to use the tool. However, it lacks explicit guidance on when to choose this over addGeoJsonLayer (which also handles GeoJSON) or other visualization tools, and mentions no prerequisites or exclusions.

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

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

Annotations establish this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false) and not idempotent. The description adds context that labels display attribute values from the data, but does not clarify whether the tool modifies the input GeoJSON object in-place, returns a new object, or creates persistent map entities. With annotations covering the safety profile, the description provides moderate additional 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.

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

The description is a single efficient sentence with zero waste. It front-loads the core action ('添加文本标注') and uses the parenthetical to add the key differentiator (displaying attribute values) without verbosity. Every element earns its place.

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?

For a tool with 3 parameters (including nested style objects) and no output schema, the description adequately covers the core function but leaves gaps. It does not describe return values, side effects on the map state, or how the label behaves when the underlying data updates. Given the annotation coverage and schema completeness, the description provides minimum viable context but could be more comprehensive.

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?

With 100% schema description coverage, the schema fully documents the data (GeoJSON FeatureCollection), field (attribute name), and style parameters. The description adds conceptual meaning by connecting the 'field' parameter to the purpose of 'displaying attribute values,' but does not provide additional syntax, format constraints, or examples beyond what the schema already specifies. Baseline 3 is appropriate when schema carries the full documentation burden.

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 specific action (添加/add), resource type (文本标注/text labels), and target (GeoJSON要素/features). The parenthetical '(显示属性值)' clarifies the specific function—displaying attribute values—which distinguishes this from sibling tools like addMarker or addBillboard that add graphical icons rather than text labels derived from data fields.

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 context by mentioning '显示属性值' (display attribute values), suggesting when to use this tool (when needing to visualize property data on features). However, it lacks explicit guidance on when to choose this over similar annotation tools like addMarker or addBillboard, or prerequisites such as requiring existing GeoJSON data with the specified attribute field.

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

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

Annotations indicate this is a write operation (readOnlyHint=false, destructiveHint=false). The description adds valuable context that the tool returns a layerId for later reference, but does not clarify failure modes, idempotency behavior (despite idempotentHint=false), or side effects beyond the return value.

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 single-sentence description efficiently packs the location constraint, action, and return value purpose with zero redundancy. Information is front-loaded and every clause serves a distinct 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?

Despite lacking an output schema, the description explicitly documents the return value (layerId), which is critical for a creation tool. With full parameter coverage in the schema and clear purpose statement, the definition is functionally complete, though it could mention the auto-generated ID behavior described in the schema.

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?

Input schema has 100% description coverage with clear Chinese descriptions for all 6 parameters including ranges and formats. The description does not repeat parameter details, which is appropriate given the complete schema documentation.

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 action (添加/add), resource (标注点/marker), and scope (指定经纬度/at specified coordinates). However, it does not explicitly differentiate from similar sibling tools like 'addLabel' or 'addBillboard', relying on the tool name to convey the distinction.

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 mentions the return value (layerId) is 'for subsequent operations,' implying a persistent object creation pattern, but provides no explicit guidance on when to choose this tool over siblings like 'addLabel' or 'addBillboard'.

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

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

Annotations indicate this is a non-readOnly operation, while the description adds crucial behavioral context: it returns an entityId (essential for later update/removeEntity calls) and specifies the coordinate system. It does not mention persistence characteristics or that multiple calls create multiple entities (idempotentHint: false).

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?

Single sentence packs action, location, resource type, format restriction, and return value with zero waste. Front-loaded with the core operation ('在指定经纬度放置') followed by resource specifics and return value.

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 rich parameter set (position, orientation, scale) and lack of output schema, the description adequately covers the essentials by mentioning the returned entityId. Could be improved by noting the entity can be manipulated via updateEntity/removeEntity siblings, but sufficient for basic invocation.

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?

With 100% schema description coverage, the schema fully documents all 9 parameters including orientation (roll/pitch/heading) and scale. The description references '经纬度' (latitude/longitude) and model URL implicitly but adds no semantic details beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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?

Description clearly states the specific action (place/放置), resource (3D model), format constraint (glTF/GLB), and location method (latitude/longitude). The mention of glTF/GLB effectively distinguishes this tool from sibling primitives like addBox or addMarker.

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?

While the glTF/GLB format mention implies usage for complex 3D assets versus simple primitives, there is no explicit guidance on when to choose this over addBox/addBillboard siblings, nor mention of prerequisites like URL accessibility or valid coordinate ranges.

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

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

Annotations indicate this is a write operation (readOnlyHint: false) and non-destructive. The description adds critical behavioral context not present in annotations: it explicitly states the return value is an 'entityId,' which is essential for downstream operations like removeEntity or updateEntity. However, it omits whether the operation is idempotent or if duplicate calls create multiple entities.

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 a single, dense sentence that front-loads the action (adds polygon), specifies the domain (map), clarifies the geometric nature (area, boundary), and states the return value (entityId). No words are wasted, and the structure is appropriate for the information density.

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 absence of an output schema, the description appropriately discloses the return of entityId, which is crucial for the entity lifecycle in this API (referencing siblings like removeEntity). However, it could improve by noting that created entities persist until explicitly removed, or clarifying the coordinate system expectations for the height parameter.

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?

With 100% schema description coverage, the input parameters are fully documented in the schema itself (including coordinate format, color defaults, and extrusion options). The description adds minimal semantic value beyond the schema, merely contextualizing coordinates as defining an 'area, boundary' without elaborating on parameter interactions or validation rules.

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 adds a polygon region (area, boundary) to the map and returns an entityId. It identifies the specific geometry type, distinguishing it from siblings like addEllipse or addBox through the explicit mention of 'polygon area,' though it lacks explicit comparative guidance against similar geometric primitives.

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 provides no guidance on when to select this tool over alternatives like addRectangle (for rectangular areas) or addEllipse (for circular regions), nor does it mention prerequisites such as coordinate format requirements or when 3D extrusion is appropriate.

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

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

Annotations establish this is a write operation (readOnlyHint: false) and non-destructive (destructiveHint: false). The description adds valuable behavioral context by specifying the return value 'entityId', which is critical given the absence of an output schema, though it omits details about coordinate validation or entity persistence.

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 a single, efficient sentence of 23 characters that front-loads the action, specifies the target object, and states the return value without redundant words or repetition of the tool name.

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?

For a creation tool with no output schema, the description adequately compensates by documenting the return value (entityId). However, given the availability of sibling tools like removeEntity and updateEntity, it could be more complete by noting how the returned ID is used for lifecycle management.

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?

With 100% schema description coverage, all 5 parameters (coordinates, color, width, label, clampToGround) are fully documented in the schema itself. The description does not need to duplicate these semantics, warranting the baseline score.

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 states the specific action '添加折线' (add polyline) and resource type, while the parenthetical '（路径、线段）' clarifies the geometry type to distinguish from sibling shape tools like addPolygon or addMarker. It also documents the return value 'entityId', providing essential contract information.

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 parenthetical '(路径、线段)' implies the intended use case for drawing routes and line segments, but the description lacks explicit guidance on when to select this tool over similar linear geometry siblings like addCorridor or addWall present in the tool set.

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

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

Annotations indicate non-read-only and non-destructive behavior, but the description adds no behavioral context beyond this, such as whether the rectangle creates a persistent entity (relevant given removeEntity/updateEntity siblings), idempotency, or side effects.

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?

Extremely brief (5 characters), front-loaded with the core action, but arguably too minimal to be useful. No redundant text, yet insufficient substance for the tool's complexity.

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 8 parameters including complex nested coordinates and styling options, plus no output schema, the description is inadequate. It fails to explain the rectangle's relation to the entity system, return behavior, or 3D extrusion capabilities implied by the schema.

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 critically low at 13% (1 of 8 parameters). With such poor coverage, the description must compensate by explaining the nested coordinates object (west/south/east/north), extrudedHeight behavior, or material options, but provides no parameter guidance whatsoever.

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 states the basic action (add) and resource (rectangle) with geographic context ('按地理范围'), but fails to differentiate from sibling tools like addBox, addPolygon, or addEllipse which all add geometric shapes to the scene.

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?

No guidance provided on when to use this tool versus alternatives (e.g., addPolygon for arbitrary shapes vs. addRectangle for axis-aligned extents), prerequisites, or required coordinate system/CRS.

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

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

Annotations already declare this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false). The description adds '沿路径' (along path), clarifying the placement behavior. However, it omits the implications of idempotentHint=false (allows duplicate walls) and fails to describe return values or side effects given the lack of output schema.

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 extremely terse (5 characters), which prevents verbosity but crosses into under-specification. It is front-loaded with the core action, yet one sentence would not suffice to document 8 parameters with complex height arrays.

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 8 parameters including nested coordinate objects and dual height arrays, plus no output schema, the minimal description provides insufficient context. It fails to explain return values, error conditions, or the relationship between the path positions and height arrays necessary to successfully construct a wall.

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?

With only 13% schema coverage (just 'material' described), the description must compensate significantly. While 'along path' implies the positions parameter, it completely omits explanation of the distinctive height parameters (maximumHeights/minimumHeights arrays) which are critical for wall geometry, nor does it clarify the outline boolean or ID parameters.

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 action (add) and resource (wall), and specifies the path-based placement method. However, it fails to distinguish from geometrically similar siblings like addCorridor or addPolyline, which also use path-based positioning.

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?

No guidance provided on when to use this tool versus alternatives (e.g., addCorridor for extruded shapes or addPolygon for vertical surfaces), nor any mention of prerequisites like requiring valid coordinate arrays or when walls are appropriate versus other primitives.

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

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

While annotations indicate non-destructive state mutation (readOnlyHint=false, destructiveHint=false), the description adds no behavioral context beyond the action names, such as state transition rules, error handling for invalid entityIds, or idempotency concerns.

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?

Extremely brief at 6 characters, conveying the essential function without redundancy. However, it may be overly terse for adequate agent comprehension given the lack of schema documentation.

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?

For a state-modification tool with zero schema descriptions and no output schema, the description is insufficient. Critical context missing includes the specific entity type expected for entityId and the effect of calling play on an already-playing animation.

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?

With 0% schema coverage, the description must compensate for undocumented parameters. It implicitly clarifies the 'action' parameter via the play/pause mention but entirely omits what 'entityId' represents (animation ID vs. entity ID) or its format 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 identifies the core action (play/pause) and resource (animation), matching the enum values in the schema. However, it does not explicitly differentiate from siblings like playTrajectory or createAnimation.

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?

No guidance provided on when to use this versus alternatives (e.g., playTrajectory), nor does it mention prerequisites such as requiring an existing animation created via createAnimation.

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

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

Annotations indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false). The description adds scope by listing what gets configured (time range, speed, animation state), but misses critical behavioral context: all 6 parameters are optional, suggesting partial configuration is possible, yet the description doesn't mention this or explain what happens to unspecified values.

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?

Extremely efficient: single sentence with verb-fronted structure. The parenthetical efficiently summarizes the 6 parameter purposes without verbosity. Every element earns its place.

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?

While the description covers basic functionality, it lacks important context for a configuration tool with all-optional parameters: it doesn't mention that partial updates are possible, doesn't explain the clockRange enum values (UNBOUNDED/CLAMPED/LOOP_STOP), and provides no indication of side effects or return values (though no output schema exists).

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?

With 67% schema coverage, the description adds valuable semantic grouping by categorizing parameters into 'time range', 'speed', and 'animation state', helping users understand the logical groupings beyond the raw schema. However, it doesn't fully compensate for the two undocumented parameters (clockRange, shouldAnimate) by explaining their semantics.

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 configures the Cesium clock and lists the specific configurable aspects (time range, speed, animation state) in the parenthetical. However, it does not explicitly distinguish this tool from the sibling 'controlAnimation' tool, which could cause selection confusion.

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?

No explicit when-to-use or when-not-to-use guidance is provided. Given the presence of sibling tools like 'controlAnimation', 'createAnimation', and 'playTrajectory', the description should clarify whether this configures static clock settings versus controlling active playback, but it does not.

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

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

Annotations indicate this is a write operation (readOnlyHint=false) and non-destructive. The description adds valuable behavioral context by specifying this is 'time-based' (基于时间) and involves movement along a path, hinting at interpolation behavior. However, it omits whether the animation starts immediately, persists after completion, or what happens if the entityId already exists.

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 single-sentence description is front-loaded with the action verb and contains no redundant or wasted words. The parenthetical clarification efficiently conveys the animation mechanic. However, given the tool's complexity (7 parameters, nested objects), extreme breveness becomes a limitation rather than a virtue.

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?

For a 7-parameter animation tool with nested waypoint objects, low schema coverage (29%), and no output schema, the description is insufficiently complete. It fails to specify return values, coordinate reference systems, time format expectations (absolute vs. relative), or how model URLs/presets interact with entity creation.

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?

With schema coverage at only 29%, the description compensates by clarifying the semantic relationship between 'path' (路径) and the waypoints parameter, and 'entity' (实体) and entityId. However, it fails to elaborate on other parameters like model, loop, pathColor, and modelScale, leaving five of seven parameters semantically underspecified.

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 core action (创建/create) and resource (路径动画/path animation), specifying the mechanism (基于时间/time-based) and what happens (实体沿路径运动/entity moves along path). It effectively distinguishes from siblings like controlAnimation, removeAnimation, and listAnimations by focusing on creation.

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?

No explicit guidance on when to use this tool versus alternatives like updateAnimationPath or playTrajectory. While 'create' implies initial creation, there is no mention of prerequisites (e.g., requiring an existing entity) or when to prefer this over other animation methods.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context about the animation transition, but does not disclose additional traits like interruption behavior, animation curves, or completion signaling beyond what the structured fields provide.

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?

Single sentence efficiently delivers the core action and distinguishing feature (animation) without redundancy. Information is front-loaded with the verb '飞行到' (fly to), making it immediately clear what the tool does.

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 rich input schema (100% coverage) and present annotations, the description provides sufficient context for tool selection. Minor gap: lacks explicit mention of coordinate reference system (WGS84 implied by ranges) or return behavior (void vs promise), but adequate for invocation.

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?

With 100% schema description coverage, the schema fully documents all 6 parameters including defaults (pitch, height, duration). The description mentions the required lat/long coordinates but adds no semantic detail beyond the schema, meeting the baseline for high-coverage schemas.

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 specific action (fly to), target resource (longitude/latitude position), and key behavioral trait (animated transition) that distinguishes it from sibling tools like setView (instant) or zoomToExtent (bounding box).

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 mention of '带动画过渡' (with animated transition) provides implicit guidance for when to use this tool (smooth camera movements), but lacks explicit when/when-not guidance or named alternatives (e.g., 'use setView for instant camera jumps instead').

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, establishing safety. The description adds valuable context about what data is returned (经纬度、高度、角度) since no output schema exists. It does not mention coordinate systems or units, but adequately supplements the structured annotations.

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?

Single, efficient sentence with parenthetical elaboration of return values. Information is front-loaded with the action verb, and every character earns its place. No redundancy or unnecessary verbosity.

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 tool's simplicity (zero params, read-only) and strong annotations, the description is nearly complete. The parenthetical list of returned attributes compensates for the missing output schema. A minor gap is the lack of units or coordinate reference system specification.

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?

The tool accepts zero parameters, which per the rubric establishes a baseline of 4. With no input requirements, there are no semantic gaps to fill regarding parameter meaning or format.

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 uses a specific verb (获取/get) and resource (相机视角/camera view), clarifying that this retrieves current camera state. The mention of 'current' (当前) and specific attributes (longitude, latitude, height, angle) distinguishes it from sibling mutation tools like setView, flyTo, and lookAtTransform.

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?

While the name and description make the tool's function obvious, there is no explicit guidance on when to use this versus setView or flyTo, nor any mention of prerequisites (e.g., requiring an initialized map view). Usage is implied by the return value specification but not stated explicitly.

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

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

With annotations indicating idempotent=true and destructive=false, the description adds minimal behavioral context. It fails to clarify whether highlighting is additive (accumulates with previous calls) or replacement-based, how long highlights persist, or how they interact with existing layer styles.

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?

Single sentence of 8 characters with zero redundancy. While efficient, it borders on under-specification for a tool with behavioral complexity (temporary vs. permanent highlighting).

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?

Basic purpose is covered and annotations provide safety hints, but the description omits critical lifecycle details: whether highlights persist across sessions, how to clear them, and the visual effect mechanism (overlay vs. style modification).

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 coverage is 100% with clear Chinese descriptions for all three parameters (layerId, color, featureIndex). The description doesn't discuss parameters, but with complete schema documentation, no additional parameter semantics are required from the description text.

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 states the specific action (高亮/highlight) and target (指定图层的要素/features of specified layer). However, it doesn't clarify how this differs from persistent styling tools like updateLayerStyle or whether this targets visual selection vs. data modification.

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?

No guidance on when to use this versus updateLayerStyle or other visualization tools. Missing information about prerequisites (e.g., layer must exist) or when not to use it (e.g., for permanent style changes).

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the description carries the burden of scoping behavior. The 'active' qualifier adds crucial behavioral context not present in the name or annotations, indicating a filter for currently running animations rather than all defined animations. However, it omits return format details.

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 extremely concise at 7 characters with zero redundant words. It front-loads the essential information (action + scope + resource) without boilerplate.

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?

For a simple read-only enumeration tool with no output schema, the description provides sufficient context for selection. The 'active' qualifier adequately scopes the operation. Missing return value details are acceptable given the tool's straightforward purpose, though mentioning the return type would improve completeness.

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?

With 0 parameters, the baseline score is 4 per the evaluation rules. The description correctly implies no filtering parameters are needed (lists 'all' active animations), which aligns with the empty input schema.

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 Chinese description '列出所有活跃的动画' clearly states the specific verb (列出/list), resource (动画/animations), and scope (活跃的/active). It implicitly distinguishes from siblings like createAnimation, removeAnimation, and updateAnimationPath by specifying a read-only listing operation versus mutation or control.

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?

While the verb choice implicitly suggests usage (listing vs creating/removing), there is no explicit guidance on when to use this versus siblings like controlAnimation (which likely also requires active animations) or prerequisites such as needing animations to exist first.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context by disclosing the specific fields returned (ID, name, type, visibility), which compensates for the missing output schema. Could improve by mentioning if results are ordered or real-time.

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?

Single efficient sentence with parenthetical elaboration. Front-loaded with action and resource, zero waste. Every element earns its place: the parenthetical return value specification is essential given no output schema exists.

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?

For a zero-parameter tool with rich safety annotations and no output schema, the description is nearly complete. It compensates for missing output schema by documenting return fields. Minor gap: doesn't specify ordering, pagination, or if hidden layers are included (though 'visibility' field suggests they are).

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?

Input schema has 0 parameters, establishing baseline 4. Description appropriately requires no parameter explanation given the empty schema, though it implies (via 'current') that the tool uses implicit context (current view/state) rather than requiring explicit filtering parameters.

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?

Description uses specific verb '获取' (get/retrieve) with resource '图层' (layers), specifies scope '当前所有' (all current), and distinguishes from sibling modification tools like removeLayer/updateLayerStyle/addGeoJsonLayer by being clearly read-only. It also clarifies what data is returned (ID, name, type, visibility).

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?

No explicit when-to-use guidance or comparison to alternatives like listAnimations. While usage is implied by the naming and the clear purpose statement, it lacks explicit guidance such as 'use this before modifying layers to check current state' or differentiation from other query tools.

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

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

Annotations declare the non-read-only, non-destructive nature of the operation. The description adds valuable context about the content type (building massing, city-scale data) but omits behavioral details like streaming/LOD behavior, memory implications, or error handling when tileset.json is unreachable.

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?

Single sentence with zero redundancy. The core action and resource are front-loaded, with parenthetical examples efficiently appended to disambiguate the specific use case.

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 complete schema annotations (100% coverage) and presence of annotations object disclosing safety hints, the description is sufficiently complete. A minor gap is the lack of mention that this creates a layer (referencing the 'id' parameter semantics), though this is inferable from the schema.

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 100%, documenting all 5 parameters including units (meters) and tuning hints (smaller value = finer). The description provides no additional parameter semantics beyond the schema, warranting the baseline score.

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?

Description states the specific action '加载' (load) and target resource '3D Tiles 数据集', with concrete examples (building massing, city models) clarifying the data type. Distinguishes implicitly from siblings like loadTerrain (elevation) and addModel (individual entities) via the 'city model' examples, though it doesn't explicitly name those alternatives.

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?

No explicit guidance on when to use this tool versus similar geometry-loading siblings (e.g., addModel for single glTF models vs. 3D Tiles for streaming datasets). No mention of prerequisites like URL accessibility or CORS requirements.

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

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

Annotations indicate non-read-only, non-destructive operation. Description adds specificity about imagery layer types supported but does not clarify behavioral traits like idempotency (annotations indicate false), what happens if duplicate IDs are provided, or whether the layer is immediately visible upon loading.

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?

Single sentence structure is efficiently front-loaded with no redundant text. However, extreme brevity leaves room for additional context (e.g., return behavior, layer lifecycle) given the tool's 6-parameter complexity and multiple protocol support.

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?

Adequate for basic operation given the schema completeness, but lacks guidance on protocol-specific requirements (e.g., WMS requires layerName while XYZ does not) and does not mention relationship with listLayers/removeLayer lifecycle management despite being a load operation with idempotentHint=false.

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 100% (all 6 parameters documented), establishing baseline 3. Description does not augment parameter semantics (e.g., explaining that layerName is required only for WMS/WMTS per schema patterns, or that id defaults to random if unspecified), but no additional compensation needed given complete schema coverage.

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?

Description provides specific verb (加载/load), resource (影像服务图层/imagery service layer), and precise scope via parenthetical enumeration of supported formats (WMS/WMTS/XYZ/ArcGIS MapServer). Clearly distinguishes from siblings like load3dTiles, loadTerrain, and addGeoJsonLayer through the format specification.

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?

Lists supported service types (WMS/WMTS/XYZ/ArcGIS MapServer) which implies usage context, but lacks explicit when-to-use versus alternatives (e.g., when to use setBasemap instead) or prerequisites (e.g., URL accessibility requirements). No exclusion criteria provided.

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

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

Annotations declare idempotentHint=true and destructiveHint=false, establishing safety. The description adds the 'switch' (切换) behavior, implying terrain replacement. However, it omits details about what happens to existing entities when terrain changes or whether the operation is synchronous.

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 a single, efficiently structured sentence of 18 characters. It front-loads the action ('加载或切换') and places the optional provider list parenthetically where it doesn't obstruct the primary purpose statement. Zero waste.

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?

For a terrain loader with clear scope and no output schema, the description adequately covers the essential behavior and options. It appropriately relies on the 100% schema coverage for parameter details and annotations for behavioral hints. Could be improved by noting that '切换' implies unloading previous terrain.

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?

With 100% schema description coverage, the schema already documents all parameters clearly. The description provides a useful grouping of the provider enum values and custom URL option in the parenthetical, but adds minimal semantic depth beyond the structured schema definitions. Baseline 3 is appropriate given the schema carries the full burden.

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 action ('加载或切换' / load or switch) and target resource (terrain), and explicitly enumerates the supported provider types (flat, ArcGIS, CesiumIon, custom URL). This effectively distinguishes it from sibling tools like load3dTiles (3D models), loadImageryService (imagery), and setBasemap (basemap).

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 parenthetical provider list, indicating which values to use for different terrain sources. However, it lacks explicit guidance on when to choose this over loadImageryService or load3dTiles, and does not mention prerequisites like needing a valid Cesium Ion token for cesiumion provider.

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

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

Annotations already indicate the operation is idempotent and non-destructive. The description adds valuable behavioral context by specifying the ENU coordinate system and orbit-style camera behavior, which clarifies how the camera will be positioned relative to the target. It does not mention transition animation or timing details.

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 a single efficient sentence with parenthetical elaboration. It front-loads the core concept (orbit camera look-at) and follows with coordinate system details. No redundant or wasted text.

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?

For a camera positioning tool with six parameters and no output schema, the description adequately covers the coordinate system (ENU) and camera behavior type. It appropriately relies on annotations for safety profile (idempotent, non-destructive). It could be improved by mentioning whether the camera transition is instantaneous or animated.

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?

With 100% schema description coverage, the schema already documents all six parameters individually. The description adds semantic context by grouping heading/pitch/range as a cohesive orientation system and mentioning ENU transform, but does not add validation constraints, units clarification, or inter-parameter relationships beyond the schema.

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 this performs an orbit-style camera look-at operation using ENU coordinates with heading/pitch/range parameters. It identifies the specific resource (position) and operation type. However, it does not explicitly differentiate from similar camera tools like flyTo, setView, or trackEntity 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.

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

The description provides no guidance on when to use this tool versus alternatives like flyTo or setView, nor does it mention prerequisites or exclusions. The term '环绕式' (orbit-style) implies the use case but does not explicitly state when this should be preferred over other camera controls.

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

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

Annotations indicate readOnlyHint=false (confirming state change) and destructiveHint=false. The description aligns by implying an active 'play' operation, but adds no details about side effects (e.g., whether playback blocks subsequent calls, if it creates a temporary visual entity, or how it handles completion).

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?

Extremely brief at only 6 characters, with zero redundancy or wasted text. However, the extreme brevity contributes to under-specification for a tool with six parameters including temporal controls.

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?

For a 6-parameter visualization tool with timing controls (trailSeconds, durationSeconds) and 3D coordinate arrays, the single-phrase description is insufficient. No mention of output behavior, visual rendering characteristics, or interaction with the map view.

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?

Input schema has 100% description coverage with clear Chinese documentation for all 6 parameters (e.g., '轨迹坐标数组', '尾迹长度'). The description itself mentions no parameters, but per the rubric, baseline 3 is appropriate when schema coverage is high.

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 Chinese description '播放移动轨迹动画' clearly identifies the action (播放/play) and resource (移动轨迹动画/moving trajectory animation), matching the tool name. It specifies this is for trajectory playback rather than generic animation creation, though it doesn't explicitly contrast with siblings like createAnimation or controlAnimation.

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?

No guidance provided on when to use this tool versus alternatives (createAnimation, controlAnimation, updateAnimationPath), or prerequisites such as whether coordinates must be pre-validated or if this requires an existing layer context.

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

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

Annotations already identify this as destructive and idempotent, which the description doesn't contradict. However, the description adds no behavioral context beyond the name—no information on failure modes (e.g., entity not found), side effects, or what happens to running animations when deleted.

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?

At only 5 characters, this is under-specification rather than effective conciseness. For a destructive operation with safety implications, the description fails to front-load critical constraints or warnings, providing insufficient structural value.

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?

Lacking output schema and with destructive annotations, the description should explain success indicators or error conditions. It omits context on how this interacts with the animation system (e.g., immediate removal vs graceful stop).

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?

With 0% schema coverage (entityId lacks description), the description fails to compensate adequately. While '实体' (entity) loosely maps to the entityId parameter, it does not clarify whether this accepts any entity ID or specifically animation instance IDs, nor does it explain the relationship to the 'createAnimation' workflow.

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 Chinese description '删除动画实体' (delete animation entity) provides a clear verb and resource, distinguishing from the generic 'removeEntity' sibling by specifying this targets animation-specific entities. However, it is extremely terse and does not clarify the relationship to related animation tools (controlAnimation, updateAnimationPath).

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?

No guidance provided on when to use this versus removeEntity or controlAnimation. No mention of prerequisites (e.g., animation must exist) or whether the animation should be stopped first via controlAnimation.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, establishing the operation is irreversible but safe to retry. The description confirms this is a removal operation but adds no additional behavioral context such as side effects on dependent objects, confirmation requirements, or cleanup behavior.

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 extremely concise at just one short sentence. Every word serves a purpose: defining the action (移除), scope (单个实体), and key parameter (entityId). There is no redundant or filler text.

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?

For a single-parameter destructive operation with full schema coverage and comprehensive annotations, the description provides the minimum viable context. However, it could be improved by noting that entityId must be obtained from a prior operation (addEntity or list) or clarifying the irreversible nature of the deletion explicitly in text.

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?

With 100% schema description coverage, the parameter entityId is fully documented in the schema itself. The description references the parameter ('通过 entityId') but does not add syntax details, format constraints, or usage examples beyond what the schema provides, warranting the baseline score.

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 specific action (移除/remove) and target (单个实体/single entity), and identifies the key parameter (entityId). It implicitly distinguishes from siblings like removeAnimation or removeLayer by specifying 'entity', though it lacks explicit comparative guidance.

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 provides no guidance on when to use this tool versus alternatives (e.g., bulk removal if available), nor does it mention prerequisites such as obtaining the entityId from a prior add or list operation. It only states the immediate action.

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

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

The description aligns with annotations (destructiveHint=true, idempotentHint=true, readOnlyHint=false) by stating 'remove', but does not add behavioral context beyond what annotations provide. It does not clarify whether removal affects the underlying data source or just the map view, nor does it mention the idempotent nature of the operation.

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 a single, efficient sentence of 12 characters with zero waste. It front-loads the action and target, placing the mechanism in parentheses. Every element earns its place.

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?

For a single-parameter destructive operation with complete schema coverage and rich annotations, the description is minimally adequate. However, it misses opportunity to clarify permanent deletion vs. temporary hiding, or to confirm the idempotent behavior hinted by annotations.

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?

With 100% schema description coverage, the baseline is 3. The description mentions 'by layer ID' which corresponds to the id parameter, but adds no semantic detail beyond what the schema already provides (the schema already notes the ID can be obtained via listLayers).

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 specific action (移除/remove), target resource (图层/layer), scope (从地图上/from map), and mechanism (按图层ID/by layer ID). It effectively distinguishes from siblings like removeEntity, removeAnimation, and setLayerVisibility by specifying 'layer' as the resource.

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 the need for a layer ID through the parenthetical (按图层ID), but does not explicitly state prerequisites (e.g., 'first call listLayers') or contrast with alternatives like setLayerVisibility (which hides rather than removes). Usage guidance relies heavily on the parameter schema description.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, confirming safe read behavior. The description adds crucial behavioral context: the return format (base64 PNG) and that it captures the 'current' view (point-in-time snapshot), neither of which are present in structured fields.

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?

Single sentence with zero waste: action (截取), target (当前地图视图), and return value (返回 base64 PNG) are all specified front-loaded without filler text.

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?

For a zero-parameter tool with no output schema, the description adequately covers the essential contract (captures current view, returns PNG). It could optionally mention image dimensions or synchronous behavior, but the core functionality is fully described.

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?

Zero parameters exist, meeting the baseline score of 4. The description appropriately focuses on the return value since no inputs require explanation.

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 uses specific verb '截取' (capture) with clear resource '地图视图' (map view) and output format 'base64 PNG'. It clearly distinguishes from sibling tools like addMarker or setView which manipulate the map rather than capturing it.

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?

No explicit when-to-use or alternatives are mentioned. However, the description implies this is for capturing visual state among 30+ manipulation tools. Usage is intuitive but lacks explicit guidance on when to prefer this over getView or similar inspection tools.

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

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

The description confirms the mutative nature of the operation (切换 implies state change), which aligns with annotations (readOnlyHint=false). However, it adds no information about side effects, performance implications, or what happens to previously loaded basemaps beyond what the idempotentHint and destructiveHint annotations already convey.

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

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

The single-sentence description is maximally efficient with zero redundancy. It front-loads the action verb and immediately qualifies it with the available options, making it easy to parse quickly.

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 low complexity (single enum parameter), complete schema coverage, and comprehensive annotations indicating idempotency and non-destructive behavior, the description adequately covers the essential information needed for invocation. It appropriately omits return value discussion since no output schema exists.

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?

With 100% schema description coverage where the parameter already maps enum values to Chinese meanings (dark=暗色, etc.), the description adds minimal semantic value beyond repeating these options in parentheses. It meets the baseline expectation for high-coverage schemas but doesn't elaborate on selection criteria.

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 specific action (切换/switch) and target resource (底图风格/basemap style), including the three valid options (dark/satellite/standard). It effectively distinguishes this tool from siblings like setView, setCameraOptions, and loadImageryService by focusing specifically on base map styling.

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 provides no guidance on when to use this tool versus alternatives. It fails to clarify the distinction between this tool (switching built-in basemap styles) and loadImageryService (loading custom imagery layers), or when to prefer specific styles over others.

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

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

Annotations indicate idempotent and non-destructive behavior. The description adds valuable context that this controls interaction capabilities (enabling/disabling) rather than camera state, though it doesn't specify if disabling a control interrupts ongoing interactions.

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?

Single sentence with parenthetical examples efficiently conveys the tool's scope. Every word earns its place—no redundancy while covering the essential functionality.

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?

Appropriate for the complexity level: 5 simple boolean parameters with no output schema. The description adequately covers the tool's purpose, though it could explicitly note that all parameters are optional (required: 0) for perfect completeness.

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?

With 100% schema coverage, the baseline is 3. The description adds semantic grouping by categorizing the parameters as camera controller options and providing representative examples (rotate, zoom, tilt) that map to the boolean enable flags in the schema.

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 configures the camera controller with specific examples (rotate, zoom, tilt), distinguishing it from sibling tools like flyTo or setView which handle camera positioning rather than interaction controls.

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?

While the functionality is clear, the description lacks explicit guidance on when to use this versus camera movement tools (flyTo, setView, lookAtTransform) or orbit controls (startOrbit). No prerequisites or exclusions are mentioned.

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

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

The description aligns with annotations (non-destructive, idempotent write operations) and identifies the affected subsystems (lighting, atmosphere). However, it adds minimal context beyond what the parameter names and annotations already convey, missing details like performance implications or visual behavior when toggled.

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 single-sentence description is compact and front-loaded, containing no redundant words. It efficiently conveys the tool's scope without unnecessary elaboration given the straightforward nature of the operation.

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?

For a tool with four optional boolean parameters and no output schema, the description adequately covers the functional scope. Combined with complete schema documentation and clear annotations, the description provides sufficient context for invocation, though it could clarify default states or interaction with other visual settings.

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?

With 100% schema coverage, the baseline is 3. The description adds value by conceptually grouping the four individual boolean toggles into two functional categories ('globe lighting' and 'atmospheric effects'), helping the agent understand these parameters work together as a unified visual configuration.

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 identifies the action (enable/disable) and the specific domain (globe lighting and atmospheric effects). While it effectively distinguishes this from sibling geometry tools (addBillboard, addBox, etc.), it does not explicitly differentiate from other configuration tools like setCameraOptions or setView.

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 provides no guidance on when to invoke this tool versus alternatives, prerequisites for use, or specific scenarios where these effects are needed. It states what the tool does but not when an agent should select it.

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

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

The description relies entirely on annotations for behavioral disclosure (idempotentHint=true, destructiveHint=false, readOnlyHint=false). It adds no context about side effects, whether visibility changes trigger re-renders immediately, or if the operation is persisted. With annotations covering the safety profile, the description offers minimal added value.

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

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

The description is extremely brief (6 characters) with zero redundancy. While this efficiency prevents information overload, it is arguably too terse to provide substantive guidance beyond the tool name itself.

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 presence of numerous sibling layer manipulation tools (addGeoJsonLayer, removeLayer, updateLayerStyle, etc.), the description is insufficiently complete. It fails to clarify the specific scope of 'visibility' changes or explain what distinguishes this from other layer modifications, leaving gaps in contextual understanding.

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?

With 100% schema description coverage ('图层ID' and '是否可见'), the schema fully documents both parameters. The description adds no additional syntax guidance, format details, or semantic context beyond what the schema properties already provide, warranting the baseline score.

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 '设置图层可见性' (Set layer visibility) is essentially a tautology of the tool name setLayerVisibility. While it confirms the tool's function, it fails to distinguish this tool from siblings like updateLayerStyle or removeLayer, and provides no scope clarification (e.g., whether this affects rendering immediately or persists across sessions).

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 provides no guidance on when to use this tool versus alternatives such as updateLayerStyle or removeLayer. It lacks prerequisites (e.g., layer must exist), conditions for use, or exclusion criteria.

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

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

Annotations declare idempotentHint=true and readOnlyHint=false. The description adds valuable behavioral context that the operation is instant (瞬间) and lacks animation, which explains the user experience of the state change. No contradictions with annotations. It does not add information about error states or side effects on the rendering pipeline.

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 a single, dense sentence with zero wasted words. It front-loads the action (瞬间切换), specifies the target (指定经纬度视角), and qualifies the behavior (无动画) efficiently.

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 simple flat schema with 6 parameters and good annotations, the description is sufficient for tool selection. It appropriately focuses on the distinguishing characteristic (instant/no animation). Minor gap: does not explicitly state this controls the camera/viewport, though '视角' strongly implies it.

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?

With 100% schema description coverage, the baseline is 3. The description highlights the required longitude/latitude parameters but does not add semantic meaning for the optional camera orientation parameters (heading, pitch, roll) or height that isn't already covered by the schema's Chinese descriptions.

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 performs an instant switch (瞬间切换) to a specific longitude/latitude view (经纬度视角), with the specific behavioral trait of having no animation (无动画). This distinguishes it from siblings like flyTo which typically animate. However, it could explicitly mention 'camera' or 'viewport' to be absolutely clear.

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 parenthetical '(no animation)' provides implied usage guidance—suggesting this is for instant jumps versus smooth transitions—but it does not explicitly state when to use this versus flyTo or other camera tools, nor does it mention prerequisites like valid coordinate ranges beyond what's in the schema.

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

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

Annotations cover idempotency and safety (idempotentHint=true, destructiveHint=false), but the description adds valuable context about orbiting around the 'current center' (当前中心). However, it omits crucial behavioral details: that the orbit continues indefinitely until explicitly stopped, and how it interacts with existing camera animations.

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?

Extremely concise single-sentence description with no redundancy. While efficient, it is arguably under-specified given the tool's behavioral complexity and could benefit from one additional sentence covering the continuous nature or stop requirements.

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?

With annotations providing safety/idempotency context and only two simple parameters, the description adequately covers the core action. However, it lacks completeness regarding the undocumented 'direction' parameter, the indefinite duration of the orbit, and the relationship with 'stopOrbit'.

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 exactly 50%—the 'speed' parameter is documented (degrees/second) but 'direction' has no schema description. The description text adds no parameter context whatsoever, failing to compensate for the undocumented direction enum or explain default behaviors.

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 identifies the action (开始/start), target (相机/camera), and specific behavior (环绕当前中心旋转/orbit around current center). It distinguishes itself from siblings like 'stopOrbit' and camera movement tools (flyTo, setView) by specifying the continuous orbital rotation action.

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?

No guidance provided on when to choose this over alternative camera controls (flyTo, lookAtTransform) or how it interacts with them. Critically, it fails to mention that this initiates a continuous animation that requires the sibling tool 'stopOrbit' to terminate, or that it conflicts with other camera operations.

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

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

Annotations cover safety profile (idempotent, non-destructive, not read-only). The description adds minimal behavioral context beyond what the annotations provide—it doesn't clarify stop behavior (immediate vs. gradual), state after stopping, or interaction with other camera operations.

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?

Extremely concise (3 Chinese characters). For a simple state-change operation with no parameters, this brevity is efficient, though it borders on being too terse to provide sufficient context for distinguishing from similar animation controls.

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 zero parameters and no output schema, the description meets minimum requirements but has clear gaps. It should mention the relationship to startOrbit and clarify behavior when no orbit is active (safe to call due to idempotency per annotations).

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?

The tool has zero parameters and the schema has 100% description coverage (empty object). Per calibration guidelines, zero parameters establishes a baseline score of 4.

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 '停止环绕动画' (Stop orbit animation) clearly identifies the verb (stop) and resource (orbit animation). However, it does not distinguish from sibling tools like controlAnimation or removeAnimation, nor does it clarify the relationship with startOrbit.

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?

No guidance provided on when to use this tool versus alternatives like controlAnimation or removeAnimation. No mention that this specifically pairs with startOrbit or prerequisites like an active orbit animation.

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

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

Annotations declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds no behavioral context beyond this, failing to clarify whether tracking is continuous (requiring a stop command) or instantaneous, and whether it affects entity state or only camera state.

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 four-character phrase is efficiently front-loaded with zero redundancy. However, for a tool with zero schema documentation and unspecified behavioral scope, the description is inappropriately minimal rather than appropriately concise.

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 presence of camera control siblings and idempotent mutation annotations, the description lacks critical context: it omits continuous vs. one-shot behavior, return value indication (none described), error conditions, and interaction with other camera commands.

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?

With 0% schema description coverage for the single required 'entityId' parameter, the description fails to compensate by providing type constraints, ID format expectations, or entity reference semantics. The term '实体' vaguely maps to the parameter name but offers no actionable specification.

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 Chinese description '相机追踪实体' (Camera tracks/follows entity) clearly states the basic action and resource using specific verbs. However, it fails to distinguish from numerous sibling camera manipulation tools (flyTo, lookAtTransform, startOrbit, zoomToExtent), leaving ambiguity about whether this is continuous tracking or a one-time camera move.

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?

No guidance provided on when to prefer this tool over alternatives like flyTo or startOrbit, nor does it indicate prerequisites (e.g., entity must exist) or how to terminate the tracking behavior (relevant given sibling 'stopOrbit' exists).

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

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

The term 'visual properties' adds context beyond annotations (which declare idempotentHint=true, destructiveHint=false), clarifying the scope is cosmetic (show/color/width) rather than trajectory data. However, it omits error behavior for invalid entityId or partial updates.

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?

Single sentence is efficient per se, but inappropriately terse given the lack of schema documentation and missing usage context. Front-loaded purpose is good, but overall insufficient for the information gaps.

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?

Incomplete for a mutation tool with four undocumented parameters and no output schema. Annotations cover safety/idempotency, but the description fails to document parameters, return values, or error conditions expected by the agent.

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?

With 0% schema description coverage, the description inadequately compensates. It broadly references 'visual attributes' but fails to map these to specific parameters (show, color, width) or explain the required entityId parameter's expected value format.

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?

States the tool updates visual properties of animation paths (specific verb+resource), but fails to differentiate from sibling `updateEntity` which could also modify path entities, or clarify what constitutes an 'animation path' vs other entities.

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?

Provides no guidance on when to use this tool versus `updateEntity`, `controlAnimation`, or `updateLayerStyle`. No mention of prerequisites (e.g., animation must exist first) or expected workflow.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, covering the safety profile. The description adds no additional behavioral context regarding error handling (e.g., what happens if entityId doesn't exist), transaction scope, or side effects. It does not contradict the annotations.

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

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

Extremely concise single-sentence structure with no redundant words. Every element serves a purpose. However, given the tool's complexity (6 parameters, nested objects, mutation behavior), the description borders on underspecified rather than optimally concise.

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?

Adequate for basic identification but incomplete for an update tool with no output schema. Missing: error handling semantics, return value description, confirmation of partial update capability (implied by optional params but not stated), and relationship to the entity lifecycle (creation via add* tools, deletion via removeEntity).

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?

With 100% schema description coverage, the schema already documents all six parameters including the nested position object. The description merely lists the fields in Chinese without adding syntactic details, format constraints, or examples beyond what the schema provides. Baseline score appropriate for high schema coverage.

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 updates properties of an existing entity, using the specific verb '更新' (update). The parenthetical explicitly lists the five modifiable attributes (position, color, label, scale, visibility), which maps directly to the schema parameters. It implicitly distinguishes from sibling 'add*' tools by emphasizing 'existing entity'.

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?

No guidance provided on when to use this tool versus alternatives. The description does not mention that entityId must be obtained from sibling tools like addMarker/addPolyline, nor does it clarify partial update behavior versus full replacement. No prerequisites or error conditions are described.

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

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

Annotations cover idempotency, read-only status, and destructiveness. The description adds domain context by listing modifiable visual properties (color, transparency, label style) but omits behavioral details like error handling for missing layerIds, partial update behavior, or persistence guarantees.

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?

Single efficient sentence front-loads the core action. Parenthetical examples (color, transparency, label style) provide immediate value without verbosity. No redundant or filler text.

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?

Sufficient for a style modification tool with comprehensive schema coverage and safety annotations. Minor gap regarding return value specification (no output schema present) and error conditions, but the scope and intent are adequately communicated.

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?

Input schema has 100% description coverage with detailed field listings (color, opacity, font, etc.). The description provides the umbrella concept ('modify style') but does not add syntax details, format constraints, or examples beyond what the schema already documents. Baseline 3 appropriate for high schema coverage.

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?

Description clearly states the specific action (modify/update) and target resource (existing layer style), explicitly distinguishing from siblings like addGeoJsonLayer (creation), setLayerVisibility (toggle), updateEntity (entity vs layer), and removeLayer (deletion).

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?

Provides implicit usage context by specifying 'existing layer,' but lacks explicit when-to-use guidance (e.g., when to prefer this over recreating a layer) or prerequisites (e.g., layer must exist). No alternative tools are named for different styling approaches.

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

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

Annotations declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds the geographic context but omits behavioral details like animation smoothness (despite the 'duration' parameter), what happens with invalid bounds, or whether the operation is interruptible.

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?

Extremely concise at 8 characters, the single sentence efficiently conveys the core action without redundancy. However, the brevity leaves significant contextual gaps given the tool's complexity (animation behavior, coordinate validation) that warrant additional detail.

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 rich ecosystem of 40+ sibling tools including multiple camera controls, the description fails to clarify the distinction between 'zoomToExtent' (bounds-based) and 'flyTo' (likely point/entity-based). It also ignores the animation implications of the 'duration' parameter, leaving critical behavioral context undocumented.

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?

With 100% schema description coverage where all 5 parameters (bounds + duration) are fully documented in Chinese with units (degrees, seconds), the schema carries the semantic load. The description adds no parameter-specific guidance, meeting the baseline expectation for well-schematized tools.

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 '缩放到指定地理范围' provides a specific verb (zoom) and resource (geographic extent/bounds), clearly indicating this performs a camera/view operation. However, it lacks differentiation from siblings like 'flyTo' or 'setView' which also manipulate the camera, leaving ambiguity about when to choose this over point-based navigation.

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?

No guidance is provided for when to use this tool versus alternatives like 'flyTo' (point-to-point), 'setView' (camera orientation), or 'lookAtTransform'. There is no mention of prerequisites such as coordinate system requirements or valid bounds (east > west).

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