The server is a local, offline MCP read/extraction layer for documents (PDF first, but also HTML, DOCX, XLSX, PPTX, EML, EPUB, XBRL, markdown, plain text), designed to make large documents addressable without flooding context.
Probe: identify format, pages, scanned/digital status, and contents.
Outline: list headings/bookmarks with page anchors before extracting.
Find: locate text or regex matches, returning page locations/counts rather than content.
Extract: pull clean text for a requested page range, refusing when too large.
Extract tables: get table rows with confidence reflecting whether ruling lines or column gaps were used.
Read page: see one page's text, tables, links, and provenance.
To markdown: convert documents to Markdown within the token budget.
Supports passwords, page ranges, zip bundles (e.g. filing.zip::instance.xbrl), and optional URL fetching.
The broader project also includes edit tools (assemble, convert, optimize, ocr, protect, redact), though the provided schema covers the read tier.
Supports Markdown documents as a first-class format, allowing the server's reading, extraction, and manipulation tools to operate on Markdown files, and enabling conversion between Markdown and other document formats.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP_Documents Probe ~/Downloads/invoice.pdf and tell me if it's scanned."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A self-hosted MCP server for reading, extracting from and manipulating documents — PDF first, but not PDF only.
The seventh repo in the MCP_* fleet, and the one that closes the research
leg of the research → analytics → reporting path the fleet exists to serve.
Release
v0.1.0— the first tagged release. All 13 tools are implemented and deployed; CI is green on Ubuntu, macOS and Windows. Source only: no wheel and no container image are published, so build the image yourself from theDockerfilehere. The documents indocs/remain the contract the implementation satisfies, andCLAUDE.mdis the rulebook for anyone changing it.
The commercial PDF sites are upload-first. The documents people actually run through them are contracts, invoices, payslips, medical and legal records.
This does the same work and nothing leaves the machine. No GPU, no cloud API, no model weights, no subscription — and it works offline.
Related MCP server: document-intelligence-mcp
Extraction from documents too large to read. A 500-page PDF is roughly 250,000 tokens; the agent driving it has about 10,000. So the server does not return documents, it makes them addressable:
probe what is this — pages, scanned or digital, where the structure is
find WHERE something is — locations and counts, never the content
extract one region you chose, cleaned, with a note on how it was obtainedThat path is what lets an agent answer a question about a 500-page bundle inside
a small context. With a regex and named groups, find over 300 pages returns
rows rather than prose — which is what the sibling data server loads.
Manipulation, the operations a PDF site offers, done locally: assemble (merge / split / reorder / rotate in one grammar), convert, compress, repair, OCR, protect, redact.
Any document, not just PDF. One reader per format normalising into a single
internal model, so every tool works the same on PDF, HTML, .docx, .xlsx,
.pptx, .eml, .epub, .xbrl, markdown and plain text. With URL fetching
enabled, every path argument also accepts a link — the same call, whether the
HTML came from disk or the web.
Bundles open too. A .zip reads as its manifest, and a member is read by
naming it — probe("filing.zip::instance.xbrl") — so a filing that arrives as
an archive does not have to be unpacked by hand first.
XBRL figures come back native. Every other format's numbers are recovered
from layout and carry a confidence to match; an XBRL instance states its facts
in machine-readable fields, and the response says so. Values are reported
exactly as filed and never rescaled.
docs-read probe · outline · find · extract · extract_tables · read_page · to_markdown
docs-edit assemble · convert · optimize · ocr · protect · redactThirteen, not the twenty-five a PDF website shows, because that number is a
property of user interfaces — a button cannot take an argument and an agent's
verb can. assemble alone covers merge, split, extract pages, remove pages,
organise and rotate.
File | What is in it |
| The rules. Read this first if you are an agent working here. |
| The three-step path, the intermediate representation, provenance, budgets |
| Every tool's signature, response shape and refusals |
| Libraries, licences, external binaries, the container budget |
| What was rejected and why — read before proposing a change |
Reconstruction announces itself. A PDF is glyphs at coordinates — paragraphs,
tables, reading order and headings are all inferred. Every extraction carries a
basis field saying how it was obtained: a table found from ruling lines and one
guessed from column gaps do not get the same confidence, and a page that is an
un-OCR'd scan says so instead of returning nothing.
PDF → Word/PowerPoint is reconstruction, not conversion. The commercial sites use commercial engines and there is no CPU-only open-source path to that quality. This ships it, labels it, and tells you when a document is a poor candidate.
Requires Python 3.14 and uv. Set MCP_CONSTRAINED_MODE=1 on small
hardware to tighten every budget.
uv sync
uv run python servers/docs_read/server.py # 7 read tools
uv run python servers/docs_edit/server.py # 6 edit toolsTwo entries in your client's mcp.json, one per tier. Everything runs on the
CPU with no network; convert(to='pdf') needs LibreOffice and ocr() needs
Tesseract, and both say so by name when they are missing rather than failing
inside a subprocess.
One container, both tiers on one port, so the PDF stack loads once:
cp tokens.example.json tokens.json # or use DOCS_API_KEY
mkdir -p oauth-state shared-files && sudo chown -R 999:999 oauth-state shared-files tokens.json
docker compose up -d --build
curl http://localhost:8850/health # aggregate
curl http://localhost:8850/read/health # per tierThe image carries LibreOffice and Tesseract. It does not carry Ghostscript
— that is a licence decision, not an omission, and optimize() reports the
capability it therefore lacks (see docs/DECISIONS.md §11). Build with
--build-arg INSTALL_GHOSTSCRIPT=1 if you accept AGPL for your own deployment.
Mounts are /read/mcp and /edit/mcp. Auth is bearer-token, by precedence:
DOCS_TOKENS_FILE > DOCS_TOKENS > DOCS_API_KEY > open. Open mode is for
localhost only — a reachable deployment with no token set has no auth at all.
Set DOCS_PUBLIC_URL to the public origin, or OAuth discovery falls back to the
internal bind address and no remote client can complete it.
To give a caller a link rather than a path inside the container, point
MCP_SHARED_DIR at a directory your file server serves and set
MCP_PUBLIC_BASE_URL to its URL; every produced file then comes back with a
public_url. MCP_FETCH_URLS=1 additionally lets any source argument be an
http(s) link — off by default, and private, loopback and cloud-metadata
addresses are refused even when it is on.
uv run python -m pytest tests/ -q # 408 offline tests
DOMAIN=http://localhost:8850 ./remote_smoke_test.sh # all 13 tools over HTTPThe smoke test is the only thing that exercises LibreOffice and Tesseract, and
it is worth more than its size suggests: it found six defects the whole offline
suite did not, because it is the only check that hands these tools a document
real software produced. DOMAIN has no default on purpose — no hostname
appears anywhere in this repo.
Extract clean text for a page range. Bounded; refuses when too big.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | ||
| source | Yes | ||
| password | No | ||
| clean_text | No |
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.
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.
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.
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.
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.
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.
Extract tables as rows. Says whether ruling lines or gaps were used.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | ||
| source | Yes | ||
| password | No | ||
| min_confidence | No |
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.
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.
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.
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.
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.
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.
Locate text across a document. Returns page locations, not content.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | ||
| query | Yes | ||
| regex | No | ||
| source | Yes | ||
| max_hits | No | ||
| password | No |
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.
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.
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.
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.
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.
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.
List headings and bookmarks with page anchors. Use before extract.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| password | No |
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.
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.
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.
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.
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.
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.
Identify a document: format, pages, scanned or digital, what it holds.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| password | No |
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.
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.
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.
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.
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.
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.
Read one page: text, tables, links, and how each was obtained.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| source | Yes | ||
| password | No |
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.
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.
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.
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.
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.
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.
Convert a document to markdown. Refuses when over the token budget.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | ||
| source | Yes | ||
| password | No |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.0.1extractextract_tablesfindoutlineproberead_pageto_markdownEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Turn documents into structured data: parse, extract, classify, split, and fill PDF forms.
Composable APIs for document extraction, image transformation, and document & sheet generation.
High-fidelity PDF to structured Markdown conversion and document field extraction.
Convert and compress PDFs and images, redact personal data, and run text and data utilities.
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
