Skip to main content
Glama
652036

ArcGIS Pro MCP

by 652036

Gp Optimized Hot Spots

arcgis_pro_gp_optimized_hot_spots
Idempotent

Detect statistically significant hot and cold spots in spatial data using optimized hot spot analysis with optional cell size, distance band, and aggregation controls.

Instructions

ArcGIS Pro:optimizedgp optimized hot spots。返回可验证的结构化结果;写入和路径限制以服务能力为准。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cell_sizeNo
in_featuresYes
out_featuresYes
distance_bandNo
analysis_fieldNo
aggregation_methodNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

D1.7/5.0
Behavior2/5

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

The boilerplate '返回可验证的结构化结果;写入和路径限制以服务能力为准' is generic across the tool family and adds no tool-specific behavior. Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false; the description neither elaborates nor contradicts them, but it discloses nothing new (no output-write semantics, no overwrite behavior).

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

Conciseness2/5

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

It is short, but the opening clause is a redundant name echo and the second clause is content-free boilerplate, so nothing in the text earns its place. Brevity here reflects under-specification rather than efficiency.

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

Completeness2/5

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

An output schema exists, so return values need not be explained. However, for a 6-parameter geoprocessing tool with zero schema descriptions, the definition should at minimum describe the required inputs and the optional analysis parameters; instead it provides no actionable content.

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

Parameters1/5

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

Schema description coverage is 0% across 6 parameters (in_features, out_features, cell_size, distance_band, analysis_field, aggregation_method), and the description supplies no meaning for any of them. The agent must guess what analysis_field or aggregation_method accept.

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

Purpose2/5

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

The description is essentially a restatement of the tool name ('optimized hot spots') prefixed with a fragment 'optimizedgp', which adds no verb+resource specificity beyond the title. It never says what the tool actually does (identify statistically significant hot/cold spots) nor distinguishes it from sibling arcgis_pro_gp_hot_spots.

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

Usage Guidelines1/5

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

No when-to-use guidance, no conditions, and no mention of alternatives such as arcgis_pro_gp_hot_spots, arcgis_pro_gp_cluster_outlier, or arcgis_pro_gp_spatial_autocorrelation. An agent has no basis for choosing this tool over its close siblings.

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

Deploy Server

Other Tools