Preparing a portable Earth Observation application involves more than writing processing code that works. An EO Application Package also needs to describe its inputs and outputs correctly, provide the expected metadata, respect packaging and staging conventions, and eventually demonstrate that it can execute under the conditions expected by the target environment.
Terradue has been experimenting with a developer workflow where a general-purpose coding agent works directly with specialised CWL and EO Application Package validation tools through the Model Context Protocol (MCP). Instead of expecting the language model itself to know every validation rule, the agent can ask a dedicated EO-aware tool to check the package, receive structured findings, update the project files and then run the validation again.
The result is a simple development loop where the coding agent helps manage the iteration, while specialised tools remain responsible for the technical checks.
The prototype separates the development loop from the specialised validation logic: the coding agent works with the project, specialised EOAP tools check the package, and the findings are used to guide the next iteration. Some aspects may still require representative execution or expert review.
Bringing specialised EO validation into the coding workflow
In the current prototype, a coding agent running inside VS Code is connected through MCP to an experimental CWL / EO Application Package authoring service.
During a recent development session, the developer asked the agent whether a burned-area severity workflow was a valid EO Application Package. Rather than answering only from its own model knowledge, the agent called a specialised validation function exposed through the MCP server.
The validation combined several types of checks, including CWL validation through cwltool, metadata checks, EO Application Package profile requirements and staging-related checks. The result was returned to the agent as structured technical findings that could be interpreted and acted upon within the same development session.
The first validation showed an interesting mixed result: the workflow passed the basic CWL and metadata checks, while the Application Package profile identified missing information on the results output, including fields such as label and doc. Staging also contained an item requiring further review.
This is exactly the kind of distinction we want the tooling to preserve as a workflow can be valid CWL without yet satisfying all the requirements expected from a complete EO Application Package.
From findings to changes in the project
The next step was deliberately simple. The developer asked the coding agent to fix the failure and the items that could be addressed from the project itself.
The agent inspected the validation report, modified the relevant workflow and configuration files and then called the specialised validator again.
The second validation no longer reported the previous static failures. One item remained for review because confirming it required representative execution and could not be established reliably from static source inspection alone.
Live development session in VS Code: the coding agent calls specialised EO Application Package validation through MCP, interprets the structured findings, edits the project and reruns the validation. The updated result clears the static failures while retaining an execution-dependent item for review.
This distinction is important. The objective is not to have an agent modify files until every indicator becomes green. Some properties can be checked deterministically from the package itself, while others depend on runtime behaviour, representative data, scientific validity or expert judgement.
The agent does not replace the validator
The interesting part of this experiment is therefore not simply “MCP inside VS Code”.
The coding agent and the specialised EOAP tools have different responsibilities.
The coding agent can inspect the workspace, understand relationships between files, reason over the findings, edit CWL and configuration files and manage the iterative development loop.
The EOAP-specific tools provide the specialised knowledge needed to check CWL syntax and semantics, Application Package requirements, metadata and staging conditions, and return those results in a structured form that the agent can use.
This means that the language model does not need to become the authority on EO Application Package conformance. It can call the tool that implements the relevant checks and work from the evidence returned by that tool.
For application developers this can create a much more useful form of AI assistance: the agent helps with navigation and iteration, while standards-aware tooling remains responsible for the rules that can be checked deterministically.
Why this matters for GEP
EO Application Packages are an important part of how portable processing capabilities can be prepared and exposed as services in the GEP ecosystem.
Developing and maintaining these packages still involves several technical iterations around inputs and outputs, metadata, containers, staging, documentation and execution behaviour. A developer may need to run validators, interpret their output, identify the corresponding source files, make changes and then repeat the process.
Bringing specialised validation into the coding workflow can make this cycle more interactive without changing where technical authority sits.
This is particularly relevant for GEP service providers and application developers because the longer-term objective is to make it easier to bring existing EO processing capabilities into interoperable environments without unnecessary rewriting.
A processing chain still has to satisfy the applicable standards, packaging rules and operational requirements. The agent can help the developer get there more efficiently.
More broadly, this is also a way of bringing existing geohazards knowledge into agent-assisted workflows without asking a language model to reproduce that knowledge itself. Years of research are already embodied in processing chains, scientific models, EO Application Packages, notebooks, validation tools and operational methods, and much of that value can be preserved by making these capabilities easier for agents to discover and use through well-defined interfaces.
For GEP, the opportunity is therefore not to rewrite established geohazards methods around a particular AI model, but to make those methods increasingly agent-ready while keeping the scientific logic, validation rules and technical authority in the specialised tools that already implement them.
Agent-ready also applies to developers
In our recent topic Towards an agent-ready Earth Observation ecosystem, we looked mainly at how data, processing services, models and other capabilities can become easier for assisted workflows to discover and use.
This experiment shows another side of the same direction.
Before an agent can reliably discover or use an EO processing capability, someone has to create, describe, validate and maintain that capability. Developer-facing agents can help with this part of the ecosystem as well, especially when they are connected to specialised tools that understand the relevant standards and technical requirements.
The same principle applies here as in the wider GEP roadmap: agents should be able to discover and use well-defined capabilities without becoming the place where EO and geohazards knowledge is reimplemented. The specialised software, standards, scientific methods and validation tools remain authoritative, while the agent helps connect them into a more efficient development workflow.
What comes next
This is currently a working development prototype rather than a public GEP service.
The experiment demonstrates that a general-purpose coding agent can call specialised EO Application Package validation tools through MCP, use the resulting structured findings to modify a project and repeat the validation cycle while preserving the distinction between static conformance and aspects that still need runtime or expert verification.
Further work can explore which additional Application Package authoring and validation capabilities are useful to expose in this way, how the approach can support developers working with portable EO applications, and where agent assistance can reduce repetitive work without removing the controls needed for reliable and interoperable processing services.
This topic describes an experimental developer capability currently being explored by Terradue. It does not announce an operational GEP authoring service, automatic deployment of EO Application Packages to GEP, automatic catalogue onboarding, or end-to-end execution of the resulting application on GEP.