Skip to main content
Glama
This connector has been deprecated

Batch search (several queries)

shamela_search_batch
Read-onlyIdempotent

بحث مجمَّع بعدة استعلامات

Run up to 12 scoped searches in ONE call and get back a single merged, deduplicated result set. Built for assembling evidence for one question from several wordings at once: each probe is {query, mode:'and'|'phrase'|'near', scope, limit}, they execute concurrently, and pages found by more than one probe are returned ONCE with every probe id that found them (probe_ids) — which is corroboration across wordings, not a duplicate. Every row carries match_quality ('exact_phrase'|'near'|'all_terms'|'relaxed') and matched_in_section ('body'|'footnote'|'both') so a near miss can never be read as a located quotation once results are merged, and a modern editor's footnote is never quoted as the author's own words. Every row also carries work_group_id, and edition_groups names any work present here under several catalog entries — read those as ONE source, not as several that corroborate each other. scope is REQUIRED on every probe (one of book_ids/author_ids/category_ids/madhab): unscoped, Lucene ranks by term frequency across all 8,594 books, so «التيمم» returns a poetry anthology ahead of the fiqh manuals. A probe that fails or times out is reported in its own slot and does NOT discard the others; incomplete is then true and a thin result must NOT be read as the library being silent. Each completed probe carries qualifiers — terms_truncated, zero_hit_terms, respelled_terms, paging_ceiling, coverage.at_cap, candidate_cap_hit, scope_resolution, unattributable_books — the same caveats the single-call search returns, per probe; the block is present only on status:'ok', so a probe WITHOUT it has not been checked and must not be recorded as searched. scope_resolution.dropped lists book ids the catalogue does not hold, which were never searched — the guard against reading an invented id's silence as the library's. Example: shamela_search_batch({probes:[{query:'الوتر واجب', scope:{category_ids:[14,19], citable_only:true}}, {query:'حكم صلاة الوتر', mode:'near', distance:5, scope:{madhab:'hanafi'}}]}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
shapeNoHow much of each hit to return. 'full' (default) is every field on every row, including the snippets — ask for this when the answer will QUOTE the page. 'brief' keeps book_id/page_id, printed_page, match_quality and matched_in_section and hoists book metadata into a top-level `books` dictionary keyed by book_id, but carries NO snippet: it answers which pages these are, how well each matched and how to cite them, for a fraction of the characters, so far more rows survive the budget. 'index' returns book_id/page_id only, for choosing what to read before paying to read it. Requires the 'shape.full_brief_index' capability (see shamela_brief).full
probesYesThe searches to run. They execute concurrently and their results are merged, deduped by (book_id, page_id) and attributed back to the probes that found each page.
deadline_msNoWall-clock budget for the whole batch. Probes still running when it expires are reported with status='timeout' and contribute nothing. A timeout is NOT a negative finding — it means the question was not fully asked.
response_formatNoOutput format for the human-readable text. 'markdown' (default) is best for direct display; 'json' returns the same data as a single JSON code block; 'none' skips the rendered text entirely and returns a one-line pointer, leaving `structuredContent` as the whole answer. The structured data is returned in `structuredContent` regardless of this setting, so a caller that parses it should pass 'none' — the character budget is measured over BOTH channels, and the unread copy is otherwise spending most of it. Requires the 'response_format.none' capability (see shamela_brief).markdown
max_total_passagesNoHard cap on merged rows returned. Rows are ordered by match quality then probe agreement before the cut, so the cap drops the weakest evidence rather than an arbitrary tail. `truncated` says whether it fired.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
booksNo
probesNo
by_bookNo
resultsNo
truncatedNo
incompleteNo
rows_droppedNo
edition_groupsNo
truncation_messageNo
total_unique_passagesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover safety (readOnly, idempotent, etc.), but the description adds substantial operational context: a probe failure does not discard the others, `incomplete` flags a thin result, `qualifiers` are present only on status:'ok' and a probe without them has not been checked, `scope_resolution.dropped` exposes invented ids, and deduplication is by (book_id, page_id) with `probe_ids` showing corroboration. This is exactly the kind of behavior beyond annotations that helps an agent interpret results correctly.

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 long but front-loaded: the first sentence states the purpose and scale, the second explains the merge and deduplication, and the third describes the output metadata. It is dense but each sentence carries unique, useful information. The example at the end is helpful. Slightly over-long for a description, but the length is justified by the tool's complexity and the need to prevent misreading of merged results.

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 tool's complexity (batch of up to 24 probes, nested scope objects, merged output with metadata like `match_quality`, `matched_in_section`, `probe_ids`, `work_group_id`), the description is remarkably complete. It explains execution model, scope requirements, deduplication, timeout handling, and how to interpret caveats. With an output schema present, it appropriately does not repeat field returns but instead teaches how to read them correctly in a merged context.

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?

Schema coverage is 100%, so the baseline is 3. However, the description adds meaning beyond the schema by explaining the required nature of `scope` ('unscoped, Lucene ranks by term frequency across all 8,594 books...') and the practical impact of `limit`, `max_total_passages`, and `deadline_ms` (timeout behavior). It also clarifies `mode` semantics and the concurrent execution model, which are not obvious from field names alone.

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?

Opens with a specific verb and resource: 'Run up to 12 scoped searches in ONE call and get back a single merged, deduplicated result set.' It then distinguishes itself from the sibling single-query search tools by naming the exact use case – assembling evidence for one question from several wordings at once – which is something shamela_search_pages or shamela_search_phrase cannot do.

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?

Explicitly when-to-use ('Built for assembling evidence for one question from several wordings at once') and when-not-to-use ('do not read absence as "no school said this"; for comparative questions leave madhab unset and scope by category instead'). It also warns that a timeout is not a negative finding, which is a critical selection rule.

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.

Resources