Reviving Legacy SOAP APIs: Building a JSON and MCP Wrapper for Spain's Cadastre API

When a 2003 SOAP Interface Meets Modern Development

For many developers, stumbling upon a government data API still running on decade-old technology feels like a jarring time warp. Recently, a developer shared their project on Hacker News: they discovered that Spain's Cadastre (land registry) API was still built on a SOAP interface designed in 2003, and decided to build a modern JSON wrapper on top of it — along with MCP (Model Context Protocol) support.

Cadastre data is a core public dataset at the national level, used to record land parcels, properties, boundaries, area measurements, and ownership information. This kind of data is in high demand across real estate, urban planning, financial risk assessment, and AI applications. Yet with the official interface frozen in the SOAP era, developers must wrestle with verbose XML envelopes, WSDL definitions, and sprawling namespaces — a far cry from the JSON and REST paradigms that dominate modern development.

Why SOAP Has Become a Stumbling Block for Modern Development

The Fundamental Differences Between SOAP and JSON

SOAP (Simple Object Access Protocol) was born in 1998, driven by companies like Microsoft and IBM, with version 1.0 released in 1999 and formally ratified as a W3C standard in 2003 — which is precisely where Spain's Cadastre API has remained frozen. SOAP was designed to solve enterprise-level interoperability problems across platforms and languages. It relies on WSDL (Web Services Description Language) files to describe service contracts, allowing clients to auto-generate calling code and theoretically guaranteeing strict type safety and interface versioning.

However, as internet applications exploded in scale, SOAP's verbosity became a fatal flaw — a simple query request might span hundreds of lines of XML, with actual business data occupying only a tiny fraction. In 2000, Roy Fielding introduced the REST architectural style in his doctoral dissertation, and JSON gradually displaced XML as the dominant data exchange format. By around 2010, the combination of REST and JSON had firmly established itself as the mainstream paradigm for modern Web APIs, pushing SOAP to the margins.

For developers looking to quickly access Spain's Cadastre data, working directly with the SOAP interface means pulling in additional parsing libraries, writing complex serialization logic, and absorbing significant learning and maintenance overhead.

The Core Value of a Wrapper Layer

This developer's approach is a textbook example of the Adapter Pattern in software engineering. The Adapter Pattern is one of the 23 classic design patterns defined in the GoF book Design Patterns. Its core idea: when two existing interfaces are incompatible, introduce an intermediate layer that converts one interface to another, enabling previously incompatible components to work together. In the world of legacy system integration, this "leave the old system untouched, build a new layer on top" strategy is sometimes called a variant of the Strangler Fig Pattern — the old system keeps running stably while the new wrapper layer evolves independently, with minimal risk.

This JSON wrapper layer handles several key responsibilities:

• Translating incoming REST/JSON requests into the underlying SOAP calls
• Parsing the returned XML and converting it into structured JSON
• Hiding implementation details like namespaces and WSDL, exposing a clean interface to consumers

With this layer in place, any application using a modern tech stack can consume Spain's Cadastre data just like any ordinary REST API, with no need to ever touch the ancient implementation underneath.

MCP Integration: Letting AI Read Cadastre Data Directly

The most compelling highlight of this project is its additional MCP (Model Context Protocol) support. MCP was officially released and open-sourced by Anthropic in late 2024, designed to solve the "last mile" connection problem between large language models and external tools and data sources.

MCP drew inspiration from one of software engineering's most successful precedents — LSP (Language Server Protocol). LSP standardized the interaction between code editors and language toolchains, enabling any editor like VS Code or Neovim to plug in and instantly gain capabilities like code completion and go-to-definition. It fundamentally transformed the IDE ecosystem. MCP aims to replicate that success for the AI agent world: it defines three standardized primitives — Resources (data sources), Tools (callable functions), and Prompts (prompt templates) — so that any MCP-compliant AI client can connect to the external world on a "build once, use everywhere" basis.

By wrapping the Cadastre API as an MCP service, the developer has effectively given Claude and other MCP-compatible AI assistants the ability to directly query Spanish land and property data. A user can ask a natural language question like "What is the area and land use classification of the parcel at this address?" and the AI can call the JSON wrapper through MCP, ultimately reaching that 2003 SOAP interface and returning a structured answer.

This combination of "legacy data source + MCP" points to a highly imaginative path forward: vast amounts of public data buried behind outdated interfaces can be reactivated through wrapping and MCP integration, becoming knowledge sources that AI agents can tap into in the modern era.

Broader Lessons for Modernizing Public Data

The Historical Baggage of Government Data Interfaces

Spain's Cadastre API is far from an isolated case. Parts of the U.S. federal government still run core systems on COBOL programs written for mainframes dating back to the 1960s and 70s. The UK's NHS long relied on Windows XP for critical operations. Japan only announced plans to phase out floppy disks as an official data submission medium in 2021. The reasons are multifaceted: the stability demands of core systems breed a conservative "if it isn't broken, don't fix it" mindset; migration costs for replacing these systems routinely run into hundreds of millions or even billions of dollars; government procurement processes are slow, and technology decision cycles lag far behind the pace of technological change; and the pool of professionals who can maintain legacy systems keeps shrinking, creating a path dependency that's hard to break.

This is why replacing or refactoring these core systems often involves enormous cost, risk, and administrative overhead — they routinely remain in service for fifteen or twenty years. For developers who depend on this data, building a bridge themselves is far more practical than waiting for an official modernization effort. Community-driven wrapper projects end up playing a critical data infrastructure role during the long wait for official system upgrades.

Small, Elegant Open Source in Practice

Judging by the discussion activity on Hacker News, this is a quintessential "developer scratching their own itch" project — no grand commercial ambitions, just a precise solution to a real and concrete pain point. The value of projects like this lies in:

• Dramatically lowering the barrier for others to access a specific data source
• Providing a reusable technical pattern (SOAP-to-JSON + MCP)
• Demonstrating how modern tooling can breathe new life into aging infrastructure

For developers who regularly grapple with legacy systems, this project offers a clear and borrowable template.

Closing Thoughts

From SOAP in 2003 to JSON and MCP today, this project compresses nearly two decades of Web technology evolution into a single repository. It's a reminder that the value of technology lies not only in creating entirely new things, but also in building bridges to the future for systems that are still running and still matter. As more and more public data gets wired into the AI ecosystem through wrappers like this, the era where "all data is conversational" may be closer than we think.