Click on "Deploy 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., "@closed-book-mcp Answer this based only on the PDFs provided."
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.
Zero-Hallucination, Closed-Book Retrieval Engine via Model Context Protocol (MCP)
A lightning-fast, local Retrieval-Augmented Generation (RAG) system built on the Model Context Protocol (MCP). ClosedBook enforces authoritative, ground-truth retrieval over your local documents (PDFs, manuals, SOPs, study materials) using Hybrid Search (Dense Semantic + BM25Okapi)—completely cutting out hallucinations and overriding unverified model assumptions.
This software is provided for educational, research, and audit purposes only. The creator assumes no responsibility for misuse of this software, including academic dishonesty or unauthorized use during proctored examinations. Always use responsibly.
Hybrid Search Architecture: Combines BAAI/bge-small-en-v1.5 (semantic understanding) with BM25Okapi (exact keyword matching) to catch tricky legal or technical phrasing.
Strict Closed-Book Mode: Forces the AI to rely entirely on the provided PDFs, ignoring conflicting pretrained knowledge (perfect for exams where the textbook has specific/outdated answers).
100% Local Privacy: Runs embedding and vector searches locally on your CPU using faiss-cpu. No cloud API required.
Agent Integration: Plugs directly into the Antigravity AI agent framework or any MCP-compatible client.
Related MCP server: PDF RAG MCP Server
Before you begin, ensure you have met the following requirements:
You have installed Python 3.12+.
You have installed uv (an extremely fast Python package installer and resolver).
Clone the repository, navigate to the folder, and run:
uv syncPlace your exam study materials (PDFs) into the resources/ directory.
mkdir -p resources
# copy your PDFs here (e.g., cp ~/Downloads/lecture_slides.pdf resources/)Run the ingestion script to chunk your PDFs and generate the vector embeddings.
uv run ingest.pyOn the first run, it will automatically download a ~130MB embedding model from Hugging Face.
Open your Antigravity MCP configuration file (typically ~/.gemini/config/mcp_config.json) and add this server block. Make sure to update the absolute path to point to your cloned repository:
{
"mcpServers": {
"mcp_closed_book": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/ExamMCP",
"run",
"server.py"
]
}
}
}Once the MCP server is configured and your AI Agent is restarted, it will automatically detect the rules in GEMINI.md.
Simply batch paste your multiple-choice questions into the chat:
1. According to the act, no suit or prosecution shall lie against whom?
A) The contractor
B) Any person acting in good faith
C) The court
D) The victimThe AI will run parallel background searches against your PDF index and immediately output the correct option based only on the text.
If you are forking this repo for your own exams, here is what you need to change:
The PDFs (resources/): Delete the existing PDFs and replace them with your own study guides, lecture slides, or textbooks.
Chunking Size (ingest.py): By default, the system uses 1000-character chunks with a 200-character overlap. If your exam requires extreme precision (like math formulas), you may want to decrease chunk size.
The System Prompt (GEMINI.md): The root GEMINI.md file contains the strict rules for the AI. If your exam requires essay-style answers instead of Multiple Choice (MCQ), edit GEMINI.md and change the instructions to output detailed paragraphs instead of just "Option A".
Rebuild the Index: Whenever you change your PDFs, you must run uv run ingest.py again!
Contributions, issues, and feature requests are welcome! Feel free to check the issues page.
This project is licensed under the MIT License - see the LICENSE file for details.
Search the authoritative study materials using Hybrid Search. The returned content comes directly from the user's PDFs. This is the primary knowledge retrieval tool for closed-book questions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that it performs a search over user PDFs and returns content directly from them, which is the core behavior. It does not mention any side effects, permissions, or edge cases, but for a search tool this is adequate.
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?
Three concise sentences with the main action front-loaded. No fluff; each 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?
Given the tool's simplicity (2 params, output schema exists), the description covers the essential purpose and source. It lacks detail on result format or pagination, but the output schema likely covers that. It adequately enables an agent to call it correctly.
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 either parameter. The names 'query' and 'top_k' are self-explanatory, but the description adds no additional semantics beyond the schema, failing to compensate for the low coverage.
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 ('Search'), resource ('authoritative study materials'), and method ('Hybrid Search'), and clarifies the source (user's PDFs). Distinguishes from siblings by positioning itself as the primary retrieval tool for closed-book questions.
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?
Explicitly identifies its role as the primary knowledge retrieval tool for closed-book questions, giving clear context for when to use it. Does not explicitly contrast with siblings, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all indexed PDFs and their page counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only says 'Return', leaving side effects, permissions, and potential limitations unstated.
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?
A single, focused sentence with no unnecessary words or repetition.
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?
Adequate for a simple list operation, though it does not specify output format or error behavior, which are not critical here.
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?
No parameters exist, so the description needs no parameter details; the output scope is clear 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?
Clearly states the tool returns all indexed PDFs and their page counts; this is distinct from sibling tools like search and page reading.
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?
Implicitly suggests use when a full listing is needed, but does not explicitly contrast with closed_book_search or read_document_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the complete extracted text of a specific page from a document.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| document | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is a read (returns text) but does not mention edge cases (e.g., invalid page, unindexed document) or any implicit side effects. For a simple read tool, this is minimally transparent but not rich in behavioral detail.
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, front-loaded sentence that states the action and outcome with zero filler. It is efficient and immediately informative.
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?
The tool is simple but the description omits critical context: it does not mention that the document must be indexed (as suggested by the sibling list_indexed_documents), nor does it state the page numbering convention. Without this, an agent might attempt to read an unindexed document or misinterpret page numbers, leading to errors.
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 parameter meaning. It only implies that 'document' identifies a document and 'page' specifies a page number, but does not clarify page indexing (0- or 1-based), expected document ID format, or constraints. This is insufficient given the lack of schema descriptions.
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 specific action ('Return'), the resource ('complete extracted text of a specific page'), and the target ('document'). It clearly differentiates from siblings: closed_book_search (search) and list_indexed_documents (list), so an agent can distinguish without ambiguity.
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 provides no guidance on when to use this tool versus closed_book_search or list_indexed_documents. It does not mention that the document must already be indexed or that this tool is for retrieving raw page text rather than searching. An agent is left to infer usage from the tool name.
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.
v0.1.0closed_book_searchlist_indexed_documentsread_document_pageScored across 3 tools
Each tool has a clear, non-overlapping purpose: search across documents, read a specific page, and list available documents. There is no ambiguity about which tool to use for a given task.
All tool names follow a consistent verb_noun pattern (closed_book_search, read_document_page, list_indexed_documents) using lowercase with underscores. The naming is uniform and predictable.
With exactly three tools, the server is well-scoped for its purpose of closed-book document retrieval. Each tool serves a distinct necessary function without redundancy or bloat.
The tool set covers the full workflow: discover available documents, search their contents, and read specific pages. This is sufficient for the stated domain of closed-book question answering over PDFs.
Search your knowledge bases from any AI assistant using hybrid RAG.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Query your own PDFs and documents from any MCP client. Every answer cites the page it came from.
Parse, extract, split, and ask over digital PDFs (text layer, no OCR) from Cursor and Claude.
