Skip to main content
Glama

find_similar

Read-only

Find archived scenes that look like the acquisition at url.

This is the one search that lives in the pixels, not the metadata: where
``search_catalog`` filters by date/bbox/task-name, this renders the query
item's quicklook, embeds it, and ranks the pre-embedded scene index by visual
(cosine) similarity — "find scenes that look like this flooded field / crowded
berth / runway". The query item is excluded from its own results.

Requires a scene-embedding index built ahead of time with ``umbra embed
build`` (a sidecar ``catalog.embed.db`` beside the catalog index) and a
user-supplied multimodal embedding key (``OPENAI_API_KEY``, optionally
``OPENAI_BASE_URL`` / ``UMBRA_SCENE_EMBED_MODEL``) — the only model call is
turning the query image into a vector; ranking is deterministic. ``asset``
picks which product's quicklook to embed (default ``GEC``; match how the index
was built); ``model`` must match the index's embedding model. Returns the
ranked matches as compact records (each with the acquisition's ``href``, so
hand it to ``get_item`` / ``quicklook`` / ``change_composite`` next) plus the
attribution line.

Input Schema

NameRequiredDescriptionDefault
urlYes
assetNoGEC
modelNo
top_kNo
min_scoreNo

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?

The description is highly transparent about operational requirements, detailing the need for a pre-built scene-embedding index, required API keys, and the deterministic nature of the ranking process (cosine similarity). This adds massive context beyond the simple 'readOnlyHint: true' annotation.

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 highly detailed, the initial paragraphs define the scope concisely and front-load the purpose. The subsequent technical explanation is dense and long, but the length is necessitated by the complexity of the underlying workflow (embedding index dependencies).

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?

This is a maximally complete definition for a complex, data-intensive tool. It outlines prerequisites (index build), operational constraints (API keys), and specifies the utility of the output data (use href with 'get_item'/'quicklook').

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?

Since schema coverage is 0%, the description must carry the full burden. It successfully adds semantics to all key parameters, explaining what 'asset' refers to (product quicklook source), what 'model' must match (the index embedding model), and the purpose of 'top_k' (ranked matches).

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 description provides an extremely clear purpose: to find archived scenes that 'look like' a specific URL acquisition. It clearly defines the scope as visual, contrasting it sharply with metadata searches like those performed by 'search_catalog'.

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?

It provides explicit guidance on when to use this tool versus alternatives. It contrasts its visual, embedding-based ranking mechanism against the metadata filtering of 'search_catalog,' leaving no ambiguity for the agent.

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.