Use GeoAgent inside 3DGeoServEngine to turn natural-language requests into auditable geospatial operations. Run models locally, connect approved model services, install Claude/GPT workflow skills, or enable authenticated MCP access for external AI clients.
Models, skills and MCP connections are complementary. Each solves a different part of the workflow without replacing the platform’s service, security or audit boundaries.
Describe an outcome in natural language. GeoAgent selects registered geospatial capabilities, exposes the tool call and parameters, and returns rendering hints for maps, rasters, profiles and tables.
See the execution model →Route text, vision and embedding workloads through Ollama, LocalAI or an approved OpenAI-compatible service. Keep sensitive and disconnected workflows on controlled infrastructure.
Review model routing →Optional skill packages give external assistants platform terminology, data conventions and repeatable geospatial workflows—useful guidance even when no live tool connection is enabled.
Compare skills and MCP →Enable the server-side MCP endpoint so compatible AI clients can discover and invoke the same governed capability catalog used by GeoAgent. The inverse MCP client lets GeoAgent call external GIS tools.
See both MCP directions →GeoAgent is not a generic chatbot layered over a map. It is a tool-calling agent connected to the platform’s analysis and service registry, with map context and explicit result contracts.
Pass current layers, selected features, locations and relevant project context into the conversation.
See the selected capability, submitted parameters, execution status and returned payload instead of trusting an unexplained answer.
Invoke routing, hydrology, geostatistics, terrain, topology, imagery, conversion and operational capabilities through the shared registry.
Return GeoJSON, raster, profile, chart and table instructions so the in-app experience can present the result appropriately.
AI providers are replaceable execution layers. The geospatial tools, validation and result formats remain platform capabilities rather than model-specific prompt tricks.
Run supported language, vision and embedding models on local or edge hardware for private and disconnected workflows.
Use an OpenAI-compatible local runtime with controlled models, infrastructure and update policy.
Connect vLLM, LM Studio or another approved OpenAI-compatible endpoint when organizational policy permits it.
Local and disconnected operation can avoid a cloud dependency. Connected deployments can route only approved workload classes to external services while retaining the same geospatial tool boundary.
Separating these concepts helps teams choose the least-privileged approach that still accomplishes the workflow.
| Layer | What it adds | Live access | Best fit |
|---|---|---|---|
| Model provider | Language, vision and embedding inference used inside the platform | Only through the application’s configured AI service | In-app chat, extraction, classification and agent reasoning |
| Claude/GPT skill | Platform terminology, data conventions, workflow instructions and reusable task patterns | No live access by itself | Guided analysis, repeatable procedures and better assistant behavior |
| MCP server | Schema-described platform tools exposed to external compatible AI clients | Authenticated, opt-in streamable HTTP | Claude Desktop, Claude Code, Cursor and compatible agent clients invoking server capabilities |
| MCP client | External MCP tools registered into GeoAgent with namespaced identities | Outbound from GeoAgent | Letting GeoAgent use tools hosted by QGIS, ArcGIS and other connected systems |
The MCP server and MCP client share a protocol but face opposite directions. Both retain tool identity, schema boundaries and explicit connection controls.
Enable the server-build endpoint explicitly, configure an authenticated client, and let the client discover JSON Schema-described geospatial tools.
Connect approved MCP servers and make their tools discoverable to the in-app agent without merging external code into the platform core.
Configuring an MCP server by hand—picking a transport, composing a command line, guessing env vars—is the part teams get wrong. The built-in wizard ships one-click presets for the high-value open-source servers and validates every field.
Featured GIS preset. Raw-TCP socket transport against the qgis_mcp plugin (port 9876). Exposes ~14 tools—load_project, add_vector_layer, execute_processing, render_map—so GeoAgent can drive a live QGIS project.
Featured GIS preset. stdio transport against the ArcGIS Pro AddIn (requires Pro running with the AddIn loaded and the .NET SDK). Tools surface as mcp:arcgis:<tool> for the agent.
Official Anthropic reference servers via npx. Point the Filesystem preset at an approved directory and let the agent read, write and grep files; expose repository state and history through Git.
The GitHub preset (issues, search, pull requests) and duckdb_mcp let GeoAgent query repos and run SQL against attached data—all namespaced, all disconnectable.
| Transport | Use for | Wizard fields |
|---|---|---|
| socket | QGIS MCP (raw TCP) | host, port |
| http | Any streamable-HTTP JSON-RPC server | baseUrl, auth |
| stdio | The dominant transport—all official reference servers, GitHub, ArcGIS Pro, duckdb_mcp | command (bare executable on PATH), args, env (KEY=VALUE per line) |
For stdio the command must be a bare executable name resolved on PATH—absolute paths are rejected. Every connected server’s tools surface under mcp:<server-slug>:<tool>, so remote tools never masquerade as native capabilities and can be disconnected without side effects.
The MCP server is designed for the headless Web/Server deployment. It is off by default, protected by bearer authentication and intended to run behind HTTPS in production.
Administrators explicitly enable the MCP endpoint; it is not silently exposed with every deployment.
Clients authenticate through the same bearer-token gate used by other protected server APIs.
Connect modern compatible clients over the network without a local subprocess or desktop UI dependency.
External MCP calls receive structured JSON results. Automatic placement into a live map remains an in-app workflow rather than an implied external side effect.