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 the wire-envelope protocol version from catalog/taxonomy.yaml. Additive field, source, or preset growth does not bump it; clients discover those additions through the catalog payload and its ETag. The version changes only when the response envelope or another wire-visible protocol contract changes. Read the version from the JSON response body (there is no version response header), cache the payload by ETag, and feature-detect field names instead of assuming that one protocol version freezes catalog membership.
us_envelope remains the backwards-compatible coarse primary envelope. The runtime validator also accepts the positive-longitude Western Aleutian rectangle: lat ∈ [51, 54], lng ∈ [172, 180). Client-side validation must accept either region.

Response

200 - application/json

Successful Response