Integration
Connecting geospatial AI through MCP and API
See how LGM fits into AI-agent and application workflows through MCP and API, from choosing a study area to returning usable geospatial results.
A geospatial service becomes valuable when it fits the tools people already use. Some teams start in an AI assistant, others in a browser map, a GIS application or a custom workflow. LGM supports this variety through a shared backend with MCP and API access.
The integration choice depends on who controls the sequence of operations: an agent selecting tools, or an application calling a defined interface.
What MCP contributes
The Model Context Protocol defines a client-server architecture through which AI applications can discover and use server capabilities such as tools, resources and prompts.
In an LGM workflow, MCP provides a way for a compatible agent to discover available geospatial tools and call them with structured arguments. The agent can use intermediate results to decide what to request next.
For example, it might first inspect available layers, then request objects within a study area and finally retrieve additional context for a smaller candidate zone. The exact sequence depends on the client, the exposed tools and the data accessible to the account.
When an API fits better
An API is useful when an application already knows what it needs to do. A dashboard may request the same indicators for a user-selected polygon. A background process may repeat a calculation for a list of assets. A GIS integration may retrieve a layer for visualization.
In these cases, application code controls the request parameters, error handling and presentation. LGM supplies the data or computation behind that interaction.
The distinction is about orchestration, not a mandatory split between types of customer. The same product can use direct API requests for predictable operations and an agent for exploratory research.
Keep access attached to the account
The LGM Platform provides account registration, API-key management and layer uploads. LGM’s GeoAI deployments use an access model that includes project-specific uploads, shared layers and permitted public data.
An agent should operate within those permissions. The phrasing of a request must not expand its access to another project’s collection.
For integration teams, a useful first validation is to check that the intended account can discover the correct data and complete one bounded operation. Larger investigations should follow once that path works.
Return artifacts that applications can use
Geospatial outputs can be much larger than a conversation. A useful integration separates the explanation from the data artifact: the agent can summarize an operation while the application retrieves geometry, a table or a raster result through the appropriate output path.
The application should retain enough context to connect an output to its study area and source. A polygon without a coordinate reference or clear meaning is difficult to reuse reliably.
LGM’s goal is to make results available for continued work in a map, a GIS project or a downstream system.
Measure the work behind the answer
An investigation may combine model tokens, requests, data processing and storage activity. These are different resources and should remain distinguishable.
LGM’s billing and tracing work connects usage to accounts and API keys. The planned task-level usage manifest extends that idea to a consolidated execution report. Billing is a service capability built around the integration; MCP itself does not establish LGM prices.
Start with the MCP connection guide for an agent workflow, or the API overview for application integration. Both paths benefit from a small initial study area and an explicit expected result.