GSoC 2026 Midterm Update

Introduction

Hi everyone,

I am Pranav Angrish, and this summer I am working with 52°North as part of Google Summer of Code 2026 on the project MCP for OGC APIs: Developing Model Context Protocols for the Suite of OGC APIs.

In my first blog, I introduced the motivation behind the project: making OGC APIs easier to use through the Model Context Protocol. At that stage, the focus was on the idea of a spec-first bridge between language models and geospatial services. Since then, the work has moved from an early prototype into a more structured MCP reference server for OGC APIs.

The central goal remains the same. I want a language model to interact with geospatial APIs through reliable, well-defined tools instead of brittle ad-hoc API calls. But during the first half of GSoC, I have understood more clearly that the hard part is not just exposing endpoints. The hard part is helping the model follow the right workflow: discover what is available, inspect the required inputs, handle large responses carefully, ask for confirmation when needed, and then call the correct OGC API operation.

From Prototype to Standardized Server

One of the main pieces of work so far has been developing a standardized Python MCP server. The server exposes stable ogc_* tools that map to OGC API concepts. This is important because the tool interface should not depend on one specific backend or demo server. A user or client should be able to work with the same MCP tool names while connecting to different registered OGC API deployments.

The reference server is designed around discovery-first behavior. Instead of assuming that a process exists or guessing an input name, the model is guided to first inspect the server. It can list available servers, read landing pages and conformance information, discover collections or records, list processes, and describe a selected process before building an execution request. This makes the MCP layer more than a simple wrapper. It becomes a workflow layer that helps the language model move through the geospatial task in a structured way.

OGC API Modules Implemented

The current server supports four main OGC API areas: Common, Features, Records, and Processes.

The Common module is used for basic discovery. It includes tools for reading the landing page, checking conformance, and accessing controlled resources from a registered OGC API server. This gives the model a starting point for understanding what a server provides.

The Features module handles vector data workflows. It can list collections, describe a specific collection, retrieve feature items, and fetch an individual feature. This is useful when the user needs to inspect geospatial data before running an analysis.

The Records module focuses on catalogue search. It helps discover datasets and retrieve metadata records. In a real workflow, this can be the first step when the user does not already know which dataset they need.

The Processes module handles executable geospatial operations. It can list available processes, describe a selected process, execute work through the planned workflow, and follow asynchronous jobs through status and results tools.

Together, these modules allow a larger end-to-end workflow. Records can help find a dataset, Features can inspect or reference the data, and Processes can run a geospatial analysis using that data.

End-to-End Workflow

A typical workflow starts with ogc_servers_list, which shows the OGC API servers configured for the MCP server. From there, the model can call ogc_common_get_landing_page, ogc_common_get_conformance, and ogc_proxy_get_capabilities to understand what the selected server supports.
If the user needs to find data, the model can use ogc_records_search and then ogc_records_get_record to inspect a chosen metadata result. If the task requires vector features, it can use ogc_features_list_collections, ogc_features_describe_collection, and ogc_features_get_items.

Only after this discovery should the workflow move toward processing. For that, the model calls ogc_processes_list to discover available processes and ogc_processes_describe to inspect the exact input and output structure of the selected process. This is a key part of the project because OGC API – Processes servers may define their own process identifiers, input names, media types, and output structures. The MCP layer should preserve these exactly instead of inventing or normalizing them. Once the process and inputs are understood, the workflow moves into the planner layer: create a plan, update it if needed, confirm it, and then execute it.

Planner Layer and Process Execution

The planner layer is one of the most important additions so far. Process execution is different from simple data discovery because it can trigger actual geospatial computation. The model should not immediately send arbitrary execution requests. It should first build a validated plan.

The workflow starts with ogc_proxy_create_plan. This tool receives a process execution request and checks whether it can become an executable plan. It validates the selected process, checks the execute request against the process description, and records any unresolved problems. If something is missing or incorrect, the plan returns needs_resolution. If everything is ready, it returns ready_for_confirmation.

When a plan needs correction, the model uses ogc_proxy_update_plan. This is important because the workflow should not restart from scratch every time a user supplies a missing value. The existing plan can be updated with a corrected execute_request, and the server revalidates it.

