Skip to main content
Glama

opensolr_search_by_image

Search an Opensolr index with an image by extracting visual labels, OCR text, or barcode/QR code as the query, returning the extracted data and matching documents.

Instructions

Search an Opensolr index with a PHOTO instead of a text query.

The image at image_path is read three ways by the Opensolr image engine —
visual labels (what it depicts), OCR text (words printed on it), and any
barcode / QR code — and turned into a text query that runs through the normal
search. No image vector is stored; the picture simply becomes words.

using selects which reading drives the search:
  "auto"    the engine's chosen text (OCR text when the picture is mostly text,
            otherwise the visual labels) — the default,
  "meaning" the visual labels (what the picture depicts),
  "text"    only the OCR text read off the picture (empty if none),
  "code"    the first barcode / QR code, matched as an exact keyword.

search_mode / mode / alpha / fresh_bias / filter_query behave exactly as in
opensolr_search. Returns {"read": {text, mode, labels, codes}, "results": [...]}
so the caller sees both what the picture was read as and the matching documents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kNo
modeNounion
alphaNo
indexYes
usingNoauto
fresh_biasNo
image_pathYes
search_modeNohybrid
filter_queryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.3

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains that the image is read three ways (labels, OCR, barcode) and converted to a text query, that no image vector is stored, and that the return structure includes both the read interpretation and results. This gives the agent a solid mental model of the tool's behavior, though it omits edge cases like supported image formats or size limits.

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?

The description is longer than average but well-organized: it leads with the purpose, explains the three reading methods, then uses a bulleted list for the 'using' values, and ends with a note on shared parameters and return format. Each sentence adds value, and the structure makes it scannable. It is not overly verbose relative to the complexity of the tool.

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

Completeness4/5

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

Given the tool has 9 parameters and an output schema (though not shown), the description provides the return structure explicitly and references the sibling for shared parameter semantics. It covers the key behavioral aspects and parameter usage, making it sufficient for an agent to call the tool correctly for typical use cases. It doesn't explain all parameter defaults or edge cases, but it does not leave critical gaps that would prevent a correct call.

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

Parameters4/5

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

The schema has 0% coverage, so the description must compensate. It does so for the 'using' parameter with a detailed breakdown of each value (auto, meaning, text, code). For the remaining parameters, it states they behave exactly as in opensolr_search, which is a useful pointer, and the names like index, image_path, and k are self-explanatory. While it doesn't fully describe all 9 parameters, it provides meaningful context for the most important ones and routes to a sibling for the rest.

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 opens with a clear verb-resource pair: 'Search an Opensolr index with a PHOTO instead of a text query.' It explicitly differentiates from the sibling opensolr_search by the input type, and the first sentence states the core function unambiguously. The rest of the description elaborates on how the photo is processed, which reinforces the purpose.

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

Usage Guidelines4/5

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

The description implies when to use this tool: when you have a photo rather than text, saying 'instead of a text query.' It also explains the 'using' parameter to select the reading mode, which guides usage. However, it does not explicitly state when NOT to use it or list alternative tools beyond referencing opensolr_search for shared parameter behavior.

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