Skip to main content
Glama
This connector has been deprecated

Read a page

shamela_get_page
Read-onlyIdempotent

جلب صفحة

Fetch the full text of one Shamela page (book_id, page_id). Returns body (matn), foot (footnotes), comment (user notes), printed_page label, prev/next page ids, the chapter ancestor chain (root → leaf), and the category path. Set keep_html=true to preserve inline markers; default strips them. The book must be downloaded (BOOK_NOT_DOWNLOADED otherwise). For batch reads use shamela_get_pages_range; for full chapters use shamela_get_book_section. Long pages: the body is split into parts of ~4000 chars — body_part selects the 1-based part, and body_total_parts/body_has_more report the split (footnote/comment come with part 1; a _display hint advises when to ask the user how to show it).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
book_idYesThe book id.
page_idYesThe page id (Lucene/SQLite internal id, not the printed page number).
body_partNoFor long pages: when the body exceeds ~4000 characters it is split into parts. Pass the 1-based part to read (default 1). The response reports body_part/body_total_parts/body_has_more; request the next part by incrementing. The footnote/comment are returned with part 1.
keep_htmlNoIf true, preserve inline HTML markers (e.g. <span data-type='title'>). Default false strips them for plain Arabic display.
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/non-destructive, and the description adds substantial traits beyond that: the BOOK_NOT_DOWNLOADED failure condition, the ~4000-char body splitting with body_part/body_total_parts/body_has_more, footnotes/comment arriving with part 1, and the keep_html stripping behavior. This is rich, non-redundant behavioral context.

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?

Dense and front-loaded, with the core action stated first and routing/edge cases following. The leading Arabic 'جلب صفحة' duplicates the title rather than adding information, a minor bit of waste in an otherwise efficient paragraph.

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 the return payload (body, foot, comment, printed_page, prev/next, chapter ancestor chain, category path) plus error and splitting behavior. Nothing essential for correct invocation is missing.

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 description coverage is 100%, so baseline is 3. The description restates keep_html marker handling and body_part splitting that the schema already documents in full, adding only marginal meaning beyond the structured fields.

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?

Specific verb+resource: 'Fetch the full text of one Shamela page (book_id, page_id)'. It also names the exact operation's scope and differentiates from siblings by naming shamela_get_pages_range (batch) and shamela_get_book_section (chapters).

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?

Explicit routing: 'For batch reads use shamela_get_pages_range; for full chapters use shamela_get_book_section', plus the prerequisite that the book must be downloaded. An agent knows exactly when to pick this tool versus its alternatives.

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