Skip to main content
Glama
652036

ArcGIS Pro MCP

by 652036

Create Domain

arcgis_pro_create_domain

Creates coded value or range domains in an ArcGIS geodatabase to enforce attribute validation and ensure data integrity.

Instructions

在地理数据库中创建编码值域或范围域;需要写入开关和方案锁。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
field_typeYes
domain_nameYes
domain_typeNoCODED
merge_policyNoDEFAULT
split_policyNoDEFAULT
workspace_pathYes
domain_descriptionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the safety profile is covered. The description adds operational context beyond the annotations: the necessity of a write switch and a schema lock, which is a real prerequisite the agent must satisfy. It stops short of describing failure modes or locking behavior.

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 front-loaded sentence stating purpose then prerequisite, with no filler. Efficient, though its brevity is part of why parameter coverage is thin.

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

Completeness3/5

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

The output schema exists so return values need not be described, and the safety profile is in annotations. But for a 7-parameter creation tool with no schema descriptions, the absence of any per-parameter guidance leaves an agent without enough to fill arguments confidently.

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 7 parameters (4 required), so the description must carry the burden and it largely does not. It implies the domain_type distinction (coded vs range) but never explains field_type, workspace_path, merge_policy, split_policy, or domain_description, leaving most parameters undocumented anywhere.

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

Purpose4/5

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

States a specific verb and resource (create a domain in the geodatabase) and names the two variants it supports (coded value domain / range domain). An agent can distinguish it from list_domains, alter_domain, or set_range_domain, though it does not explicitly name those siblings.

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

Usage Guidelines3/5

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

Provides a precondition ("requires write switch and schema lock") that tells the agent when the call will succeed, which is genuinely useful. However, it gives no guidance on when to use this versus alter_domain or add_coded_value_to_domain, nor any exclusions.

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