No user-submitted related servers found.
Scored across 29 tools
Each vector tool targets a distinct operation (buffer, clip, overlay, dissolve, explode, simplify, centroid, area, merge, convert, reproject) and the descriptions actively disambiguate the risky pairs, e.g. spatial_join vs nearest_join and merge_layers vs dissolve_layer. The plan/provenance/discovery cluster (list_operations, validate_plan, brief_plan, execute_plan, get_provenance, run_operation) is explicitly staged, and the authors even explain why lineage is NOT a separate tool to avoid overlap. The only intentional overlap is run_operation as a documented escape hatch to the wider catalog.
The dominant convention is verb_noun (buffer_layer, clip_layer, overlay_layers, execute_plan, get_provenance, preview_map), applied consistently across the vector and planning families. Deviations cluster in the raster/terrain family, which is named by the quantity produced (hillshade, slope, aspect, flow_accumulation, watershed) plus a few noun_noun cases (centroid_layer, server_info, zonal_statistics). Readable and semi-predictable, but not one uniform pattern.
29 exposed tools is on the heavy side for a single MCP surface, though each one maps to a genuinely distinct geoprocessing operation rather than a duplicate. The design admits this tension by exposing only the frequently used operations and routing the rest of the catalog through run_operation. The count is defensible for the domain's breadth but sits past the point where tool-selection accuracy is known to degrade.
Coverage is strong across vector geoprocessing, raster/terrain analysis, spatial SQL, plan validation/execution, provenance and preview — with an explicit generic runner to reach the rest of the catalog. Minor gaps remain on the exposed surface: no length/perimeter measurement, no raster clipping/warping/resampling, and no direct listing of workspace contents. These are workable via run_sql or run_operation, so no hard dead ends.