Skip to main content
Glama
652036

ArcGIS Pro MCP

by 652036

Gp Multipart To Singlepart

arcgis_pro_gp_multipart_to_singlepart
Idempotent

Splits multipart features into singlepart features for ArcGIS Pro geoprocessing workflows, writing each part to a specified output feature class.

Instructions

ArcGIS Pro:multipartgp multipart to singlepart。返回可验证的结构化结果;写入和路径限制以服务能力为准。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
in_featuresYes
out_feature_classYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.1/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description's 'write and path restrictions are subject to service capabilities' is vague boilerplate and 'returns verifiable structured results' adds nothing concrete about behavior, permissions, or side effects 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.

Conciseness3/5

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

The text is short and not bloated, but it is a garbled mix of Chinese and English that reads as machine-generated filler rather than a front-loaded, purposeful sentence. Length is fine; content quality is low.

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 mutation GP tool with two parameters and 0% schema coverage, the description omits the essentials: what the input/output feature classes should be, that a new singlepart feature class is produced, and any environment/output requirements. An output schema exists, so return values need not be explained, but the description remains substantially incomplete.

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% and the description provides no meaning for in_features or out_feature_class. The parameter names are self-explanatory, but the description does not compensate for the missing schema documentation as required at low coverage.

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 'multipart gp multipart to singlepart' essentially restates the tool name/title without stating a distinct verb+resource action. A reader can only infer the operation (splitting multipart features into singlepart) from the name itself; the description adds no clarifying scope or differentiation from the ~200 sibling GP tools.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as gp_dissolve, gp_feature_to_point, or other geometry tools. No preconditions, no exclusions, no reference to a sibling are given.

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