Which integrations are available for this server?

Enables LangChain agents to index and query local documents using the PageIndex tree-based RAG framework. Allows integration with OpenAI Agents SDK to index and query local documents via a local LLM endpoint.

How do I use pageindex-local-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pageindex-local-mcp search my notes for machine learning topics" 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.

pageindex-local-mcp

by jamesbubenik

Overview Schema Related Servers Score Discussions

TypeScript

Local

pageindex-local-mcp

A local-first MCP (Model Context Protocol) server for PageIndex — the vectorless, reasoning-based RAG framework.

This server lets local AI agents (Claude Desktop, Cursor, Claude Code, Cline, Continue, OpenAI Agents SDK, LangChain, or any MCP-compatible client) index and query local PDF and Markdown documents through a self-hosted PageIndex installation, without requiring any PageIndex cloud API key.

Security Warning: This MCP server exposes local file indexing and tree-query capabilities to MCP clients. Only connect trusted clients. Review PAGEINDEX_ALLOWED_ROOTS before deploying in shared environments.

What This Project Does

Wraps a locally installed PageIndex repository and exposes its capabilities as MCP tools.
Indexes local PDF and Markdown files by calling run_pageindex.py from the PageIndex repo.
Builds and stores a hierarchical PageIndex tree structure for each document.
Performs vectorless, reasoning-based document search over those trees using a local OpenAI-compatible LLM endpoint (LM Studio, Ollama, vLLM, etc.).
Returns traceable results: document ID, node ID, title, summary, page/line range, reasoning path.
Maintains a local document registry with full metadata.

Related MCP server: PageIndex MCP

What This Project Does Not Do

Does not call https://api.pageindex.ai or any PageIndex cloud API.
Does not require a PAGEINDEX_API_KEY.
Does not use vector databases or embeddings.
Does not provide a web UI.
Does not perform cloud OCR. Local PDF parsing quality depends on your PageIndex installation and the underlying Python PDF library (PyPDF2). Complex scanned PDFs may parse poorly compared to the cloud pipeline.

How It Differs from the Official PageIndex MCP

Feature	Official pageindex-mcp	This project
Backend	PageIndex Cloud API	Local PageIndex repo
API key required	Yes	No
Runs locally	No	Yes
Vector DB	No (tree-based)	No (tree-based)
LLM for indexing	Cloud models	Configurable local/remote
LLM for querying	Cloud models	Local OpenAI-compatible endpoint
OCR quality	Cloud (best)	Local (depends on PageIndex/PyPDF2)

Prerequisites

Node.js 18+ (for this MCP server)
Python 3.9+ (for the PageIndex repo)
A local clone of VectifyAI/PageIndex with dependencies installed
A local OpenAI-compatible LLM endpoint (LM Studio, Ollama, vLLM) — required for both indexing (if PageIndex is configured to use it) and querying

1. Install the Local PageIndex Repository

git clone https://github.com/VectifyAI/PageIndex.git
cd PageIndex
pip install -r requirements.txt

PageIndex needs an LLM to generate tree structures. Configure it to use your local endpoint by editing pageindex/config.yaml:

model: local-model           # must match what your local server loads

Or set the model via the --model argument at indexing time.

Note: PageIndex's indexing currently calls LLM APIs. Point its config at your local endpoint (LM Studio, Ollama, vLLM) so no internet calls are made during indexing.

2. Install the MCP Server

git clone https://github.com/jamesbubenik/pageindex-local-mcp.git
cd pageindex-local-mcp
npm install
npm run build

3. Configure Environment Variables

Copy the example and edit:

cp examples/sample.env .env
# or: cp .env.example .env

Edit .env:

PAGEINDEX_REPO_PATH=/home/user/PageIndex
PAGEINDEX_PYTHON=python3
PAGEINDEX_WORKSPACE=/home/user/.pageindex-local-mcp
PAGEINDEX_LLM_BASE_URL=http://127.0.0.1:1234/v1
PAGEINDEX_LLM_API_KEY=lm-studio
PAGEINDEX_MODEL=local-model

All Configuration Options

