MCP_Documents

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.1
Disambiguation4/5
Each tool has a distinct primary purpose: probe identifies, outline lists structure, find locates text, extract pulls text ranges, extract_tables pulls tables, read_page gives a full single-page view, and to_markdown converts the whole document. Some overlap exists between extract, extract_tables, and read_page, but their scope and output focus are clear enough to avoid major misselection.
Naming Consistency4/5
Most tool names follow a lowercase imperative verb pattern: probe, outline, find, extract, read_page, extract_tables. The one deviation is to_markdown, which describes a target format rather than an action, but it is still readable and consistent in style.
Tool Count5/5
Seven tools is a well-scoped set for a document examination server. There are no redundant filler tools, and each tool covers a meaningful aspect of reading or extracting document content.
Completeness4/5
The set covers the main document workflow: identify, outline, search, extract text, extract tables, read a page, and convert to markdown. Minor gaps exist around scanned document OCR handling and image extraction, but the core extraction lifecycle is well covered.
Average 3.3/5 across 7 of 7 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.json to 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety characteristics with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a useful behavioral detail: the tool also reports whether ruling lines or gaps were used. However, it does not discuss limitations, handling of malformed tables, or what happens when no tables are found.
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?
The description is concise and front-loaded with the primary action: 'Extract tables as rows.' The second sentence adds a worthwhile detail without padding. It is appropriately sized, though the unusual phrasing 'Says whether ruling lines or gaps were used' could be slightly clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and sibling tools that could easily overlap, the description is too sparse. It omits parameter semantics, input expectations, and any output structure beyond 'rows,' leaving important gaps for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description provides no information about the four parameters: source, pages, password, and min_confidence. Required source and optional parameters are left completely unexplained, so the agent cannot infer their meaning or valid formats from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation: extracting tables as rows, and adds a distinct behavioral detail about reporting ruling lines or gaps. It is clear about the resource and output, though it does not explicitly contrast itself with sibling tools like 'extract' or 'to_markdown'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as 'extract', 'probe', 'outline', or 'to_markdown'. There are no explicit usage conditions, exclusions, or alternative recommendations, leaving the agent to infer selection 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?
Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds what information the probe yields (format, pages, scanned/digital, content), but does not disclose details like whether it opens remote URLs, handles encrypted files, or what failure modes exist. No contradiction with 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with the core verb front-loaded and the informative scope listed after a colon. There is no fluff, repetition, or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and undocumented parameters, the description is too sparse. It tells what the tool identifies but not how the result is structured, how to specify the source, or whether password is required for certain document types. An agent could call it correctly but would not know what to expect back or how to interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining 'source' and 'password'. It does not mention either parameter at all, leaving the agent to guess what 'source' refers to (path, URL, object ID?) and when password is needed. The parameter names are mildly self-evident but the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Identify') and resource ('a document'), and enumerates concrete aspects: format, pages, scanned/digital status, and content. It clearly conveys the tool's role as an inspection/reconnaissance tool, distinct from siblings like extract or to_markdown, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to get an overview of a document before deeper operations like extraction or reading. However, it does not explicitly state when to prefer probe over siblings such as read_page, outline, or extract, and offers no exclusions or alternative routing.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds useful behavioral context: it lists content types returned (text, tables, links) and includes the notable detail 'how each was obtained', indicating provenance reporting. It does not contradict the annotations, but it also does not disclose other traits such as page indexing 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the key action and expected output. No extraneous information; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the descriptions lists what the call returns (text, tables, links, provenance), which helps. However, it does not mention how to configure the required parameters or any prerequisite relationship with sibling tools like probe. Given the lack of parameter documentation and no usage guidance, the description is adequate for a simple read operation but leaves several gaps an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no details about the three parameters: source, page, and password. Although the names are somewhat self-explanatory, the description does not clarify what 'source' refers to (e.g., URL, file path, document ID), what format page expects, or the role of password. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Read' with the resource 'one page' and enumerates the returned content: text, tables, links, and provenance. This provides a clear sense of what the tool does. However, it does not distinguish it from sibling tools like extract_tables or to_markdown, which also deal with page content extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use read_page versus its siblings (probe, outline, find, extract, extract_ables, to_markdown). The description implies the tool is for reading a page, but does not specify alternatives or exclusion conditions. An agent would have to infer selection criteria.
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?
The annotations already cover the safety profile with readOnlyHint=true and destructiveHint=false. The description adds a meaningful behavioral detail by stating it 'refuses when over the token budget,' which is useful operational context beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core purpose front-loaded and no filler. Both sentences contribute useful information: what the tool does and a key constraint on its execution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameter documentation and no output schema, the description leaves important gaps: how pages and password affect conversion, what the markdown output contains, and how token-limit refusal is surfaced. The annotations cover safety but not these operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does 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 meaning or usage of source, pages, or password. The description's only reference to the input is the generic word 'document,' which does not compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and result: 'Convert a document to markdown.' This is specific enough to identify the tool's function, though it does not explicitly distinguish it from sibling tools like extract or read_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as extract, extract_tables, or read_page. There are no use-case conditions, exclusions, or examples of when to prefer a sibling tool.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds genuinely useful behavioral context beyond annotations: the operation is 'Bounded' and 'refuses when too big,' which is important operational knowledge for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the core purpose and then adds a critical behavioral warning, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, 0% schema coverage, and no output schema, this description is too thin. It does not explain what 'clean text' excludes, how to specify the page range, what source refers to, what happens on refusal, or what the return value looks like. The bounded/refusal note is helpful but not sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does 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 maps loosely to two parameters: 'page range' hints at pages and 'clean text' hints at clean_text. However, it does not explain source, password, or page-range formatting, leaving significant parameter semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Extract clean text for a page range.' It clearly indicates the output type ('clean text') and scope ('page range'), which helps differentiate it from siblings like extract_tables and to_markdown, though it does not explicitly name or contrast any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a page range' implies the intended use case, and 'Bounded; refuses when too big' warns about size limits. However, there is no explicit guidance about when to prefer this tool over siblings such as read_page, extract_tables, or to_markdown, so the usage context is only implied.
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?
Annotations already signal readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds meaningful behavioral context by disclosing that the tool returns only page locations, not content, which is a non-obvious trait. It stops short of describing search matching, regex, or hit-limit 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the core action is front-loaded and the output constraint follows immediately. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with annotations, the description plus schema is usable: the agent knows the output is page locations and can infer the role of each parameter from its name/default. However, it leaves gaps such as how the empty pages default behaves, how max_hits applies, and matching semantics (regex/case), and there is no output schema to clarify return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for undocumented parameters. It adds no parameter-level meaning beyond the self-evident names (query, source, pages, regex, max_hits, password). The agent must infer semantics from titles/defaults alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Locate text across a document') and immediately clarifies the tool's output as page locations rather than content. This distinguishes it from siblings like extract and read_page, which pull content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Returns page locations, not content' clause implies it should be used for locating text rather than retrieving content, but it does not explicitly name alternatives or state when to prefer this over extract/read_page. Usage guidance is only implied.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some context beyond annotations—that output includes page anchors and that the tool is a precursor to extraction—but offers no detail on return format, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Twelve words in two sentences, with zero waste. The core purpose is front-loaded in the first sentence and the usage hint in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, idempotent listing tool with only one required parameter, the description covers the essential ground: what it returns (headings, bookmarks, page anchors) and when to run it (before extract). Since no output schema exists, the return description partially compensates. The main gap is the un-documentd 'source'/'password' semantics, which is likely shared across the sibling family but still left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters, but it never explains what 'source' refers to or what 'password' unlocks. The only implicit hint is that source is a document containing headings and page anchors. The description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('headings and bookmarks with page anchors'), clearly distinguishing it from reading content (read_page), extracting tables (extract_tables), or converting format (to_markdown). The purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use before extract' provides clear workflow context by positioning this tool as the precursor to extraction. It does not name alternatives or state when-not-to-use, but the placement guidance is explicit enough for an agent to sequence correctly.
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:

[![MCP_Documents MCP server](https://glama.ai/mcp/servers/azzindani/MCP_Documents/badges/card.svg)](https://glama.ai/mcp/servers/azzindani/MCP_Documents)

Score Badge

Copy to your README.md:

[![MCP_Documents MCP server](https://glama.ai/mcp/servers/azzindani/MCP_Documents/badges/score.svg)](https://glama.ai/mcp/servers/azzindani/MCP_Documents)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/azzindani/MCP_Documents'

If you have feedback or need assistance with the MCP directory API, please join our Discord server