Skip to main content
Glama
This connector has been deprecated

Identify a cited work

shamela_resolve_work
Read-onlyIdempotent

تحديد الكتاب المُحال إليه

Resolve a CITED work — title, optional author, optional edition — to the catalogue entry it names, or refuse. Use this instead of shamela_resolve whenever a citation is being verified: shamela_resolve RANKS, and a ranking always produces a winner, so an ambiguous request comes back as a confident wrong answer. Three guarantees. (1) The requested title must be a PREFIX of the candidate's title: «شرح صحيح البخاري», «المدخل إلى صحيح البخاري» and «عمدة القاري شرح صحيح البخاري» all contain the work's name and none of them IS the work — a commentary is another author writing about it, and quoting one as the work attributes his words to al-Bukhari. (2) author is a FILTER, not a hint: a candidate whose author cannot be reconciled with it is rejected and listed in rejected[], never ranked down. (3) A requested edition that no entry carries returns status='not_found' with reason='edition_not_found' plus available_editions[] — never a different book. status is 'exact' (one entry, in match), 'ambiguous' (several — ambiguity:'edition' means one work in several printings, so pass every book_id as one scope; ambiguity:'work' means DIFFERENT books, and nothing may choose between them: «المغني» is al-Dhahabi's book of weak narrators and Ibn Qudama's fiqh), or 'not_found'. Catalogue-only, no index, no library read. Examples: shamela_resolve_work({title:'صحيح البخاري - ط السلطانية'}), shamela_resolve_work({title:'المغني', author:'ابن قدامة'}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum candidates to report (1-50, default 20).
titleYesThe work's title as cited, e.g. «صحيح البخاري», «المغني», «فتح الباري». Leading words only — the title, not a description of it. You may include the catalogue's own edition tail, with the « - » («صحيح البخاري - ط السلطانية») or without it («مسند أحمد ط الرسالة»), and it will be read as `edition`. An author name appended instead («صحيح البخاري محمد بن إسماعيل البخاري», «الهداية للمرغيناني») is read as `author`. Where a title is held by more than one author, a trailing edition is NOT read as one until you also pass `author` — «صحيح البخاري ت البغا» alone is refused, «صحيح البخاري ت البغا» + author «البخاري» resolves.
authorNoThe author as cited, when known. This is a FILTER, not a hint: a candidate whose author cannot be reconciled with it is rejected rather than ranked down, because that is exactly how a commentary gets returned as the work it comments on.
editionNoA specific printing, as the catalogue names it: 'ط السلطانية', 'ت البغا', 'ط التأصيل'. If no entry carries it you get status='not_found' with reason='edition_not_found' and the editions that DO exist — never a different book.
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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/closed-world, and the description adds genuinely non-obvious behavior on top: three prefix/author/edition guarantees, the refusal contract, the `rejected[]` vs ranked-down distinction, the ambiguity:'edition' vs ambiguity:'work' split, and the explicit 'catalogue-only, no index, no library read' scope limit.

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 key contrast against `shamela_resolve`, then the three numbered guarantees, then status semantics, then examples — a sensible order. It is long and repeats some schema content, but for a tool with three subtle matching rules and no output schema, most sentences carry weight.

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 no output schema, the description carries the full burden of describing returns — status values ('exact'/'ambiguous'/'not_found'), the reason code, `match`, `rejected[]`, and `available_editions[]` are all explained. Combined with the refusal contract and scope limits, an agent has everything needed to call and interpret it.

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

Parameters3/5

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

Schema coverage is 100% and each parameter already carries a rich description (title's edition-tail/author-append rules, author-as-FILTER, edition miss behavior, response_format capability). The description largely restates this, adding the concrete example calls but no syntax or constraints the schema lacks — baseline 3 is appropriate.

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 — resolving a CITED work (title + optional author/edition) to a catalogue entry — and explicitly distinguishes itself from sibling `shamela_resolve`, noting that the other RANKS while this one refuses ambiguity. An agent can pick between the two siblings without opening either schema.

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?

Gives an explicit when-to-use rule ('Use this instead of `shamela_resolve` whenever a citation is being verified') plus the reason (ranking always produces a confident winner, so ambiguity yields a wrong answer). When-not semantics are implicit in the refusal behavior but the routing condition is unambiguous.

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