Skip to main content
Glama

search_catalog

Read-only

Search Umbra's catalog and return compact context cards.

Filters (all optional, combine freely): ``bbox`` as
``[min_lon, min_lat, max_lon, max_lat]`` in WGS84 degrees; ``intersects`` as
a GeoJSON polygon object (a ``Polygon`` / ``MultiPolygon`` geometry, or a
``Feature`` / ``FeatureCollection`` wrapping one) to keep only footprints
intersecting it -- a tighter spatial filter than the rectangular ``bbox``,
and mutually exclusive with ``bbox`` / ``place``; ``place`` as a
free-text name geocoded to a bbox; ``area`` as a substring of the Umbra
task (site) name (set ``fuzzy`` to match it loosely -- word-order- and
punctuation-independent and typo-tolerant, resolved deterministically with
no model call, so ``"beet piler"`` still reaches ``"Beet Piler - ND"`` and
``"utah centerfield"`` still reaches ``"Centerfield,
Utah"``; set ``semantic`` instead to treat ``area`` as a plain-language
*description* of a site whose name you don't know and resolve it to the
closest task names by *meaning* via the prebuilt embedding index, so
``"grain storage north dakota"`` reaches ``"Beet Piler - ND"`` -- a query
that shares no word with the label, which ``fuzzy`` cannot and should not
fake; ``semantic`` and ``fuzzy`` are mutually exclusive, and the resolved
task name is returned as ``resolved_area`` with the ranked candidates in
``semantic_matches`` so you can audit and retry with a different one, and
``min_score`` -- a cosine threshold in ``[0, 1]`` -- drops weak aliases, so
a description that matches nothing confidently returns an empty result
rather than an arbitrary top pick); ``start``/``end`` as acquisition-date
bounds -- an ISO
``YYYY-MM-DD`` date, a bare year/month (``2024``, ``2024-03``), or a
relative expression (``today``, ``yesterday``, ``3 months ago``,
``last month``), resolved deterministically with no model call;
``products`` to restrict to product types
(any of GEC, SICD, SIDD, CPHD); the SAR acquisition-property filters
``polarizations`` (keep items exposing any of these, e.g. ``["VV"]`` -- the
filter that keeps a change comparison like-with-like), ``min_incidence`` /
``max_incidence`` (view incidence-angle bounds in degrees) and
``max_resolution`` (keep items at least this fine, in metres) -- each a hard
predicate that excludes items missing that metadata; ``canonical`` to keep
the preferred copy of a collect Umbra republished under another prefix
(``True``), only the other copies (``False``), or every item when omitted;
``limit`` to cap
results; ``max_per_task`` to cap items per site (use 1 for a one-pin-per-site
overview).

``local`` selects the backend: leave it unset to use the on-disk index when
present (instant) and fall back to a live S3 walk otherwise. When the server
is configured with a Canopy token (``$UMBRA_CANOPY_TOKEN``), the search runs
against Umbra's authenticated commercial archive instead and ``source`` is
reported as ``"canopy-archive"``. Returns the per-item context cards, not
full STAC JSON, to protect the context window; call ``get_item`` for one
item's full metadata.

Prefer ``fuzzy=True`` (or :func:`find_repeat_sites`) when ``area`` shares
words with a task name; that path is deterministic and needs no key.
``semantic=True`` is only for a description that shares **no** tokens with
the label. It requires a task-embedding index built ahead of time with
``umbra semantic build`` and a user-supplied embedding key (``OPENAI_API_KEY``,
optionally ``OPENAI_BASE_URL`` / ``UMBRA_EMBED_MODEL``); it raises a helpful
setup error otherwise, so it never runs implicitly. The only model call is
turning ``area`` into a vector -- the resolved search over the chosen backend
stays fully deterministic.

Input Schema

NameRequiredDescriptionDefault
endNo
areaNo
bboxNo
fuzzyNo
limitNo
localNo
placeNo
startNo
productsNo
semanticNo
canonicalNo
min_scoreNo
intersectsNo
max_per_taskNo
max_incidenceNo
min_incidenceNo
polarizationsNo
max_resolutionNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the simple `readOnlyHint`, the description provides crucial behavioral traits: it specifies the return format (compact cards, not full STAC JSON), the determinism of the search (no model call unless `semantic=True`), and the explicit logic behind `min_score` dropping weak matches.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While the description is exceptionally dense and long, its structure follows a logical pattern of parameter-by-parameter definition, ensuring that despite its size, no critical information is lost or poorly placed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity and the fact that the input schema provides virtually no documentation, the description is maximally complete, explaining prerequisites (like the need for a task-embedding index for `semantic=True`) and output implications.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the entire semantic weight. It defines units (WGS84, degrees, meters), syntax (ISO format vs. relative expressions), and the specific geometric requirements for complex parameters like `bbox` and `intersects`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The tool clearly states its core function: 'Search Umbra's catalog and return compact context cards.' It immediately distinguishes itself from potential alternatives by detailing the extensive filtering capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides detailed decision matrices for usage, specifically comparing and contrasting: `bbox` vs `intersects`, `fuzzy` vs `semantic` filters for 'area', and specifying when to use `local` to target different backends (on-disk vs authenticated archive).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.