Feature Request: Native Model Context Protocol (MCP) Server Integration

[ChrisJohnNOAA]

Adding MCP support to the ERDDAP server would enable easy querying by LLM models. By being part of ERDDAP we can support the functionality more efficiently than an external MCP can.

What is MCP? MCP is an open standard that enables AI assistants to connect to data sources. By implementing an MCP server, ERDDAP would expose its datasets as "resources" and its API functions (search, griddap, tabledap) as "tools" that AI agents can discover and execute safely.

Implementation Concept: This could be implemented as a new handler within the Erddap servlet, or possibly as a new Servlet within the existing ERDDAP Java web application.

Protocol: JSON-RPC 2.0 (over generic HTTP or SSE).

Library: Use the official Java SDK for MCP.

The MCP server would expose standard tools such as:

search_datasets(query): Wraps the existing OpenSearch/Lucene search.

get_schema(dataset_id): Returns the metadata, variables, and units (reducing LLM hallucination).

fetch_data(dataset_id, constraints): returns a JSON or CSV snippet of the data.

Describe alternatives you've considered

External Sidecar: Users can run a separate middleware service (e.g., a Python script) that translates MCP requests to ERDDAP API calls. Downside: This puts the burden on the user to host and configure extra infrastructure.

OpenAPI/Swagger only: While ERDDAP has good docs, raw OpenAPI specs are often too large or complex for LLMs to navigate efficiently compared to the optimized MCP tool definition structure.

Additional context

Benefits to the Community:

"Chat with your Data": Users could connect their local AI clients (like Claude Desktop) directly to their organization's ERDDAP URL and ask, "Plot the temperature trends from station 42 from last week," without writing a single line of Python.

Standardization: Just as ERDDAP standardized REST access for humans/scripts, this standardizes access for Agents.

Discoverability: It lowers the barrier to entry for non-technical users to utilize the rich data hosted on ERDDAP servers.

Example "Tool" Definition (Conceptual): The MCP server would automatically generate tool definitions like this for the AI:

{
  "name": "erddap_tabledap",
  "description": "Retrieve tabular data from ERDDAP datasets.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "dataset_id": { "type": "string" },
      "variables": { "type": "array", "items": { "type": "string" } },
      "time_range": { "type": "string", "description": "ISO formatted time range" }
    },
    "required": ["dataset_id"]
  }
}

[srstsavage]

An interesting perspective on MCP implementation here: https://blog.cloudflare.com/code-mode/

The authors basically argue that typescript APIs should be presented to MCPs instead of implementing an exhaustive set of tool methods, as LLMs are much better at writing code against APIs than calling arbitrary tools. This approach apparently results in a much lower rate of token consumption as well.

Compelling implementation example: https://blog.cloudflare.com/code-mode-mcp/

[ChrisJohnNOAA]

An interesting perspective on MCP implementation here: https://blog.cloudflare.com/code-mode/

The authors basically argue that typescript APIs should be presented to MCPs instead of implementing an exhaustive set of tool methods, as LLMs are much better at writing code against APIs than calling arbitrary tools. This approach apparently results in a much lower rate of token consumption as well.

Compelling implementation example: https://blog.cloudflare.com/code-mode-mcp/

If I understand that, the process is still to make an mcp server and then wrap it (most easily on the client side). We can certainly provide information on how to do that.

I do also suspect they are partially solving a problem we won't have. I was hoping to keep the ERDDAP mcp small (search for a datast, request data with output format specified). So the token cost of the mcp server definition shouldn't be very high.

[rmendels]

@ChrisJohnNOAA @srstsavage For what it is worth in the upcoming ERDDAP™ showcase I will be showing using plain language within positron to access and plot ERDDAP™ data, without having to construct a MCP. It works reasonably well (well sort of) because positron has an added-on that is aware of your workspace and environment, and this is both for R and Python. The user does not need to do any extra coding.

I had constructed an MCP for R and ERDDAP™, but they kept changing the packages and keeping up with that was a lot of work, and that didn't perform all that much better than just using what positron had built. If you want to play around with it, you need to install:

https://positron.posit.co/assistant.html

follow the steps to link to your account for whichever LLM you are using, Also look at positron databot:

https://positron.posit.co/databot.html

Works pretty well if I have say a netcdf file and want to do things with it in plain language.