Skip to main content
Glama
This connector has been deprecated

Exact phrase and proximity search

shamela_search_phrase
Read-onlyIdempotent

بحث بالعبارة والتقارب

Exact-phrase and proximity search the regular search lacks. mode='phrase' matches the query words as a CONSECUTIVE phrase (e.g. «خيار المجلس» only where those two words are adjacent). mode='near' matches pages where the words occur within distance words of each other in any order (e.g. «بيع» near «قبض» within 5 words) — ideal for fiqh questions where related terms sit close but not adjacent. Two-stage: finds candidate pages where all words co-occur, then verifies adjacency/proximity in the full page text. Pass scope (book_ids/author_ids/category_ids) to cover large libraries reliably. Returns book name, author, printed page, and a snippet. Examples: shamela_search_phrase({query:'خيار المجلس'}), shamela_search_phrase({query:'بيع قبض', mode:'near', distance:5, scope:{category_ids:[17]}}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'phrase' = exact consecutive words (default). 'near' = words within `distance` words, any order.phrase
limitNoMaximum number of results to return (1-100, default 20).
queryYesArabic phrase. In mode='phrase' the words must appear consecutively (exact phrase). In mode='near' the words must appear within `distance` words of each other in any order.
scopeNoRestrict to books/authors/categories/period. Strongly recommended to scope large libraries.
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
offsetNoNumber of results to skip for pagination. Use with `limit` to page through large result sets. The response includes `has_more` and `next_offset` to drive paging.
distanceNoFor mode='near': maximum word span from the FIRST to the LAST query word, counted inclusively — distance=1 means adjacent, distance=2 allows one word between two query words. Ignored for mode='phrase'.
search_inNoWhich page sections to verify the phrase in: body (matn), foot (footnotes), comment.
exclude_pagesNoExact pages to keep out — the pages a previous round already returned. Excluding these rather than whole books is what lets a follow-up search find MORE evidence in a book that has already contributed some.
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
exclude_book_idsNoBook ids to keep out of the results entirely.
exclude_author_idsNoExclude every book by these authors.
exclude_category_idsNoExclude every book on these shelves.
exclude_work_group_idsNoExclude every catalogue entry of these works — all printings at once. This is the one to use after a round returned «صحيح البخاري - ط السلطانية»: excluding that book_id alone leaves the other seven entries of group 1681 free to return the same text again as if it were a second source.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
booksNo
queryNo
offsetNo
resultsNo
distanceNo
has_moreNo
returnedNo
truncatedNo
next_offsetNo
scope_countNo
rows_droppedNo
total_verifiedNo
zero_hit_termsNo
scope_resolutionNo
candidate_cap_hitNo
truncation_messageNo
unattributable_booksNo
total_candidates_scannedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral context: the two-stage execution (find co-occurring candidate pages, then verify adjacency/proximity in full page text) and the reliability implication of using `scope` on large libraries. It does not discuss rate limits or cost beyond the 'regular search lacks' framing.

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?

Front-loaded with the core distinction, then mode semantics, then the two-stage mechanism, then scoping advice, then return fields and examples — a logical order for a 14-parameter tool. It is appropriately sized, though the bilingual Arabic header duplicates the English title and the return-fields sentence overlaps with the output schema.

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?

With 14 parameters, a 100%-covered schema, an output schema, and full annotations, the description only needs to supply the conceptual layer — mode choice, execution model, scoping advice — and it does exactly that with worked examples. Nothing an agent needs to call it correctly is missing.

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 description coverage is 100%, so baseline is 3, but the description goes further by showing a full invocation example with `query`, `mode`, `distance`, and nested `scope:{category_ids:[17]}`, which clarifies how the parameters compose. It does not add semantics for the many exclusion/shape/pagination params, all of which the schema handles.

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 states a precise verb+resource ('exact-phrase and proximity search') and immediately defines the two modes with concrete Arabic examples («خيار المجلس» for phrase, «بيع» near «قبض» within 5 words). It also distinguishes itself from 'the regular search' by naming what that search lacks, so an agent can tell what this tool adds without opening the schema.

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?

It clearly states when to pick phrase vs near ('ideal for fiqh questions where related terms sit close but not adjacent') and recommends scoping for large libraries. However it never names the closest siblings (shamela_search_exact, shamela_search_boolean) or states when NOT to use this tool, so the routing guidance is strong but not exhaustive.

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