Variable	Required	Default	Description
`PAGEINDEX_REPO_PATH`	Yes	—	Absolute path to cloned PageIndex repo
`PAGEINDEX_PYTHON`	No	`python3`	Python executable with PageIndex deps
`PAGEINDEX_WORKSPACE`	No	`~/.pageindex-local-mcp`	Where the MCP server stores artifacts
`PAGEINDEX_MODEL`	No	`local-model`	Default model name for indexing/querying
`PAGEINDEX_LLM_BASE_URL`	No	`http://127.0.0.1:1234/v1`	OpenAI-compatible endpoint for queries
`PAGEINDEX_LLM_API_KEY`	No	`local`	API key (any non-empty value for local servers)
`PAGEINDEX_LLM_TIMEOUT_MS`	No	`120000`	LLM request timeout (ms)
`PAGEINDEX_TOOL_TIMEOUT_MS`	No	`600000`	Max ms for a PageIndex Python subprocess. Raise for large PDFs or slow machines.
`PAGEINDEX_TOC_CHECK_PAGES`	No	`20`	Pages scanned for TOC (PDF only)
`PAGEINDEX_MAX_PAGES_PER_NODE`	No	`10`	Max pages per tree node (PDF only)
`PAGEINDEX_MAX_TOKENS_PER_NODE`	No	`20000`	Max tokens per tree node
`PAGEINDEX_ALLOWED_ROOTS`	No	`""` (all)	Semicolon (Win) or colon (Unix) separated allowed dirs
`PAGEINDEX_REGISTRY_BACKEND`	No	`json`	`json` (supported) or `sqlite` (future)
`PAGEINDEX_LOG_LEVEL`	No	`info`	`debug`, `info`, `warn`, `error`

4. Configure Your MCP Client

Claude Desktop

macOS/Linux — config file: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or ~/.config/Claude/claude_desktop_config.json (Linux)

{
  "mcpServers": {
    "pageindex-local": {
      "command": "node",
      "args": ["/home/user/pageindex-local-mcp/dist/index.js"],
      "env": {
        "PAGEINDEX_REPO_PATH": "/home/user/PageIndex",
        "PAGEINDEX_PYTHON": "python3",
        "PAGEINDEX_WORKSPACE": "/home/user/.pageindex-local-mcp",
        "PAGEINDEX_LLM_BASE_URL": "http://127.0.0.1:1234/v1",
        "PAGEINDEX_LLM_API_KEY": "lm-studio",
        "PAGEINDEX_MODEL": "local-model",
        "PAGEINDEX_ALLOWED_ROOTS": "/home/user/Documents:/home/user/Downloads"
      }
    }
  }
}

Windows — config file: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "pageindex-local": {
      "command": "node",
      "args": ["C:\\Users\\user\\pageindex-local-mcp\\dist\\index.js"],
      "env": {
        "PAGEINDEX_REPO_PATH": "C:\\Users\\user\\PageIndex",
        "PAGEINDEX_PYTHON": "C:\\Users\\user\\miniconda3\\envs\\pageindex\\python.exe",
        "PAGEINDEX_WORKSPACE": "C:\\Users\\user\\.pageindex-local-mcp",
        "PAGEINDEX_LLM_BASE_URL": "http://127.0.0.1:1234/v1",
        "PAGEINDEX_LLM_API_KEY": "lm-studio",
        "PAGEINDEX_MODEL": "local-model",
        "PAGEINDEX_ALLOWED_ROOTS": "C:\\Users\\user\\Documents;C:\\Users\\user\\Downloads"
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "pageindex-local": {
      "command": "node",
      "args": ["/home/user/pageindex-local-mcp/dist/index.js"],
      "env": {
        "PAGEINDEX_REPO_PATH": "/home/user/PageIndex",
        "PAGEINDEX_PYTHON": "python3",
        "PAGEINDEX_WORKSPACE": "/home/user/.pageindex-local-mcp",
        "PAGEINDEX_LLM_BASE_URL": "http://127.0.0.1:1234/v1",
        "PAGEINDEX_LLM_API_KEY": "lm-studio",
        "PAGEINDEX_MODEL": "local-model"
      }
    }
  }
}

Claude Code

Add to your project's .claude/settings.json under mcpServers, using the same format as Cursor above.

LM Studio (as MCP client)

LM Studio 0.3.17+ can act as an MCP host, meaning it can call this server's tools directly from its chat UI — no separate MCP client needed.

Note: This section is about using LM Studio as the MCP client. For using LM Studio as the LLM backend for indexing and querying, see Section 5 below.

