A
licenseA
qualityC
maintenanceEnables local image-driven displacement of STL/OBJ meshes, STL/3MF export, and agent-driven texturing workflows without remote services.
3
AGPL 3.0
tactile-terrain
by derekriemer
This MCP server turns map areas into tactile 3D-printable models and helps inspect, edit, analyze, and print-check them.
Resolve a place or bounding box and report area size, elevation range, and named streams, roads, lifts, and peaks without building anything.
Create terrain or flat models with map features, scale, base, printer, vertical exaggeration, and tactile profile settings.
Update existing models with undoable edits, shortcuts like crop, z-multiply, feature drop, and revert.
Describe models as plain text, including high/low points, line courses, crossings, cross-sections, tactile legend, and distortion.
Analyze models for warnings and fixes.
Check printability: watertightness, volume, filament, print time when available, minimum features, and bed fit; write a print pack.
Build calibration sampler plates to test tactile profiles, widths, heights, and spacing.
Inspect installation health, supported capabilities, existing models, and a model's current spec.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@tactile-terrain make a 3D-printable tactile model of Central Park and check printability"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
tactile-terrain
Tactile terrain printing: an MCP server and Claude plugin that turn map areas into 3D-printable models for touch.
Status: Phase 1 under construction. Licensed AGPL-3.0-or-later.
Everything the tool reports is plain text, so it works with a screen reader.
Design documents:
Design spec: what the tool does and why; the source of truth when the code and a plan disagree.
Design invariants: the rules the tool must keep.
Plans: the build plans and milestones.
What it does
resolve_area: describe an area before building (size, elevation range, named streams, roads, lifts and peaks).create_modelandupdate_model: build a model from US elevation and map data, then change it. Every edit keeps the previous version, so it can be undone.describe_model: read the whole model out as text: high points, the course of every line, crossings, cross-sections and the tactile legend.analyze_modelandcheck_print: warnings with exact fixes, volume and filament, and a print pack (STL, attribution, print notes, submission notes).create_sampler: a calibration plate for finding which line shapes, sizes and spacings you can tell apart. Tactile sizes come from your own tactile profile, never from fixed defaults.doctorandlist_capabilities: check the installation and see what is available.
Related MCP server: print_prep_studio
Install for development
Python runs only through uv. From this folder:
uv syncuv run pytest -qModels are written to ~/TactileModels. The config file is created on first use; uv run tactile-terrain doctor prints its path.
Use with Claude
Run uv sync once first, so Claude does not have to build the environment while it starts the server.
Load the plugin straight from this folder for a session:
claude --plugin-dir C:/path/to/bold_tactile_exploreOr install it from this folder as a local marketplace:
claude plugin marketplace add C:/path/to/bold_tactile_exploreclaude plugin install tactile-terrain@tactile-terrain-localAny other MCP client can run the server directly:
claude mcp add tactile-terrain -- uv run --directory C:/path/to/bold_tactile_explore tactile-terrain mcpCommand line
uv run tactile-terrain build examples/winter-park-library.jsonuv run tactile-terrain doctorDevelopment plugin (alpha testing)
The published plugin never contains alpha-test tools. For your own testing, build the development plugin:
uv run tactile-terrain dev-pluginIt writes the git-ignored folder dev-plugin/, so it can't be pushed or published by accident. It holds the same skill plus an alpha-test skill, and the server it starts runs from this checkout with TACTILE_TERRAIN_DEV=1. That adds a write_dev_note tool, and the skill tells Claude to use it whenever its workflow is awkward. Notes are saved as Markdown in ~/TactileModels/dev-notes/.
To load it:
Claude Code:
claude --plugin-dir dev-plugin, orclaude plugin marketplace add dev-pluginthenclaude plugin install tactile-terrain-dev@tactile-terrain-dev-local.Claude desktop (Cowork): upload
dev-plugin/tactile-terrain-dev.pluginthrough the plugin or customize screen, if your version has one.
Available Tools
11 toolsanalyze_modelB
Metrics and suggestions for a built model: warnings first, each with its fix.
Inputs: name (required). Returns: result
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.
Inputs: name (required). Returns: result
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.
Inputs: bbox (required), name (required), features (required), mode, +7 more. Returns: result
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.
Inputs: name, seed, focus, printer, +2 more. Returns: result
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"}.
Inputs: name (required), sections. Returns: result
doctorA
Report the installation: versions, config path, models folder, which data services are reachable, and whether a slicer is available.
Inputs: no named parameters. Returns: result
get_specC
The current spec of a model, as JSON text.
Inputs: name (required). Returns: result
list_capabilitiesC
Every provider, filter, style, analyzer and printer this installation supports.
Inputs: no named parameters. Returns: result
list_modelsC
The models that already exist.
Inputs: no named parameters. Returns: result
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.
Inputs: bbox, place, width_km. Returns: result
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.
Inputs: name (required), changes (required). Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
B3.3/5.0
Scored across 11 tools
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Maintenance
ActivityMaintained
ResponsivenessNo recent community issues
Related MCP Connectors
Design 3D-printable multi-colour map models from OpenStreetMap data, render them, and share them.
Turn text and images into 3D models for games, rendering and 3D printing.
Design 3D-printable names, keychains and cake toppers; save designs and export STL or 3MF.
Create, edit, render, save, and export voxel models with interactive 3D previews.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables people and general-purpose AI agents to inspect, model, edit, verify, and export local 3D projects through MCP tools, including print preparation, without requiring a hosted 3D service key.10MIT
- AlicenseAqualityBmaintenanceEnables MCP clients to inspect and measure native B-rep geometry, create and edit CAD models, export results, and optionally review models or prepare print jobs locally.11MIT
- AlicenseNot gradedqualityBmaintenanceEnables users to generate printable 3D map models of any place on Earth from open data, including terrain, buildings, trees, water, roads, and fields, with options for tiles, colors, and browser previews via MCP tools.MIT