Skip to main content
Glama

opensolr_search

Retrieve the most relevant documents from an OpenSolr index using hybrid, semantic, or lexical search modes. Filter results, adjust relevance balance, and apply recency bias for fresh results.

Instructions

Search an Opensolr index and return the k most relevant documents.

search_mode: "hybrid" (default — BM25 + semantic kNN fused per document),
"semantic" (pure kNN), or "lexical" (pure keyword edismax — no embedding
call, zero AI quota, works on ANY index including non-vector ones).
For hybrid: mode is union / keywords_required / meaning_required /
intersection, alpha balances semantic (0) vs lexical (1).
filter_query accepts a raw Solr fq expression, e.g. 'meta_category:"docs"'.
fresh_bias biases the ranking toward recent documents by multiplying each
score by a recency curve on creation_date. It re-orders and never filters:
the hit count is unchanged, nothing old becomes unreachable, and a document
with no creation_date is simply left unboosted. Works in all three search
modes. Off by default — turn it on when newer should beat older on a tie.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kNo
modeNounion
alphaNo
indexYes
queryYes
fresh_biasNo
search_modeNohybrid
filter_queryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations available, the description carries the full burden, and it is exceptionally transparent. It discloses that lexical mode uses zero AI quota, that fresh_bias re-orders but never filters, that hit counts stay unchanged, that documents without creation_date remain unboosted, and that fresh_bias defaults to off.

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

Conciseness5/5

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

The description is long but every sentence earns its place, providing necessary detail for an 8-parameter tool with zero schema descriptions. It is front-loaded with the core purpose and uses line breaks to keep complex mode and bias semantics readable.

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?

All meaningful parameters are covered in the description, and the output schema exists to define the return shape. Given the tool's complexity and absent annotations, the description gives an agent enough context to select modes, set filters, and understand ranking behavior without guessing.

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?

Schema description coverage is 0%, so the description must compensate, and it does. It explains search_mode values, the hybrid-mode sub-parameter 'mode', alpha's semantic-vs-lexical weighting, filter_query syntax with an example, fresh_bias behavior, and k in the opening sentence.

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?

States a specific verb and resource: search an Opensolr index and return the k most relevant documents. This clearly differentiates the tool from sibling operations like listing, deleting, or ingesting indexes, and the first sentence is unambiguous.

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?

Provides strong guidance on when to choose lexical vs semantic/hybrid search modes, when fresh_bias should be enabled, and how filter_query works. However, it does not explicitly compare against sibling tools such as opensolr_ai_answer or explain when one should be preferred over the other.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/phpcip/opensolr-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server