Summary

I would like to propose adding a standard, protocol-level way for MCP tools to return provenance metadata alongside tool results.

I am building an MCP server for UXarray, a Python library for analyzing and visualizing unstructured climate and Earth-system model grids. In this workflow, MCP tools operate over local and HPC-resident NetCDF/UGRID/MPAS datasets, run UXarray analyses, generate plots, and sometimes route execution to remote Globus Compute endpoints so large scientific files never leave the facility filesystem.

That has made provenance a first-class need rather than a nice-to-have. MCP already has structuredContent, content annotations, resource links, and _meta, but there is no protocol-recognized place for provenance that clients can preserve, display, validate, or chain across tool results.

Motivation from the UXarray MCP server

The UXarray MCP server exposes tools for mesh and variable inspection, validation, area and zonal-mean calculations, comparison metrics, subsetting/remapping, plotting, persisted result handles, workflow status, and optional HPC execution diagnostics.

For scientific analysis, a returned number or image is not enough. Users and downstream agents need to know:

• which input files, dataset handles, variables, grid paths, and result handles were used
• whether execution happened locally or on a remote/HPC endpoint
• which library/runtime versions produced the result
• which plot or analysis parameters were applied
• which workflow/session/operation produced an artifact
• whether the result is reproducible, cacheable, or derived from mutable external state
• what artifacts were created, where they live, and how they can be re-used

Today I can include ad hoc fields like _provenance, execution_venue, session_id, workflow_id, result_handle, plot_params, and artifact metadata inside each tool's JSON result. That works inside one server, but it is not interoperable. Hosts, clients, agents, and other MCP servers cannot reliably recognize, display, persist, filter, or chain this metadata because every server must invent its own schema.

Proposal

Add an optional standard provenance envelope to MCP tool results. This could be a core tool-result field, a reserved _meta key, or a recommended extension with a path toward standardization.

At a high level, a tool result could include protocol-recognized metadata such as:

{
  "content": [...],
  "structuredContent": {...},
  "provenance": {
    "inputs": [
      {
        "kind": "file",
        "uri": "file:///path/to/grid.nc",
        "role": "grid",
        "digest": "sha256:...",
        "mutable": false
      },
      {
        "kind": "variable",
        "name": "temperature",
        "role": "analyzed_variable"
      }
    ],
    "operation": {
      "name": "calculate_zonal_mean",
      "parameters": {
        "conservative": true,
        "lat_spec": [-90, 90, 5]
      }
    },
    "execution": {
      "venue": "hpc",
      "endpoint": "globus-compute:<endpoint-id>",
      "started_at": "...",
      "completed_at": "..."
    },
    "environment": {
      "software": [
        {"name": "uxarray", "version": "..."},
        {"name": "python", "version": "..."}
      ]
    },
    "artifacts": [
      {
        "kind": "image/png",
        "name": "zonal_mean_plot",
        "uri": "mcp-artifact://...",
        "digest": "sha256:..."
      }
    ]
  }
}

The exact schema is open for discussion. The main request is that provenance be discoverable by generic MCP clients rather than hidden inside arbitrary server-specific JSON.

Client behavior this would enable

Standard provenance would let MCP clients and agents:

• show a consistent "how this result was produced" view
• preserve provenance when passing results between tools
• distinguish generated artifacts from source inputs
• reason about local vs remote/HPC execution
• cache or invalidate results more safely
• audit analyses without every server inventing separate conventions
• export provenance to external standards such as RO-Crate, W3C PROV, or domain-specific scientific workflow metadata

This seems useful beyond UXarray. Similar needs should appear in data science, bioinformatics, geospatial analysis, simulation, ETL, notebooks, CI systems, and any MCP server that returns generated artifacts or derived data.

Related observations

A few recurring patterns motivated this proposal:

1. Scientific users often ask follow-up questions about a result after the original tool call is no longer visible. Persisted result handles help, but only if the result carries enough provenance to explain itself later.
2. Remote/HPC execution makes provenance more important because the host may never see the raw input data, only derived outputs.
3. Plots need provenance too: colormap, bounds, dimensions, selected variable, and rendering environment all affect interpretation.
4. Tool chains become easier to validate when each result records its parent inputs and operation parameters.
5. Ad hoc _provenance fields are useful but cannot be reliably interpreted by generic MCP clients.

Open questions

• Should provenance be part of the core tool result schema, a reserved _meta field, an annotation, or a recommended extension?
• Should MCP align with an existing model such as W3C PROV, RO-Crate, or a simplified MCP-native schema?
• Should provenance support both public display metadata and private/client-only metadata?
• Should artifacts and result handles have standardized identifiers and digests?
• Should hosts be encouraged to preserve provenance automatically across tool-result references?

I would be happy to share more concrete examples from the UXarray MCP server if useful. My main request is to make provenance discoverable and interoperable across MCP clients and servers.