Skip to main content
Glama
652036

ArcGIS Pro MCP

by 652036

Raster Con

arcgis_pro_raster_con
Idempotent

Runs Con conditional calculations on rasters, selecting true or false outputs from rasters or constants based on a conditional raster and optional SQL where clause.

Instructions

以受控栅格/常量和可选 SQL 条件执行 Con 条件计算。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
out_rasterYes
environmentNo
where_clauseNo
in_conditional_rasterYes
in_true_raster_or_constantYes
in_false_raster_or_constantNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false). The description adds only that a SQL condition is involved, but says nothing about output raster creation, overwrite behavior, or execution semantics beyond what annotations provide.

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

Conciseness4/5

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

A single compact sentence with no filler or redundancy. It is well-formed, though its brevity is part of the under-specification problem rather than a stylistic strength to celebrate.

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?

For a 6-parameter geoprocessing tool with 0% schema description coverage and an output schema, one sentence is inadequate. The description should explain the conditional/true/false raster logic and the where_clause semantics, none of which are covered elsewhere.

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

Parameters2/5

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

Schema description coverage is 0% across 6 parameters, so the description must compensate. It loosely maps to in_conditional_raster, the true/false rasters-or-constants, and where_clause, but leaves the distinction between in_true vs in_false, out_raster, and environment entirely undefined.

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

Purpose3/5

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

The description states a verb and object — executing a Con conditional calculation on a conditional raster/constant — which conveys the general operation. However, 'Con 条件计算' largely restates the tool name 'Raster Con' and gives no differentiation from sibling conditional/raster tools like arcgis_pro_gp_raster_calculator or arcgis_pro_gp_reclassify.

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

Usage Guidelines2/5

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

It mentions an 'optional SQL condition' but provides no explicit when-to-use, when-not-to-use, or alternative tools. An agent cannot infer from this text when Con should be preferred over raster_calculator or set_null.

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