Once the plan is ready, ogc_proxy_confirm_plan records explicit user approval. This step makes the human-in-the-loop part of the workflow clear. The final request should be shown to the user before it is executed.

Only after confirmation does ogc_proxy_execute_plan run the process. It executes a stored and confirmed plan using its plan_id. This means execution is tied to the plan that was already validated and approved.

The lifecycle is therefore: create, resolve or update if needed, show the final request, confirm, and execute.

Example Flow

For example, imagine a user wants to run a process on a feature collection. The model would first discover the available servers and inspect capabilities. Then it might list feature collections or search records to find the right dataset. After that, it would call ogc_processes_list to find relevant processes. If the server advertises many processes, it could use search_text to narrow the list.

Once a suitable process is found, the model calls ogc_processes_describe to read the exact input names and expected structure. It then creates a plan with the required execute_request. If an input is missing, the planner returns a resolution prompt, and the model asks the user for the missing value. When the plan becomes ready, the final request is shown to the user. After confirmation, the plan is executed and the result can be summarized, stored in proxy memory, or later visualized.

 

 

 

Handling Large Responses: Summarization, Search Text, and Proxy Memory

Another important part of the work has been handling large OGC API responses. Geospatial APIs can return large payloads, especially GeoJSON feature collections, catalogue search results, process lists, and process outputs. Sending all of that directly into a language model context is inefficient and often unnecessary.
To address this, I added a summarization flow. Tools that can return large or unbounded payloads use response_mode=”summary” by default. Instead of placing the full response into the model context, the server returns a compact summary that includes the most useful fields. This gives the model enough information to decide what to do next while keeping the interaction manageable.

The full response is not lost. It is stored in the proxy memory layer behind an opaque memory handle such as mem_*. Later, the model can use that handle to retrieve the stored payload in paginated slices. This is useful when the workflow needs to inspect more details without flooding the context window all at once.

I also added a targeted search_text feature for process discovery. Some OGC API – Processes servers may advertise a large number of processes. In that situation, it is not ideal to repeatedly put long process lists into the model context. With search_text, ogc_processes_list can filter the process list across fields such as ID, title, description, and summary before returning the summarized result. For example, the model can search for terms like buffer or delaunay and receive a much more focused result.

This feature is currently focused on process discovery, not a generic search engine over all stored proxy-memory payloads. But it is an important step toward making large discovery responses easier for the model to work with.

Reflection at Midterm

At the beginning, I thought of this project mainly as a bridge between MCP and OGC APIs. Now I see it more as a workflow design problem. A simple wrapper can expose API endpoints, but it does not help enough with the decisions around them. Which server should be used? Which process exists? What are the exact input names? Is the response too large for the model context? Should the data be summarized or stored? Is the execution request ready, or does the user need to provide more information? These questions are where the MCP layer becomes useful. The work so far has been about adding structure around them: discovery tools, summaries, memory handles, targeted search, and planner states.

This connects back to my original motivation. OGC APIs already provide powerful open geospatial capabilities. The challenge is helping more people use them without needing to understand every endpoint and parameter beforehand. If the system works well, a user can focus on the geospatial question while the MCP layer helps translate that question into the right sequence of API calls.

Next Steps: Building the UI

For the next phase, I will focus on building a user interface on top of this MCP and OGC API workflow. The planned UI will have a map view on one side and a chat interface on the other. The user will be able to talk to the LLM through the chat interface, give instructions, ask geospatial questions, and request analysis. The LLM will use the MCP tools to fetch accurate information, discover the right OGC API resources, run the required workflow, and then return clear results.

Based on the output, the UI will display the result on the map. This is the next important step because the backend workflow makes the tool use structured, while the UI can make the experience visual and accessible. A map and chat interface together can make the system much easier to understand for users who may not be familiar with OGC APIs.

I am grateful to 52°North, my mentors Benjamin Proß and Benedikt Gräler, and the Google Summer of Code program for this opportunity. The first half of the project has helped me understand the technical and design challenges much more deeply, and I am excited to continue building the next layer of the system.

LinkedIn: www.linkedin.com/in/pranav-angrish
GithubRepo: https://github.com/PranavAngrish/OGC-MCP-Service