Requirements:

LM Studio 0.3.17 or later
A tool-use-capable model loaded in LM Studio (e.g., Mistral Nemo Instruct, Qwen2.5 Instruct, LLaMA 3.1 Instruct, Gemma 3). Pure base models will not invoke tools reliably.

Step 1 — Edit mcp.json

Open LM Studio, switch to the Program tab in the right sidebar, then click Install → Edit mcp.json. This opens the config file in LM Studio's built-in editor.

The file lives at:

macOS / Linux: ~/.lmstudio/mcp.json
Windows: %USERPROFILE%\.lmstudio\mcp.json

Step 2 — Add the server

Paste the following, adjusting paths for your system:

macOS / Linux:

{
  "mcpServers": {
    "pageindex-local": {
      "command": "node",
      "args": ["/home/user/pageindex-local-mcp/dist/index.js"],
      "timeout": 600,
      "env": {
        "PAGEINDEX_REPO_PATH": "/home/user/PageIndex",
        "PAGEINDEX_PYTHON": "python3",
        "PAGEINDEX_WORKSPACE": "/home/user/.pageindex-local-mcp",
        "PAGEINDEX_LLM_BASE_URL": "http://127.0.0.1:1234/v1",
        "PAGEINDEX_LLM_API_KEY": "lm-studio",
        "PAGEINDEX_MODEL": "your-loaded-model-name",
        "PAGEINDEX_TOOL_TIMEOUT_MS": "600000",
        "PAGEINDEX_LOG_LEVEL": "info"
      }
    }
  }
}

Windows:

{
  "mcpServers": {
    "pageindex-local": {
      "command": "node",
      "args": ["C:\\Users\\user\\pageindex-local-mcp\\dist\\index.js"],
      "timeout": 600,
      "env": {
        "PAGEINDEX_REPO_PATH": "C:\\Users\\user\\PageIndex",
        "PAGEINDEX_PYTHON": "C:\\Users\\user\\miniconda3\\envs\\pageindex\\python.exe",
        "PAGEINDEX_WORKSPACE": "C:\\Users\\user\\.pageindex-local-mcp",
        "PAGEINDEX_LLM_BASE_URL": "http://127.0.0.1:1234/v1",
        "PAGEINDEX_LLM_API_KEY": "lm-studio",
        "PAGEINDEX_MODEL": "your-loaded-model-name",
        "PAGEINDEX_TOOL_TIMEOUT_MS": "600000",
        "PAGEINDEX_LOG_LEVEL": "info"
      }
    }
  }
}

Set PAGEINDEX_MODEL to the exact model name shown in LM Studio's server status bar (e.g., mistral-nemo-instruct-2407). Save the file — LM Studio picks up changes immediately.

Timeout configuration — required for large PDFs

Indexing a PDF can take several minutes because PageIndex makes multiple LLM calls. LM Studio's default MCP request timeout is 60 seconds, which is not long enough. You must set two values or you will see MCP error -32001: Request timed out:

Setting	Where	What it does
`"timeout": 600`	`mcp.json` server entry	Tells LM Studio to wait up to 600 seconds (10 min) for a tool response
`PAGEINDEX_TOOL_TIMEOUT_MS=600000`	`env` block or `.env`	Tells the server how long to let the Python subprocess run before killing it

Both values are already included in the example configs above. Make sure they are present in your actual mcp.json — LM Studio does not have a default that is long enough.

The server also sends heartbeat notifications every 5 seconds while indexing or searching. Clients that support resetTimeoutOnProgress (Claude Desktop, Cursor, Claude Code) will reset their timer on each one. LM Studio will additionally receive supplemental log notifications that may reset its connection timer depending on version.

Step 3 — Enable tool use

Go to App Settings → Tools & Integrations and ensure tool calling is enabled. You can allow individual tools once or permanently when the confirmation dialog appears.

Step 4 — Start the LM Studio local server

