mcp-ebook-read
Server Quality Checklist
Latest release: v0.3.7
- Disambiguation5/5
Each tool targets a distinct resource and action, with clear separation between library-level, document-level, and component-level operations (e.g., library_explore vs. document_explore, pdf_list_figures vs. pdf_list_tables). Overlap is minimal and resolved by descriptive names and context.
Naming Consistency4/5Tools follow a consistent snake_case with domain prefixes (document_, library_, pdf_, epub_, storage_, eval_), and most use a verb_noun pattern. Minor variations like 'doctor_health_check' and 'get_outline' vs. 'read_outline_node' break perfect uniformity but remain predictable.
Tool Count2/5With 29 tools, the set exceeds the 25-tool threshold for 'too many'. While the domain is complex, many tools could be consolidated (e.g., combining pdf_list_figures/images/tables into a single listing tool with type parameter), making the surface overly large for agents.
Completeness4/5The tool set covers the full lifecycle: library scanning, document ingest, exploration, component-level reading (figures, tables, etc.), storage maintenance, and evaluation. Minor gaps exist, like no direct tool for top-level document metadata retrieval, but core workflows are well-supported.
Average 3.7/5 across 29 of 29 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'deterministic diagnostics' implying read-only, but does not explicitly confirm whether mutations occur, what side effects exist, or any required permissions. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is a dense list of items without clear structure. It front-loads the core action ('Run deterministic diagnostics') but the list could be more readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain the return value or how to interpret results. It also omits usage context and parameter explanation, making it incomplete for a diagnostic tool with one unexplained parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'root' is completely undocumented in both the schema (0% coverage) and the description. The description lists diagnostics but does not explain how the 'root' parameter influences the checks, leaving the agent without critical guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Run') and lists the exact resources it diagnoses (SQLite sidecar indexes, GROBID enrichment, etc.). It effectively distinguishes itself from sibling tools which are primarily for document operations and ingestion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply lists what it checks, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Read' implying read-only. It does not disclose any behavioral aspects such as side effects, permissions, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the main function. The list of node types is comprehensive but slightly verbose; still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately omits return values. It covers the tool's scope across document types and node types. Missing parameter explanations reduce completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter descriptions are absent (0% coverage). The description hints that node_id can be a graph node ID or short stable ID, but does not explain doc_id or confirm syntax, leaving semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a specific node by ID, listing supported document types and node types. However, it does not explicitly differentiate from sibling tools like document_explore or read_outline_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a known node, but provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the behavioral burden. It states the tool is read-only ('Read') and lists outputs, which is helpful but lacks details on auth, permissions, or side effects. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler words. Front-loaded with verb and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the output but omits parameter explanations, which are essential given the lack of schema descriptions. For a simple tool with an output schema, this is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the schema provides no descriptions for doc_id or figure_id. The description does not explain these parameters, leaving the agent without guidance on what values to supply. This is critical for successful invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Read' and resource 'extracted PDF figure', and lists return fields (local path, caption, nearby context, diagnostics). This clearly distinguishes it from sibling tools like pdf_read_image or pdf_read_table, which handle different entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., pdf_read_image for raw images, pdf_read_table for tables). No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lacks details about read-only nature, response format, ordering, or pagination. The term 'recent' is undefined, and the default limit of 20 is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and then use cases. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple and has an output schema, the description is marginally adequate but omits explanation of 'recent' and the limit parameter. It could benefit from clarifying the list contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. Schema coverage is 0%. It implies doc_id is for the document but says nothing about limit or their types/formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists recent ingest jobs for one document. It distinguishes from siblings like document_ingest and document_ingest_status by focusing on job history, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions two use cases: when the latest job_id was lost or the user asks for ingest history. It provides clear context but does not specify when not to use it or compare with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states that the tool returns data (a dashboard), but it does not indicate whether it is read-only, idempotent, or has side effects. Important context like performance implications or data freshness is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of only two sentences. The first sentence lists what is returned, and the second provides the primary use case. There is no fluff, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description adequately explains the tool's overall purpose and output, it completely neglects the parameters. With 4 optional parameters and an output schema, explanations of parameter behavior are necessary for complete understanding. The tool appears to be a simple monitoring dashboard, so the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the 4 parameters (root, limit_failed, limit_queued, limit_running). An AI agent has no guidance on how to use these parameters, which is critical for effective invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a 'compact whole-library ingest dashboard' with specific details (document counts, job counts by status, running jobs, etc.), and explicitly ties it to monitoring 'library_ingest_documents progress.' This distinguishes it from siblings like 'document_ingest_status' which likely focus on individual jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to monitor library_ingest_documents progress,' providing clear context for when this tool is appropriate. However, it does not mention when not to use it or list alternative tools, which would enhance guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so full burden on description. Only states 'Read one outline node or chapter directly' with no additional behavioral details like side effects, permissions, or error conditions. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. No fluff, but missing essential parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple read tool with output schema existing, but lacks parameter descriptions and any behavioral context (e.g., max_chunks limit). Could be improved with parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any parameters (doc_id, node_id, format, max_chunks). No value added for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool reads one outline node or chapter directly and distinguishes from sibling get_outline by specifying use after get_outline. Verb 'read' and resource 'outline node' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: 'Prefer this for chapter summaries and guided reading after get_outline.' This tells when to use and implicitly after getting the outline. Lacks explicit alternatives or exclusions but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the return value and use case, with no disclosure of side effects, authorization needs, performance implications, or data scope limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description adequately covers usage context and purpose. Missing details about output structure, but output schema likely covers that. Slight gap on parameter meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must document parameters. It mentions doc_id implicitly through context but adds no format, example, or validation beyond the type 'string'. No guidance on how to obtain the doc_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns the document outline for EPUB/PDF. The verb 'return' and resource 'outline' are specific. It implies differentiation from sibling tools like read_outline_node by suggesting it's used first for overview, but does not explicitly distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use this first for outline-first navigation, chapter selection, and node-scoped reading.' This tells when to use it, but does not mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It enumerates return types (structured rows, markdown/html, evidence image, nearby context, diagnostics) but does not disclose side effects, performance, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Core purpose is front-loaded ('Read one extracted PDF table'), followed by a clear list of outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers outputs but omits context about the dependency on pdf_list_tables for table_id. With an output schema existing, the description adds value but misses usage prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not add information about doc_id or table_id beyond their names. It fails to explain how to obtain table_id, which is critical for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'one extracted PDF table', and differentiates from siblings like pdf_list_tables by specifying it reads a single table with multiple output formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not mention prerequisites (e.g., obtaining table_id from pdf_list_tables) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'with diagnostics' without elaboration, and does not describe ordering, return format, or any side effects. The output schema may cover return values, but the description lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy: first states core functionality and optional scoping, second provides usage recommendation. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values need not be detailed. However, with 3 parameters and 0% schema coverage, the description should elaborate on all parameters. It only addresses node_id. Additionally, prerequisites (e.g., document ingestion) are not mentioned, leaving gaps for new users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only clarifies the 'node_id' parameter (scoping to an outline node). The 'limit' and 'doc_id' parameters are not explained, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Docling-detected PDF figures with diagnostics, and optionally scopes to an outline node. It differentiates from siblings like pdf_list_images by specifying 'Docling-detected' and 'diagnostics', and explicitly suggests sequencing before pdf_read_figure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use for figure-centric reading before pdf_read_figure.' This implies sequential workflow. However, it does not explicitly mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral disclosure. It correctly implies a read-only rendering operation with no mention of side effects. However, it does not explicitly state safety (read-only, no modifications) that annotations would have provided. Lacks details on potential issues like size or time, but for a simple tool it's minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. Efficient and no wasted words, though could include parameter details without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no schema descriptions, no annotations, but an output schema exists, the description is partially complete. It states the purpose and when to use but lacks parameter explanations and return format details. The output schema might cover return values, but the description itself is insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description provides no explanation of parameters ('doc_id', 'page', 'dpi'). It does not clarify page numbering (0- or 1-based), what doc_id refers to, or the effect of dpi. Description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'render', resource 'PDF page', output 'PNG evidence image'. Distinguishes from sibling tools that extract specific elements like figures, tables, etc. by stating 'beyond extracted figures, tables, images, or formulas'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'when page-level visual evidence is needed beyond extracted figures, tables, images, or formulas.' Provides clear context and implies alternatives, though does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic function (listing images) and optional scoping, without mentioning read-only nature, return format, or any side effects. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core function, and contains no unnecessary words. It is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description gives the essential purpose and workflow hint, it lacks details such as output format, what qualifies as an image, or any limitations. The presence of an output schema partly mitigates this, but the description could be more informative for a tool with 3 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters. The description only hints at node_id for scoping but does not clarify doc_id or limit. With 3 params and 1 required, more explicit parameter guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists extracted images from an EPUB, with optional scoping by outline node. It distinguishes from siblings like epub_read_image and pdf_list_images by specifying the file type and workflow context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool before epub_read_image in multimodal workflows, giving a clear usage context. However, it does not mention when not to use it or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: operates on already-ingested sidecars, uses local SQLite FTS and DocumentGraph ranking, and does not auto-ingest PDFs. Missing details like performance implications or required permissions, but still adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each adding distinct information. It front-loades the purpose and usage. Could potentially include parameter info without being verbose, but as is, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that output schema exists, return value documentation is not required. However, with three parameters and 0% schema coverage, the description fails to cover parameter semantics adequately. The tool is relatively simple, but missing parameter details reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). The description partly explains 'root' (default behavior) but does not describe 'query' or 'top_k' at all. This leaves the agent without guidance on parameter usage, a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: exploring an already-ingested root sidecar using SQLite FTS and DocumentGraph ranking to find relevant content in books/papers. It distinguishes from sibling tools like document_explore and library_ingest_documents by focusing on querying ingested content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('when the user asks which book/paper contains relevant content') and explains default behavior for root. It also notes that it does not auto-ingest heavy PDFs, providing context for what not to expect. However, it does not compare to alternatives or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it infers book/paper mode from doc_id metadata, which is a behavioral trait. However, without annotations, it does not explicitly state that the tool is read-only or mention any permissions, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences without superfluous words. The first sentence covers purpose and output, the second adds behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two required parameters and an output schema exists, the description is somewhat complete. However, it lacks information on how to obtain formula_id (e.g., from pdf_list_formulas) and does not cover error cases or mode inference specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the parameters. It mentions doc_id and formula_id but does not describe their meaning, format, or how to obtain them. This adds minimal value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads one formula from an ingested PDF and specifies the output components (LaTeX, status, context, evidence image). It distinguishes itself from sibling tool 'pdf_list_formulas' which lists formulas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading a specific formula, but does not explicitly state when to use this tool versus pdf_list_formulas or other read tools. No guidance on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states 'Search within one outline node' without disclosing output format, pagination, or any side effects. This is insufficient for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with front-loaded key information. No wasted words; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (mentioned but not provided) and 4 parameters, the description is minimal. It provides usage context but lacks details on behavior, parameter descriptions, and return structure, leaving gaps for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (query, top_k, doc_id, node_id). It adds no meaning beyond the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'search' and the resource 'one outline node or chapter'. It distinguishes itself from sibling tools like 'get_outline' by specifying focused reading after identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this for focused reading questions after get_outline identifies the relevant section, providing clear usage context. No explicit when-not-to-use or alternatives, but the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the return value (local path plus context), implying a read operation without side effects. However, it does not explicitly confirm that it is read-only, does not mention potential authentication requirements, or handle errors like missing images.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the action and return value, the second provides usage guidance. It is front-loaded with the core purpose and has no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, simple read operation) and presence of an output schema (though not shown), the description adequately covers the tool's purpose and return value. It does not need to detail output structure since the schema is provided. However, it could be slightly more exhaustive about usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meanings. It does not elaborate on what 'doc_id' or 'image_id' represent (e.g., document identifier, image index/ID), leaving the agent to infer from names alone. This is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an EPUB image local path and nearby text context. The verb 'Return' and resource 'EPUB image local path plus nearby text context' are specific. This distinguishes it from sibling tools like epub_list_images (which lists images) and pdf_read_image (for PDFs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when a multimodal LLM needs to inspect a figure, diagram, or illustration,' providing clear context for appropriate use. However, it does not explicitly exclude alternative uses or mention when not to use it, such as when only the image path is needed without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions that the tool infers book/paper mode from doc_id metadata, which is helpful. But it does not disclose other important traits like read-only nature, error handling, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long and front-loaded with the core purpose. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and no annotations, the description only covers the basic purpose and one parameter. It lacks details on other parameters, behavioral context, and return value expectations (output schema exists but not described).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only explains the node_id parameter (scoping). It does not describe limit, doc_id, or status parameters, leaving their meaning unclear. This is insufficient for a tool with 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'formulas from an ingested PDF', with an optional scoping to outline node. It distinguishes from siblings like pdf_list_figures and pdf_read_formula by specifying list vs read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs not to use a separate book/paper formula tool, implying that this tool handles both modes. However, it doesn't specify when not to use this tool (e.g., for reading a single formula) or provide alternatives beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Implies read-only operation but does not disclose requirements (e.g., document must be processed), or behavior like pagination. Adequate for a standard list tool but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. First sentence front-loads purpose, second provides sibling distinction. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 params, no annotations, and existing output schema, the description covers basic purpose and sibling differentiation but lacks parameter details and behavioral context. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description only hints at node_id ('optionally scoped to an outline node'). No explanation for doc_id or limit parameters. Minimal added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'List' and resource 'extracted PDF images', with optional scoping to an outline node. Explicitly distinguishes from siblings pdf_list_figures and pdf_list_tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct guidance on when to use this tool ('general PDF visual evidence') and when to use alternatives (figures/tables tools). However, lacks prerequisites like document ingestion status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It states the output (local path + context) but does not disclose whether the tool is read-only, requires specific permissions, or has any side effects. The name implies a read operation, but added clarity would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the action and output, and adds a usage tip. There is no redundant information, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context (2 required params, 0% schema coverage, output schema exists), the description is adequate but not complete. It covers the primary purpose and usage scenario but lacks parameter explanation and does not reference sibling tools for context, such as where to find image_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (doc_id, image_id) with 0% description coverage. The description does not explain these parameters beyond the tool name's implication. It could clarify that image_id is obtained from pdf_list_images, but it does not, leaving the agent without guidance on valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'one extracted PDF image local path plus nearby text context,' which is specific and distinct from sibling tools like pdf_list_images (which lists image IDs) and pdf_read_figure (for figures). The verb 'return' and resource 'extracted PDF image' are precisely defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use-case: 'Use when a multimodal LLM needs to inspect PDF visual evidence.' This tells the agent when to invoke the tool, though it does not explicitly state when not to use it or mention alternatives like pdf_read_figure or pdf_read_table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the main actions (pruning missing docs, orphan artifacts, compacting SQLite) but lacks depth on behavioral traits like destructiveness, reversibility, or required permissions. With no annotations, this is adequate but could be more informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the purpose and actions, the second clarifies the root parameter. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While all parameters are covered, the description does not mention the output schema or return value. For a cleanup tool, the agent might need to know if it returns success/failure or a report. Also, safety and idempotency are not addressed. The presence of an output schema but lack of description leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are explained in the description: 'root' is clarified with fallback, 'compact_catalog' is described as 'optionally compacting SQLite', and the two boolean flags are directly tied to 'pruning missing documents' and 'orphan artifacts'. This adds value over the schema which has zero descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('clean the root sidecar catalog') and specifies what it does (prune missing documents, orphan artifacts, compact SQLite). It distinguishes from siblings like 'storage_list_sidecars' or 'storage_delete_document' by referring to a general cleanup operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention scenarios, prerequisites, or when to avoid using it. It only defines the action and the root fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It mentions deletion and state removal but does not clarify permanence, side effects, or the role of the 'remove_artifacts' parameter. The description gives only minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the action and resource, second provides usage condition. Every sentence is necessary and efficient. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and an output schema, the description is minimal. It covers the primary action and usage condition but omits prerequisites (e.g., does the document need to exist?) and the meaning of 'sidecar persistence'. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description mentions 'remove persisted MCP state for a specific document' but does not explain the purpose of any parameter (path, doc_id, remove_artifacts) or how to use them. The description adds almost no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'delete' and the resource 'one document from local sidecar persistence'. It distinguishes from sibling tools like storage_cleanup_sidecars by focusing on a single document removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use only when the user asks to remove persisted MCP state for a specific document.' It provides clear context but does not mention alternatives or when-not-to-use scenarios beyond the implied exclusivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the main behavioral traits: recursive scanning, sidecar catalog registration, and return performance metrics. However, it does not mention whether the operation is destructive, if it can be safely rerun, or any permissions needed. This is adequate for a non-destructive scan tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence delivers the core purpose and mechanism; the second adds usage guidance and return value info. Every sentence earns its place. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description appropriately references return fields (candidate counts, hash workers, scan timing). The tool has two optional parameters; one is well-explained. The sibling tools set context. It covers the essential aspects for an agent to decide to invoke it, though a tiny bit more on patterns would make it perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the 'root' parameter ('If root is omitted, the MCP process project root is used') but says nothing about the 'patterns' parameter. Users need to guess its purpose (likely file patterns). This is a significant gap, as one of two parameters is completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Scan a local root recursively for EPUB/PDF documents'), the target resource ('local root'), and the outcome ('register them in one root sidecar catalog'). It uniquely describes what the tool does and distinguishes it from sibling tools like library_explore or library_ingest_documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use this before doc_id-only tools after a fresh server restart.' It tells when to use it, though it does not explicitly state when not to use it or mention alternatives. The context of sibling tools helps, but a bit more guidance on idempotency or avoiding unnecessary scans would elevate it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses listing tables with diagnostics and scoping, but does not detail what diagnostics entail or confirm absence of side effects. Minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage hint. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters and an output schema, the description covers the main action and usage context. Lacks detail on return value content, but output schema likely compensates. Good but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description mentions 'optionally scoped to an outline node' (node_id), but does not explain doc_id or limit. Significant gaps in parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists Docling-extracted PDF tables with diagnostics, optionally scoped to an outline node. It distinguishes itself from siblings like pdf_read_table and other pdf_list_* tools by focusing on tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for table-centric reading before pdf_read_table,' providing a clear workflow sequence. Does not specify when not to use, but the positive guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions exporting events and omitting file paths, but does not disclose side effects, state changes, or performance implications. Minimal behavioral context beyond basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Front-loaded with the core action and parameter. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple export tool with output schema present, description covers main purpose and root behavior. Could mention limit or output format, but output schema handles return. Mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'root' parameter's default and behavior, adding value beyond the schema (which has 0% coverage). However, the 'limit' parameter is not mentioned, leaving its purpose unclear. Adds some meaning but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Export' and resource 'opt-in reading-session capture events' and distinguishes from sibling like eval_replay_reading_sessions by mentioning 'export' vs 'replay'. It also clarifies scope with 'selected root sidecar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use: 'to inspect real MCP reading calls and retrieval evidence without exposing file paths'. Provides context on default root behavior. Lacks explicit exclusions or alternatives but is sufficient for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds context: the constraint about query text and root default. But it doesn't mention side effects, idempotency, or performance implications for a replay operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: first gives purpose and root behavior, second adds a key constraint. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema (so return values need no explanation) and only two parameters, the description covers the tool's core functionality well, though 'limit' remains unexplained, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'root' parameter's default behavior ('If root is omitted, the MCP process project root is used'), but does not address the 'limit' parameter which remains undocumented, leaving a gap despite low schema coverage (0%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool's action ('Replay captured search reading-session events') and its purpose ('to detect retrieval drift'), clearly distinguishing it from sibling tools like eval_export_reading_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: omitted root defaults to project root, and a constraint on replayability (only events with query text enabled). However, no explicit guidance on when to use this tool over alternatives like eval_export_reading_sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies read-only behavior by stating 'inspect local persistence,' but does not detail error handling, sidecar format, or the effect of the limit parameter. Adds some context but lacks thorough behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the main action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, output schema exists), the description covers the main purpose and default behavior. It lacks explanation of the limit parameter, but output schema may compensate for return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the root parameter and its default behavior ('If root is omitted, the MCP process project root is used'), but does not mention the limit parameter or its semantics, leaving it undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List the .mcp-ebook-read sidecar') and clearly distinguishes from sibling tools like storage_cleanup_sidecars and storage_delete_document, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'rediscover known documents after restart and inspect local persistence.' It also explains the default behavior for the root parameter, though it does not explicitly mention when not to use this tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes background async behavior, file persistence details (pypdfium2, PyMuPDF, Docling), and sidecar location. No annotation contradictions. Less transparent about error behavior and resource side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with front-loaded purpose and parameter details. Dense but not verbose. Could be slightly more structured (e.g., bullet points), but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose, parameters, and output via output schema. Lacks prerequisites (e.g., file existence), error handling, and relationship with status tools. Adequate given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains path, root, doc_id, profile, and library_scan behavior. Misses force parameter, and library_scan is described but not in schema. Partial compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Queue high-fidelity background ingest' and the resource 'one EPUB/PDF document'. It distinguishes from siblings like library_ingest_documents by specifying single document ingestion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use doc_id vs path, root, and profile options (auto, book, paper). Includes recommendation for library_scan for automatic profile detection. Does not directly compare to list/status siblings but context implies single ingest use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it's a read operation but lacks details on error behavior, typical status values, or polling considerations, which are important for a status-checking tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and usage, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not detail return values. It covers basic usage and context, but could briefly mention that it is non-destructive or specify typical status values for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (doc_id, job_id). Without this, agents may struggle to know how to obtain or use these IDs, especially doc_id from a prior document_ingest call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read current status') and resource ('background ingest job'), and distinguishes from siblings like document_ingest_list_jobs by focusing on a specific job's status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use after a document_ingest call and until status is succeeded or failed, providing clear context for when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description fully details the return values including FTS hits, nodes, evidence, diagnostics, truncation notices, ambiguity candidates, and suggested next calls. Also notes auto-inference of document type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense paragraph that conveys all key information. Could be slightly more structured but is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (though not shown) and the tool's 3 parameters, the description covers all essential aspects without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description clarifies doc_id and query but does not explain top_k. Output schema exists but is not shown. Partial compensation, but top_k remains vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies the tool explores one ingested book or paper by doc_id, asks a natural-language question, and returns detailed results. Distinguishes from sibling tools like document_ingest and document_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is for asking reading questions about a specific document. Does not list exclusions or alternatives, but the context of siblings provides sufficient differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses the non-destructive but write-oriented behavior (queue ingest), conditions for processing, deduplication, and the meaning of max_documents=0. However, it does not mention authentication, rate limits, or potential side effects like locking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first delivers the core action and condition, second provides usage guidance and return value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Cover essential points: action, condition, usage, return values (counts). Output schema exists but description adds value beyond it. Could mention default behavior for null root or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains root as the selected directory and max_documents cap behavior. The force parameter is not explained, leaving part of the parameter semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scans a root and queues background ingest for EPUB/PDF documents that are not READY or have stale metadata. It distinguishes from sibling tool document_ingest by noting it's for whole-library operations instead of parallel individual calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this for whole-library initialization or refresh instead of calling document_ingest many times in parallel,' providing clear when-to-use and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ArtiPyHeart/mcp-ebook-read'
If you have feedback or need assistance with the MCP directory API, please join our Discord server