spatial-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SPATIAL_URL | Yes | Your spatial-service address, ending in /ws (also configurable via --spatial flag) | |
| SPATIAL_PASSWORD | No | Your admin password | |
| SPATIAL_READONLY | No | Set to '1' to refuse all changes (read-only mode) | |
| SPATIAL_USERNAME | No | Your admin username (same as for the portal) | |
| SPATIAL_ALLOWED_DIRS | No | Folders the assistant may upload zips from (recommended) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| spatial_healthA | Which spatial-service this server talks to, its version, whether the credentials work (admin endpoints), and drift against the reference version |
| spatial_capabilitiesA | Tasks (analyses and maintenance processes) this spatial-service can run, with their input specs. Admins see private ones too |
| spatial_list_layersB | Layers, optionally filtered by text (name, display name, classification) |
| spatial_get_layerB | One layer by id or name |
| spatial_list_fieldsC | Fields (the sampling/intersect view of layers: cl… contextual, el… environmental), optionally filtered |
| spatial_get_fieldA | One field by id (e.g. cl22) |
| spatial_list_objectsC | Objects (polygons, e.g. each state) of a contextual field |
| spatial_search_gazetteerC | Search objects by name across the gazetteer fields |
| spatial_intersectC | Values of one or more fields at a point |
| spatial_task_statusA | Status (queued/running/success/failed/cancelled), message and the last log lines of a task |
| spatial_list_tasksA | Recent tasks (admin): filter by text or status (0 queued, 1 running, 2 cancelled, 3 failed, 4 finished) |
| spatial_run_taskA | Run a task via /tasks/create: a user analysis (AreaReport, AooEoo, PointsToGrid…) or, for admins, a maintenance process (Thumbnails, TabulationCreate, LayerDistancesCreate, StandardizeLayers…). See spatial_capabilities for names and inputs [changes spatial-service] |
| spatial_cancel_taskA | Cancel a queued or running task [changes spatial-service] |
| spatial_rerun_taskA | Re-run a task (admin), e.g. a failed LayerCreation or FieldCreation [changes spatial-service] |
| inspect_layer_zipA | Check a local layer zip before uploading (files present, WGS84, DBF encoding) and list DBF columns with sample values |
| spatial_list_uploadsA | Uploaded files waiting to become layers (admin) |
| spatial_layer_adminB | Admin view of a layer or upload: metadata, its fields and the tasks started for it |
| spatial_form_contractB | The live admin form for a layer/upload or field: what the UI allows (maxlength, options, read-only), and drift against the reference version |
| spatial_uploadA | Upload a layer zip (wiki step 2). Returns the upload id; then spatial_create_layer [changes spatial-service] |
| spatial_create_layerC | Create a layer from an upload (wiki step 3); starts LayerCreation [changes spatial-service] |
| spatial_create_fieldA | Add a field to a layer (wiki step 5); starts FieldCreation, then reloads the intersect config [changes spatial-service] |
| spatial_add_layerA | Whole wiki procedure in one go: inspect, upload, create layer, wait for LayerCreation, create field, wait for FieldCreation, reload intersect config [changes spatial-service] |
| spatial_update_layerC | Edit layer metadata (display name, classification, licence, enabled…). Read-only fields of the form cannot be changed [changes spatial-service] |
| spatial_update_fieldA | Edit a field (name, description, flags). Read-only fields of the form cannot be changed [changes spatial-service] |
| spatial_reload_intersect_configA | Reload the intersect configuration so new fields answer /intersect (wiki step 7) [changes spatial-service] |
| spatial_verify_layerC | Wiki step 8: check the layer and field in /layers, /fields, /objects, /object, KML, intersect, GeoServer WMS and the admin UI |
| spatial_deleteA | Delete a layer (numeric id), a field (cl…/el… id) or an upload (upload id) [changes spatial-service] |
| spatial_compare_remoteA | Compare the layers and fields here with another spatial-service (e.g. https://spatial.ala.org.au/ws) |
| spatial_import_from_remoteA | Copy a layer or field definition from another spatial-service (/manageLayers/importLayer|importField) [changes spatial-service] |
| spatial_create_areaA | Create a user area from WKT or GeoJSON (returns its pid, usable in analyses) [changes spatial-service] |
| spatial_delete_areaB | Delete a user area created with spatial_create_area [changes spatial-service] |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 31 tools
Most tools pair a distinct spatial resource with a distinct action, so list/get/update/delete and task/admin operations are generally easy to tell apart. The main confusion risk is spatial_add_layer versus spatial_create_layer/spatial_create_field, plus spatial_list_objects versus spatial_search_gazetteer, but the descriptions largely clarify these boundaries.
The dominant spatial_verb_noun pattern is consistent and lower_snake_case is used throughout. The un-prefixed inspect_layer_zip and a few noun-only names such as spatial_health, spatial_layer_admin, and spatial_form_contract deviate from the otherwise verb-first convention.
With 31 tools, this is a large surface that exceeds the 25+ threshold for a heavy toolset. Many tools are individually justified by the spatial-service admin lifecycle, but composite operations like spatial_add_layer and overlapping workflow tools make the set feel larger than necessary.
The toolset covers the full layer and field lifecycle: inspect, upload, create, update, verify, delete, task management, remote comparison/import, and user areas. There are no obvious dead ends, and both admin and user-facing workflows appear well supported.