Skip to main content
GET
Meta Fields

When to use this

Hit /v1/meta/fields once at startup to discover the catalog. The response sets ETag and Cache-Control: public, max-age=3600, so a long-lived agent or service fetches it once an hour at most. The catalog drives:
  • Client-side validation — reject unknown field names before sending a /v1/fetch request.
  • Tool descriptions — agents that build their own UI from the catalog populate field pickers and preset selectors from this endpoint.
  • LLM planners — third-party agents that route to Mireye via the MCP server can render the catalog into their own planner system prompt, same as Mireye’s /v1/ask does internally.

Response shape

Self-discovery flow

The recommended client pattern:
If-None-Match returns 304 Not Modified with no body when the catalog hasn’t changed. The ETag covers the whole payload, so any catalog change — new fields, edited hints, preset changes — produces a fresh ETag alongside the version bump (see the versioning policy). Each field object also carries honesty metadata: nullable marks fields that can legitimately return null at valid coordinates, and null_meaning says what such a null means (e.g. “no wetland within the search radius”) so clients don’t misread semantic absence as a fetch failure.

How the catalog drives the planner

Mireye’s own /v1/ask planner renders the catalog into its system prompt:
The system prompt is prompt-cached (catalog-sized — roughly 19 K tokens at catalog 0.6.0) so subsequent planner calls pay ~90% off input cost. Third-party agents that build their own planner can use the exact same pattern.

Versioning

The version field is a manual SemVer bump maintained alongside the catalog source (src/mireye_earth/ask/catalog.py, which carries the version history as a changelog comment):
  • Patch (e.g., 0.6.00.6.1) — wording-only changes: description or interpretation_hints improved, no field added or changed. Safe to ignore for existing clients.
  • Minor (0.5.x0.6.0) — additive, backwards-compatible changes: new fields or new presets registered. Existing field names, types, and semantics are untouched. (This is the common case — the catalog moved 0.2.00.6.0 through additive field registrations.)
  • Major (0.x.y1.0.0) — breaking: field renamed, type changed, or removed. Clients hardcoding field names must be updated.
The version is only available in the response body — read it from the JSON (there is no version response header).

Response

200 - application/json

Successful Response