tactile-terrain
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resolve_areaA | Describe an area before building: size, elevation range, available data, and the named streams, roads, lifts and peaks inside it. Give a place name (with width_km for a square around it) or a bbox [west, south, east, north] in degrees. Builds nothing. |
| create_modelB | Create and build a model. bbox is [west, south, east, north] in degrees. Give exactly one of scale_m_per_mm or long_side_mm. mode is terrain or flat. Each feature is {type, provider, style, filter}; style names come from the tactile profile (see list_capabilities). Returns a build summary plus analysis with fixes. |
| update_modelA | Change a model and rebuild it. changes is a JSON merge-patch of the spec, plus the shortcuts z_multiply (factor), crop_percent ({north|south|east|west: percent}), drop_feature (type) and revert_to (earlier version number). Reports each change as before to after. An invalid change leaves the model untouched. |
| describe_modelA | Read a model out as text: footprint, scale, high and low points, the course of every line, crossings, cross-sections, the tactile legend and distortion. sections adds extra cross-sections: {"y_mm": 40}, {"x_mm": 60} or {"through": "Second Creek", "direction": "EW"}. |
| analyze_modelB | Metrics and suggestions for a built model: warnings first, each with its fix. |
| create_samplerB | Build a calibration plate to find which differences the user can feel: profile pairs with identical controls, widths, heights, and closely spaced lines. profile names the tactile profile to test (default: the active one). focus limits the plate to one row type (profiles, widths, heights or spacing). Every sample has a raised numeral and rows are marked by notches on the left edge, so no Braille is needed. Use describe_model on the result for a row-by-row readout. |
| check_printA | Check a model is printable: watertight, volume and filament (an upper bound), print time when a slicer is installed, and minimum feature and bed-fit problems. Also writes the print pack (STL, attribution, print notes, submission notes) next to the model. |
| doctorA | Report the installation: versions, config path, models folder, which data services are reachable, and whether a slicer is available. |
| list_capabilitiesC | Every provider, filter, style, analyzer and printer this installation supports. |
| list_modelsC | The models that already exist. |
| get_specC | The current spec of a model, as JSON text. |
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 11 tools
Each tool has a clearly distinct role: model creation, mutation, textual description, analysis, calibration sampler creation, print checking, installation diagnostics, capability listing, model listing, spec retrieval, and area resolution. The closest pairs (describe_model vs. analyze_model, get_spec vs. describe_model) are separated by output type and purpose.
Most tools follow a consistent snake_case verb_noun pattern such as create_model, update_model, describe_model, and list_models. The only notable deviation is doctor, which is a conventional noun-style diagnostic command rather than a verb_noun name.
Eleven tools is well-scoped for a terrain-modeling server, covering creation, editing, inspection, calibration, validation, and installation discovery. Each tool appears to earn its place without excessive surface area.
The surface covers the core model lifecycle: resolve an area, create, update, inspect, analyze, list, retrieve specs, and check printability. A delete or duplicate operation is missing, but most workflows can be completed without it.