Skip to main content
Glama
This connector has been deprecated

Books by period (composition and death year)

shamela_books_by_period
Read-onlyIdempotent

كتب حسب المدة (تأليفًا ووفاةً)

Catalog filter that AND-combines its constraints, unlike scope.period_*, which unions them and so widens a search instead of narrowing it. composed_from/composed_to bound book.book_date (Shamela's «تاريخ الكتاب»); died_from/died_to bound the MAIN AUTHOR's death year. Read those as two COLUMNS, not two independent dimensions: measured on this catalogue they carry the same number on 98.5% of dated books, because Shamela records no composition year. A composed-vs-died question — «books written in the 8th century by authors who died in the 9th» — is therefore one this data cannot answer, and a near-empty result means the distinction is unavailable, not that no such book exists. A book matches only if it satisfies ALL provided constraints at once (composition-year AND death-year AND category AND downloaded) — an intersection, never a union. At least one of the four bounds is required. Also accepts category_id, downloaded_only, limit/offset. Returns book_id, book_name, main author + death_year, book_date, category, downloaded flag, and a ready-to-use book_ids[] to pass as scope.book_ids. Use when a question distinguishes 'books composed in a period' from 'books by authors who died in a period' — e.g. died_from:700, died_to:800 for 8th-century-Hijri authors.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return (1-100, default 20).
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.
died_toNoHijri year, inclusive UPPER bound on the MAIN AUTHOR's death year (author.death_number). Pair with died_from.
died_fromNoHijri year, inclusive LOWER bound on the MAIN AUTHOR's death year (author.death_number). A different column from composed_*, but the same number on 98.5% of dated books. Pair with died_to.
category_idNoOptional: restrict to one category (use shamela_list_categories for IDs). Categories are flat in master.db.
composed_toNoHijri year, inclusive UPPER bound on book.book_date («تاريخ الكتاب»; see composed_from — it is not a composition year). Pair with composed_from.
composed_fromNoHijri year, inclusive LOWER bound on book.book_date — Shamela's «تاريخ الكتاب». NOT an independent composition year: it holds the main author's death year on 98.5% of dated books (8,461/8,587), so pairing it with died_* almost never narrows anything. Pair with composed_to.
downloaded_onlyNoIf true, restrict to books actually downloaded on this machine (master.db.book.major_ondisk > 0) — the only ones with searchable page content.
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.8/5.0
Behavior5/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 description spends its budget on non-obvious behavior: constraints AND-combine (intersection, never union), at least one of the four bounds is required, and the near-empty-result interpretation. It also discloses the hand-off artifact (`book_ids[]` to pass as `scope.book_ids`), which no annotation could convey.

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 highest-value distinction (AND vs. union, and the composed/died column caveat) before the mechanics and return fields. It is dense but each paragraph carries a distinct load; the main cost is the duplicated Arabic header line and the 98.5% statistic restated from the 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?

No output schema exists, and the description compensates by enumerating the returned fields (book_id, book_name, main author + death_year, book_date, category, downloaded flag) and the `book_ids[]` payload for chaining into `scope.book_ids`. With the filter semantics, requirement rule, and return shape all covered, an agent has everything needed to call it correctly.

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 per-parameter docs already exist (including the 98.5% overlap note, which the description partly repeats). What the description adds beyond the schema is the cross-parameter rule that at least one of the four bounds must be supplied and the pairing guidance between `composed_*` and `died_*` — real value, but a substantial fraction of the text is duplicative of the schema.

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 resource (books) and an explicit filter axis (Hijri period bounds on composition/`book_date` and on the main author's death year), and names the sibling family it must not be confused with (`scope.period_*`). An agent can tell it apart from `shamela_search_books` or a period scope without opening any 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?

Explicitly says when to use it ('when a question distinguishes books composed in a period from books by authors who died in a period') with a concrete example (`died_from:700, died_to:800`). It also says when the tool is the wrong instrument — a composed-vs-died question — and warns that a near-empty result means the distinction is unavailable rather than that no book exists.

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