Introducing My GSoC 2026 Project with 52°North: MCP for OGC APIs

Hi everyone,

I am Pranav Angrish, a final-year Computer Science and Engineering student from Thapar Institute of Engineering and Technology, India. This summer, I am excited to be 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.

The project sits at an intersection I find deeply interesting: open geospatial standards, intelligent software agents, and making complex technical systems easier for people to use. Over the next few months, I will be working on a bridge between OGC APIs and the Model Context Protocol, so that large language models can interact with geospatial services through well-defined, structured tools instead of brittle ad-hoc API calls.

First Steps with the 52°North Community

Our first community meeting took place on 13 May 2026. It was a warm introduction to 52°North, the organization, the people involved, and the two GSoC projects selected this year. The meeting included Sebastian Drost, Benedikt Gräler, Benjamin Proß, Katharina Demmich, Martin Pontius, Ann Hitchcock, Shashaank Srivastava, and me. Shashaank is the other selected GSoC contributor this year, working on a different 52°North project. It was a helpful start because it placed the project in the larger context of the organization. This is not just about building a prototype in isolation. It is about contributing to an open-source geospatial ecosystem with real users, established standards, and long-running community work behind it.

Why This Project Matters

The Open Geospatial Consortium has developed a suite of modern web APIs for geospatial data and processing, including OGC API – Features, Records, Environmental Data Retrieval, and Processes. These APIs are powerful and increasingly important across the geospatial domain. However, using them well still requires a lot of expertise. A user often needs to know which endpoint to call, how to structure request parameters, how to handle coordinate reference systems, how to paginate through large responses, and how to chain multiple services together. For a GIS developer, this is familiar territory. For an urban planner, researcher, policymaker, or domain expert who simply wants to answer a spatial question, it can become a major barrier.

This is where the Model Context Protocol becomes interesting. MCP gives language models a structured way to interact with external tools. If OGC API operations can be described as MCP tools, then a user could express a geospatial task in natural language while the system translates that intent into precise, standards-compliant API calls. For example, instead of manually discovering endpoints and writing requests, a user could ask: Create a 1 km buffer around this location and calculate statistics for the values inside it. The MCP layer would help the language model identify the right OGC API operation, resolve the required inputs, call the service, and return a useful result.

What I Built Before the Coding Period

As part of the selection process, I completed the OGC API coding challenge. I built an OGC API – Processes backend using pygeoapi, containerized with Docker, and protected behind an nginx reverse proxy with JWT authentication. The backend includes two geospatial processes:

• A buffer process that creates a circular polygon around a coordinate point
• A zonal statistics process that computes descriptive statistics for values inside a polygon

The buffer process also handles projection properly. It transforms coordinates from WGS84 to Web Mercator for metric buffering, then transforms the result back to WGS84 for GeoJSON output. This was one of the early moments where the project became very real for me: even a simple-sounding operation like “create a buffer” has important geospatial details hidden inside it.
https://github.com/PranavAngrish/OGC-API—Processes

 

Beyond the coding challenge, I also built an initial MCP prototype. This prototype connects natural language tool use to OGC API operations across three modules:

• OGC API – Processes
• OGC API – Features
• OGC API – Records

The current draft mapping specification defines 15 tools across these modules. It describes each tool through its purpose, natural language triggers, HTTP mapping, input schema, output summary, follow-up tools, and error handling. The goal is for the mapping specification to become the central artifact, with the Python MCP server acting as one reference implementation. That way, the same mapping idea can eventually be implemented in other languages and integrated into other parts of the geospatial ecosystem.
https://github.com/PranavAngrish/OGC-MCP-Service

The Core Idea: A Spec-First Bridge

The project is not only about wrapping APIs. A thin wrapper would expose endpoints, but it would not solve the deeper usability problem. The MCP mapping needs to help with things like:

• Discovering what a server supports
• Matching user intent to available OGC API capabilities
• Resolving required inputs
• Handling CRS differences
• Managing pagination
• Summarizing large GeoJSON responses
• Translating errors into useful next steps
• Preventing unsafe or hallucinated tool calls

This is why I am approaching the project as a spec-first bridge. The mapping specification should describe not only how to call an endpoint, but also how that endpoint fits into a larger geospatial workflow. For example, a Records search may discover a dataset, a Features request may fetch its geometry, and a Processes request may run an analysis on it. The interesting part is not any single API call. The interesting part is making the chain understandable, reusable, and safe.

What I Will Work On During GSoC

During the coding period, I will work with my mentors Benjamin Proß and Benedikt Gräler to turn the prototype into a more robust and community-ready contribution. The main areas of work include:

• Formalizing and validating the OGC API to MCP mapping specification
• Building a more intelligent proxy layer for capability negotiation, CRS handling, pagination, and response summarization
• Adding safety mechanisms such as tool validation, ambiguity handling, and human-in-the-loop confirmation
• Making tests and documentation so the project can be extended by others
• One of my goals is to make the project useful not only as a demo, but as a foundation that other developers in the geospatial community can understand, test, and build upon.

My Motivation

When I first came across this project, I did not have prior experience with OGC APIs. My way of learning was to build. I read the specifications, set up pygeoapi, implemented processes, worked through authentication and deployment, and then built the MCP prototype to test whether the larger idea was viable. That process changed how I understood the project. At first, it looked like an integration task. Now I see it as an accessibility problem. There is a lot of geospatial capability already available through open standards. The challenge is helping more people reach it without requiring them to become API experts first. If this project succeeds, a user should be able to focus more on the question they want to answer and less on the technical choreography needed to answer it. That is the kind of software I enjoy building: systems that make other systems easier to use.

Looking Ahead

I am grateful to 52°North, my mentors Benjamin Proß and Benedikt Gräler, and the Google Summer of Code program for this opportunity. I am also looking forward to learning from the broader 52°North community throughout the summer.
In the coming weeks, I will share more updates about the mapping specification, the MCP server architecture, and the first end-to-end workflows. I am excited to begin this journey and contribute to open geospatial software in a meaningful way.

LinkedIn : https://www.linkedin.com/in/pranav-angrish
GitHub : https://github.com/PranavAngrish