The MCP server's query engine calls LM Studio's OpenAI-compatible endpoint (http://127.0.0.1:1234/v1) to reason over document trees. Make sure the local server is running: Developer tab → Start Server (default port 1234).

Step 5 — Chat with your documents

Load a tool-capable model, open a new chat, and ask naturally:

Index the file at /home/user/Documents/research-paper.pdf

Search my indexed documents for information about climate feedback loops

List all my indexed documents

When the model decides to call a tool, LM Studio will show a confirmation dialog with the tool name and arguments. Review and approve. Results are returned inline in the chat.

Tip: Run pageindex_local_health first to confirm the server, PageIndex repo, and Python environment are all reachable before attempting to index.

5. LM Studio Setup

Download and install LM Studio.
Load a model (e.g., Mistral 7B Instruct, LLaMA 3, Qwen 2.5).
Start the local server: Server tab → Start Server (default port 1234).

Set:

PAGEINDEX_LLM_BASE_URL=http://127.0.0.1:1234/v1
PAGEINDEX_LLM_API_KEY=lm-studio
PAGEINDEX_MODEL=<model-name-from-lm-studio>

Ollama Setup

ollama serve
ollama pull llama3

PAGEINDEX_LLM_BASE_URL=http://127.0.0.1:11434/v1
PAGEINDEX_LLM_API_KEY=ollama
PAGEINDEX_MODEL=llama3

6. Using the MCP Tools

Check Health

pageindex_local_health

Verifies the PageIndex repo, Python, workspace, and LLM config. Run this first.

Index a PDF

{
  "tool": "pageindex_local_index_document",
  "arguments": {
    "path": "/home/user/Documents/research-paper.pdf",
    "addNodeSummary": true,
    "addNodeId": true,
    "addDocDescription": true
  }
}

Index with node text (larger output, enables source text in search results):

{
  "path": "/home/user/Documents/research-paper.pdf",
  "addNodeText": true
}

Index a Markdown File

{
  "tool": "pageindex_local_index_document",
  "arguments": {
    "path": "/home/user/notes/project-spec.md"
  }
}

List Indexed Documents

{
  "tool": "pageindex_local_list_documents",
  "arguments": { "status": "indexed", "limit": 20 }
}

Get Tree Structure

{
  "tool": "pageindex_local_get_tree",
  "arguments": {
    "documentId": "550e8400-e29b-41d4-a716-446655440000",
    "maxDepth": 3
  }
}

Query (Vectorless Search)

{
  "tool": "pageindex_local_search",
  "arguments": {
    "query": "What are the main conclusions about climate change?",
    "maxResults": 5,
    "includeReasoningPath": true
  }
}

Search across specific documents:

{
  "query": "What is the recommended dosage?",
  "documentIds": ["doc-id-1", "doc-id-2"],
  "includeSourceText": true
}

Remove a Document

{
  "tool": "pageindex_local_remove_document",
  "arguments": {
    "documentId": "550e8400-e29b-41d4-a716-446655440000",
    "deleteFiles": true
  }
}

Re-index a Document

{
  "tool": "pageindex_local_reindex_document",
  "arguments": {
    "documentId": "550e8400-e29b-41d4-a716-446655440000",
    "addNodeText": true
  }
}

7. Workspace Layout

The server stores all artifacts under PAGEINDEX_WORKSPACE:

~/.pageindex-local-mcp/
  registry.json                       ← document registry
  documents/
    <document-id>/
      original/
        source.pdf                    ← copy of original file
      index/
        tree.json                     ← PageIndex tree structure
        metadata.json                 ← indexing metadata
        stdout.log                    ← PageIndex stdout
        stderr.log                    ← PageIndex stderr
      queries/
        <query-id>.json               ← query results (future)

8. Development and Testing

# Type-check only
npm run typecheck

# Run tests
npm test

# Run smoke tests (requires configured .env and PageIndex repo)
npm run smoke:health
npm run smoke:index -- /absolute/path/to/document.pdf
npm run smoke:list
npm run smoke:query -- "What is this document about?"

# Dev mode (runs from TypeScript source, no build needed)
npm run dev

9. Troubleshooting

run_pageindex.py not found Verify PAGEINDEX_REPO_PATH points to the root of the cloned PageIndex repository and that run_pageindex.py exists there.

Python import errors during indexing Make sure the PageIndex Python dependencies are installed in the Python environment pointed to by PAGEINDEX_PYTHON:

pip install -r /path/to/PageIndex/requirements.txt

Tree file not found after indexing PageIndex saves output to <PAGEINDEX_REPO_PATH>/results/<filename>_structure.json. If your version saves elsewhere, check stdout.log in the document workspace for the actual output path and open an issue.

LLM connection failed during search Verify your local LLM server is running and that PAGEINDEX_LLM_BASE_URL is correct. Test manually:

curl http://127.0.0.1:1234/v1/models

File outside allowed roots Add the file's parent directory to PAGEINDEX_ALLOWED_ROOTS in your environment config.

Low-quality indexing results on scanned PDFs PageIndex uses PyPDF2 for local PDF parsing, which does not perform OCR. Scanned PDFs without embedded text will produce poor results. For scanned documents, consider pre-processing with an OCR tool or using the PageIndex cloud service.

MCP error -32001: Request timed out in LM Studio (or other clients)

The timeout is enforced by the MCP client, not this server. LM Studio's default is 60 seconds — not long enough for PDF indexing.

Checklist (do all three):

"timeout": 600 must be present in your mcp.json under the server entry. This raises LM Studio's per-request timeout to 10 minutes. Without this field, LM Studio uses 60 seconds regardless of how fast the server is.
PAGEINDEX_TOOL_TIMEOUT_MS=600000 in the env block (or .env) — keeps the server-side Python subprocess limit in sync.
Restart LM Studio after editing mcp.json — changes are not always picked up without a restart.

The server sends heartbeat notifications every 5 seconds (progress + log) while indexing and searching. If you are still seeing -32001 after adding "timeout": 600, set PAGEINDEX_LOG_LEVEL=debug and check the stderr output to confirm whether hasProgressToken: true appears — if it does, LM Studio is sending progress tokens and the heartbeats are active. If hasProgressToken: false, the heartbeats are log-only and you must rely on the "timeout" field.

MCP server logs All logs go to stderr (not stdout, which is reserved for the MCP protocol). Check your MCP client's stderr console or increase log level:

PAGEINDEX_LOG_LEVEL=debug

10. Security Notes

PAGEINDEX_ALLOWED_ROOTS: When set, only files within these directories can be indexed. Always configure this in shared or multi-user environments.
No shell interpolation: All Python subprocess calls use argument arrays (shell: false). Path arguments are never interpolated into shell strings.
No cloud calls: This server never contacts api.pageindex.ai, chat.pageindex.ai, or any PageIndex cloud endpoint.
Secrets: Never place API keys in document paths or document IDs. All config comes from environment variables.
Trusted clients only: The MCP protocol grants tool invocation to any connected client. Run this server only in trusted local environments.

11. Known Limitations

SQLite registry backend: The sqlite option for PAGEINDEX_REGISTRY_BACKEND is planned but not yet implemented. Use the default json backend.
Concurrent indexing: Only one indexing job should run per server instance at a time. Concurrent calls are not prevented but may produce race conditions in the registry.
Source text extraction: Full source text in search results (includeSourceText: true) only works when the document was indexed with addNodeText: true. Otherwise, results include node summaries only.
Markdown line references: PageIndex uses line numbers (not pages) for Markdown files. Search results will show line ranges instead of page numbers.
Large documents: Indexing very large PDFs may exceed LLM context windows. Adjust maxPagesPerNode and maxTokensPerNode to reduce node size.
Model compatibility: The query engine uses a simple JSON-structured prompt. Some smaller local models may not reliably output valid JSON. Use instruction-tuned models (Mistral Instruct, LLaMA Instruct, Qwen Instruct, etc.).

12. Using with an AI Agent

AGENT_SYSTEM_PROMPT.md contains a ready-to-use system prompt for any AI agent that will drive this MCP server. It covers all 8 tools, every parameter and response field, typical workflows, error handling, and usage constraints.

How to use it:

Copy the full contents of AGENT_SYSTEM_PROMPT.md.
Paste it into your agent's system prompt (or include it as a context file if your framework supports file injection).
The agent will know how to index documents, search them, handle failures, and avoid common mistakes — without needing further instruction.

This is useful when building automated pipelines, custom agents, or assistants that need to interact with local documents through this server.

MCP Tools Reference

Tool	Description
`pageindex_local_health`	Check configuration and connectivity
`pageindex_local_index_document`	Index a local PDF or Markdown file
`pageindex_local_list_documents`	List all registered documents
`pageindex_local_get_document`	Get full metadata for one document
`pageindex_local_get_tree`	Retrieve the PageIndex tree structure
`pageindex_local_search`	Vectorless reasoning-based search
`pageindex_local_remove_document`	Remove a document from the registry
`pageindex_local_reindex_document`	Re-run indexing for an existing document

License

MIT

Available Tools

8 tools

pageindex_local_get_documentC

Return full metadata for one indexed document.

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits beyond the core purpose. It does not mention side effects, required permissions, error conditions, or the structure of 'full metadata'. The description carries the full burden but fails to add meaningful behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (one sentence, 7 words) but too minimal. It is efficient but sacrifices valuable information that would not significantly increase length.

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 a single required parameter, no output schema, and no annotations, the description should explain what 'full metadata' includes, potential error cases, or required permissions. It is incomplete for an agent to use effectively.

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 schema coverage is 0%, meaning the description does not explain the 'documentId' parameter at all. It adds no meaning beyond what is already in the schema, and for a single required parameter, this is insufficient.

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 'Return full metadata for one indexed document' clearly states the action (return) and resource (full metadata for one indexed document). It distinguishes itself from sibling tools like pageindex_local_list_documents (which lists documents) and pageindex_local_search (which searches).

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 provided on when to use this tool vs alternatives such as pageindex_local_search or pageindex_local_list_documents. The description lacks context about prerequisites or scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pageindex_local_get_treeC

Return the PageIndex tree structure for a document, optionally limited by depth.

ParametersJSON Schema

Name	Required	Description	Default
`maxDepth`	No
`documentId`	Yes
`includeSummaries`	No
`includePageRanges`	No

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears full responsibility. It discloses that the tool returns a tree structure, but does not clarify whether it is read-only, if it requires authentication, what destructive effects might occur, or any rate limits. The lack of behavioral detail beyond the core function 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately states the main action. It is front-loaded and contains no filler. However, it could be slightly more structured with separate lines for clarity, but overall it is concise and efficient.

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 4 parameters and no output schema, the description is too sparse. It does not specify what the tree structure looks like, how depth affects the result, or the meanings of the boolean parameters. More details would be necessary for an agent to use it correctly without additional context.

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 input schema has 4 parameters with 0% description coverage, yet the description only mentions the optional depth ('maxDepth'). It fails to explain 'includeSummaries' and 'includePageRanges', which defaults are given in schema but no semantic context. The description adds minimal value beyond what is already in the schema.

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 clearly states it returns the 'PageIndex tree structure for a document', which distinguishes it from sibling tools like get_document (which likely returns a single document) and search. The mention of optional depth limitation adds specificity. However, it could more explicitly contrast with sibling tools.

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 on when to use this tool versus alternatives like pageindex_local_get_document. There is no mention of prerequisites, exclusions, or scenarios. The description only states the action, not the context of use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pageindex_local_healthA

Check whether the local MCP server, PageIndex repo, Python environment, and workspace are configured correctly.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden. It accurately states the tool performs a configuration check, implying no destructive effects. The description is transparent about its non-modifying behavior, though it does not detail the response format or potential failure modes.

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, well-structured sentence that conveys the tool's purpose without any extraneous information. Every word serves a purpose, making it highly efficient for an AI agent to parse.

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?

Given the tool's simplicity (no parameters, no output schema), the description provides sufficient context for an agent to understand its purpose. It could be slightly improved by hinting at the expected return (e.g., 'returns success or failure details'), but it is largely complete for a health-check tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters (0 required, 0 total), so the description does not need to add parameter-level detail. The baseline for zero-parameter tools is 4, and the description appropriately covers the tool's function without needing parameter explanations.

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 uses a clear verb-noun structure ('Check whether ... configured correctly') and specifies the exact resources being verified (local MCP server, PageIndex repo, Python environment, workspace). It unambiguously distinguishes from sibling tools, which all deal with document operations.

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 implicitly suggests using this tool to verify configuration health, but provides no explicit guidance on when to use it vs alternatives, nor when not to use it. Given the sibling context, the purpose is clear, but direct usage recommendations are absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pageindex_local_index_documentC

Add and index a local PDF or Markdown file using the local PageIndex installation. Returns document ID and tree path on success.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Absolute path to .pdf, .md, or .markdown file
`model`	No
`addNodeId`	No
`documentId`	No	Optional stable custom document ID
`ifThinning`	No
`addNodeText`	No
`forceReindex`	No
`tocCheckPages`	No
`addNodeSummary`	No
`copyToWorkspace`	No
`maxPagesPerNode`	No
`maxTokensPerNode`	No
`addDocDescription`	No
`thinningThreshold`	No
`summaryTokenThreshold`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Does not disclose side effects (e.g., overwrites existing index, requires network), error behavior, or idempotency. For a mutation tool with 15 parameters, significant gaps.

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?

Single sentence, clear and front-loaded. No wasted words, but lacks structured breakdown of key parameters or behavior.

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?

No output schema, 15 parameters, no annotations. Description does not explain complex options (e.g., forceReindex, thinningThreshold), default values, or how to use the returned document ID and tree path.

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 only 13% (only path and documentId have descriptions). The description adds no details for the other 13 parameters, leaving the agent without guidance on their meaning or usage.

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?

Clearly states the action (add and index), the resource (local PDF/MD file), the system (local PageIndex), and the return value (document ID and tree path). Distinguishes from sibling tools like search, remove, and reindex.

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 on when to use this tool vs alternatives (e.g., reindex_document, list_documents). Missing prerequisites like file existence or workspace setup.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pageindex_local_list_documentsC

List documents in the local workspace registry.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`status`	No

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only says 'List documents' and does not disclose behavior such as pagination (limit/offset), filtering by status, or what the return format looks like. No annotations exist to compensate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While brief, the description is under-specified for a tool with three parameters and no output schema. It misses critical usage details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should at least hint at return values (e.g., 'returns a list of document metadata'). It does not, and it fails to cover pagination or status filtering behavior.

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 coverage is 0%, and the description adds no meaning to the parameters (limit, offset, status). The description does not explain their function or defaults.

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 'List' and identifies the resource as 'documents in the local workspace registry', clearly distinguishing from siblings like get_document (single), index, or search.

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 on when to use this tool versus alternatives (e.g., search, get_document). Does not specify that it lists all documents with optional filtering and pagination.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pageindex_local_reindex_documentC

Re-run local PageIndex generation for an existing document.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`documentId`	Yes
`addNodeText`	No
`tocCheckPages`	No
`maxPagesPerNode`	No
`maxTokensPerNode`	No

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description does not disclose whether reindexing overwrites or merges, side effects on existing data, or authorization needs. Minimal disclosure beyond basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence, very concise. However, it sacrifices informativeness for brevity; could include key details without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 undocumented parameters, no output schema, and no annotations, the description is severely incomplete. Does not explain return values, parameter roles, or operational context.

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 coverage 0%; description provides no parameter explanations. 6 parameters (model, addNodeText, tocCheckPages, etc.) are undocumented, leaving the agent without semantic guidance.

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 clearly uses verb 'Re-run' and resource 'local PageIndex generation for an existing document', distinguishing it from initial indexing (index_document) and retrieval (get_document). Could specify what 'generation' involves.

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 on when to use this tool vs alternatives like pageindex_local_index_document. No mention of prerequisites (e.g., document must already exist with initial index).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pageindex_local_remove_documentA

Remove a document from the local registry and optionally delete workspace artifacts.

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes
`deleteFiles`	No

TDQS

A3.5/5.0

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 two behaviors: registry removal and optional artifact deletion. However, it does not explain what 'workspace artifacts' are, nor any side effects like permission requirements or reversibility.

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?

Single sentence, 15 words, front-loaded with action. No extraneous information. Highly concise.

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?

Covers the main action and one parameter option. Missing output format, error states, and idempotency details. Given no output schema or annotations, it could provide more context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds meaning to both parameters: documentId is the document to remove, deleteFiles controls artifact deletion. However, it does not explain default values or error handling for missing documents.

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 clearly states the action ('remove a document') and the resource ('local registry'), with an optional additional effect. It distinguishes itself from sibling tools like get, list, or reindex by focusing on removal.

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 explicit guidance on when to use this tool versus alternatives. No mention of when not to use or prerequisites. The description relies on the tool name to imply usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pageindex_local_searchC

Perform vectorless reasoning-based retrieval across locally indexed PageIndex documents using a local LLM.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`query`	Yes
`maxResults`	No
`documentIds`	No
`includeSourceText`	No
`includeReasoningPath`	No

TDQS

C2.7/5.0

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 mentions 'vectorless reasoning-based retrieval' and 'local LLM', offering some behavioral insight, but fails to disclose key traits such as read-only nature, performance implications, required permissions, or any side effects. The description is insufficient for an agent to understand the tool's full operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the primary purpose. However, given the tool's complexity (6 parameters), the conciseness comes at the cost of completeness. It is efficient but could better serve the agent with more structured detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 6 parameters, no output schema, and no annotations. The description covers only the core purpose, leaving the agent without guidance on parameter usage, return values, or error conditions. This is a significant gap for a retrieval tool that likely returns structured results.

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%, meaning no parameter descriptions exist in the schema. The tool description does not compensate: it explains none of the 6 parameters (including 'model', 'maxResults', 'documentIds', etc.). An agent has no information about how to use these parameters effectively.

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 clearly states the tool's action ('perform vectorless reasoning-based retrieval') and resource ('locally indexed PageIndex documents'), distinguishing it from sibling tools that handle operations like indexing, listing, or getting individual documents. The mention of 'using a local LLM' further specifies the method.

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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or exclusions. Without context, an agent cannot differentiate this search tool from other document access tools like 'pageindex_local_get_document' or 'pageindex_local_list_documents'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: get vs list, index vs reindex, health vs search, etc. No overlapping functionality.

Naming Consistency4/5

All tools use the pageindex_local_ prefix and snake_case, with verb_noun pattern for most. The health tool is a minor exception as it's a noun-only verb, but still fits the style.

Tool Count5/5

8 tools is well-scoped for a document indexing server covering CRUD, search, and health checks. Each tool earns its place without redundancy.

Completeness4/5

Covers all core operations: add, list, get, reindex, remove, search, and tree structure. Minor gap might be content retrieval, but the focus is on metadata and indexed search.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
docbase
io.github.krayinc
DocBase MCP server for AI agents
Documentation Access Search Developer Tools
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Keenable Web Search A
ai.keenable.api
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Research & Data Search Web Scraping
23

Related MCP Servers

ragi
RAG Systems Search
SusuTawar
A
license
A
quality
D
maintenance
Local-first RAG indexing and semantic search MCP server. Enables document retrieval and context-aware queries using local embedding models.
Updated 21 days ago (2026-08-13 16:07 UTC)
3
14
MIT
PageIndex MCP
Search Documentation Access
lorenzpfei
F
license
Not graded
quality
C
maintenance
A self-hosted MCP server for PageIndex's vectorless, reasoning-based document retrieval. It ingests PDFs into a hierarchical table of contents using an LLM and serves documents, structure, and page content via MCP tools.
Updated 3 months ago (2026-06-14 09:50 UTC)
pageindex-mcp
RAG Systems Search
ypolosov
A
license
A
quality
D
maintenance
Self-hosted MCP server for Claude Code that implements PageIndex vectorless RAG locally, enabling indexing, navigation, and content extraction of PDF documents without LLM calls during search.
Updated 5 months ago (2026-03-19 20:27 UTC)
5
128
1
MIT
Agentoom Knowledgeofficial
RAG Systems Search
agentoom
A
license
A
quality
B
maintenance
A self-hosted, MIT-licensed MCP server that securely connects private documents and markdown files to LLMs. It provides a lightweight, local-first RAG infrastructure compatible with any MCP-enabled AI client or framework.
Updated 14 days ago (2026-08-20 05:24 UTC)
3
5
MIT

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/jamesbubenik/pageindex-local-mcp'

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

pageindex-local-mcp

What This Project Does

What This Project Does Not Do

How It Differs from the Official PageIndex MCP

Prerequisites

1. Install the Local PageIndex Repository

2. Install the MCP Server

3. Configure Environment Variables

All Configuration Options

4. Configure Your MCP Client

Claude Desktop

Cursor

Claude Code

LM Studio (as MCP client)

5. LM Studio Setup

Ollama Setup

6. Using the MCP Tools

Check Health

Index a PDF

Index a Markdown File

List Indexed Documents

Get Tree Structure

Query (Vectorless Search)

Remove a Document

Re-index a Document

7. Workspace Layout

8. Development and Testing

9. Troubleshooting

10. Security Notes

11. Known Limitations

12. Using with an AI Agent

MCP Tools Reference

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Agentoom Knowledgeofficial

Latest Blog Posts

MCP directory API