Loading ToolBench
A secure, local-first, asynchronous MCP server exposing ArcGIS Pro's ArcPy engine over stdio JSON-RPC.
This is a well-engineered MCP server with strong fundamentals. Tool naming follows verb-noun conventions consistently (health_check, list_layers, execute_spatial_tool, create_feature_class, etc.). All 15 tools have descriptive, actionable descriptions (ranging 100-350 chars, well within the 10-1024 baseline). Input schemas are comprehensive with proper JSON Schema typing and enum constraints for controlled parameters. However, output schemas are not explicitly documented in the visible code, the server returns results but schema documentation for those results is absent. This is the primary gap preventing a higher score. Security posture is strong: destructive tools enforce confirmation gates (delete_dataset, delete_field, calculate_field with PYTHON3 all require confirm=true), path-based access control is validated at runtime (PathGuard), and no credentials are exposed as parameters. Error handling is present but could be more prescriptive about recovery guidance. The server demonstrates mature patterns like batching (add_fields_batch), idempotent design, and clear parameter relationships (e.g., calculate_field's expression_type enum constrains which modes are safe vs require confirmation).
Add one attribute field to an existing table or feature class.
Add multiple fields to an existing table or feature class.
Field calculation contract with an expression-channel safety floor.
Copy a feature class or layer into a new output feature class.
Create an empty feature class inside an existing file geodatabase.
Create a new file geodatabase in an existing folder.
Delete an existing dataset; irreversible and confirmation-gated.
Delete one or more fields from an existing table or feature class.
Output schemas not documented. While input parameters are thoroughly specified with types and descriptions, the response structure for each tool is not explicitly documented in visible code. LLMs cannot plan downstream calls without knowing what fields will be returned.
Error handling lacks prescriptive recovery guidance. Tools return errors but do not consistently guide LLMs on retry logic, available alternatives, or next steps. For example, if a dataset is not found, the error should suggest 'Call list_layers() to see available datasets' rather than a bare 404-equivalent.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
Return dataset metadata such as data type, geometry type, CRS, and extent.
Execute one allowlisted geoprocessing tool (Buffer_analysis, Clip_analysis).
Return the row or feature count for an existing dataset.
List field names, types, lengths, aliases, and nullable status.
Verify the full execution pipeline: server -> conda worker -> back. Spawns a real worker process (without importing arcpy) and reports the interpreter version plus configuration summary. Use this first when diagnosing connectivity.
List feature classes, tables and rasters inside a file geodatabase.
Rename an existing dataset within its current workspace.
Parameter dependency documentation incomplete. For example, calculate_field's 'confirm' parameter is only required when expression_type='PYTHON3', but this conditional logic could be made more explicit in descriptions to prevent LLM confusion.
describe_dataset, get_field_info, get_feature_count descriptions are minimal (75 chars or fewer). While technically compliant, they lack detail on when to call them vs alternatives and what structure they return.