The Alexandria MCP server provides semantic search over 4.6 million text chunks from 20,000+ classical philosophy and humanities works (sourced from the Internet Archive).
search_texts: Natural language semantic search using hybrid dense+sparse retrieval with cross-encoder reranking. Filter by author (e.g., Kant, Nietzsche, Plato), language (eng, ger, lat, fre, ita, gre, rus), and result limit (up to 20). Returns ranked excerpts with metadata: title, creator, date, language, subject, and relevance scores.
get_book_list: Browse and filter the collection by author, subject (e.g., ethics, logic, metaphysics), or language. Returns book metadata including title, creator, date, Archive.org identifier, and chunk count (up to 100 results).
ping: Health check to confirm the server is responsive.
Prompts: Pre-built prompts for philosopher deep-dives, topic exploration across multiple thinkers, and side-by-side philosopher comparisons.
Provides access to a collection of 4.6 million text chunks from 20,000+ classical philosophy and humanities works sourced from Internet Archive, enabling semantic search across authors, topics, and languages.
Semantic search over 4.6 million text chunks from 20,000+ classical philosophy and humanities works. Built for AI agents using FastMCP over HTTP.
All texts are public domain (pre-1928), sourced from Internet Archive (americana, europeanlibraries, gutenberg collections).
Philosophy: Aristotle, Plato, Kant, Hegel, Nietzsche, Schopenhauer, Descartes, Spinoza, Locke, Hume, Mill, Wittgenstein, Aquinas, Augustine, Leibniz, Rousseau, Voltaire, Marx, and hundreds more
Topics: Ethics, metaphysics, epistemology, logic, political philosophy, theology, stoicism, neoplatonism, existentialism, history of ideas
Languages: English, German, Latin, French, Italian, Greek, Russian
Related MCP server: OpenEnded Philosophy MCP Server
Remote (hosted):
claude mcp add --transport http alexandria https://alexandria.aidatanorge.no/mcpVia MCP config:
{
"mcpServers": {
"alexandria": {
"type": "http",
"url": "https://alexandria.aidatanorge.no/mcp"
}
}
}search_textsSearch the collection using natural language. Uses hybrid dense+sparse retrieval with cross-encoder reranking.
Parameter | Type | Description |
| string | What you are looking for |
| string | Optional filter by author/creator, e.g. |
| string | Optional language filter: |
| int | Number of results (default 5, max 20) |
Example queries:
"Nietzsche will to power eternal recurrence"
"Kantian categorical imperative duty"
"Platonic theory of forms and the Good"
"Stoic virtue and the sage"
"Hegel dialectics spirit history"
Each result includes: title, creator, date, language, subject, text (chunk), rerank_score, vector_score.
curl example:
curl -X POST https://alexandria.aidatanorge.no/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search_texts",
"arguments": {
"query": "Kantian categorical imperative duty ethics",
"author": "Kant",
"limit": 3
}
}
}'get_book_listList books in the collection filtered by author, subject or language.
Parameter | Type | Description |
| string | Filter by author/creator, e.g. |
| string | Filter by subject keyword, e.g. |
| string | Filter by language code: |
| int | Max books to return (default 20, max 100) |
curl example:
curl -X POST https://alexandria.aidatanorge.no/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "get_book_list",
"arguments": {"author": "Plato", "language": "eng"}
}
}'pingConnectivity test.
philosopher_analysis(philosopher) — deep dive into a philosopher's key ideas
topic_exploration(topic) — explore a topic across multiple thinkers
compare_philosophers(philosopher_a, philosopher_b, topic) — compare two philosophers on a specific topic
Archive.org (13,000+ books)
↓
Text extraction + chunking
↓
Qdrant (4.6M vectors)
↓
Hybrid search: intfloat/multilingual-e5-large (dense) + Qdrant/bm25 (sparse)
↓
Cross-encoder reranking: mmarco-mMiniLMv2-L12-H384-v1
↓
FastMCP 3.2 over HTTPRequires a running Qdrant instance with the alexandria collection populated.
pip install -r requirements.txt
python alexandria_mcp_server.py
# Server starts at http://localhost:8005/mcpEnvironment variables (optional):
QDRANT_HOST=localhost
QDRANT_PORT=6333
MCP_PORT=8005MIT
List books in the Alexandria collection, optionally filtered by author, subject or language.
Returns unique books (one entry per Archive.org identifier) with metadata. At least one filter parameter is recommended — without filters, results are arbitrary.
Args: author: Filter by author/creator name, e.g. 'Kant', 'Nietzsche', 'Plato'. Case-insensitive substring match against the creator field. subject: Filter by subject keyword, e.g. 'ethics', 'logic', 'metaphysics'. Case-insensitive substring match against the subject field. language: Filter by language code, e.g. 'eng', 'ger', 'lat', 'fre', 'gre', 'rus'. limit: Maximum number of distinct books to return (default 20, max 100).
Returns: List of books with title, creator, date, language, subject, identifier and total_chunks.
| Name | Required | Description | Default |
|---|---|---|---|
| author | No | Filter by author/creator name, e.g. 'Kant', 'Nietzsche', 'Plato'. Case-insensitive substring match. | |
| subject | No | Filter by subject keyword, e.g. 'ethics', 'logic', 'metaphysics'. Case-insensitive substring match. | |
| language | No | Filter by language code: 'eng', 'ger', 'lat', 'fre', 'ita', 'gre', 'rus' | |
| limit | No | Maximum number of distinct books to return (default 20, max 100) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, but the description adds important behavior: 'Returns unique books (one entry per Archive.org identifier)' and 'without filters, results are arbitrary'. This goes beyond annotations and provides useful context.
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 well-structured: a brief summary followed by a parameter list and return description. Every sentence is informative, and it is front-loaded with the core function.
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 description covers the purpose, all parameters, and return fields. Given the presence of an output schema and the tool's simplicity, the description is complete and leaves no obvious gaps.
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 coverage is 100%, so the description's parameter details are largely redundant, but it adds helpful examples (e.g., 'Kant', 'ethics', 'eng') and clarifies case-insensitive substring matching. This adds moderate 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 clearly states 'List books in the Alexandria collection, optionally filtered by author, subject or language.' This is specific, with a clear verb and resource. It distinguishes from sibling tools like search_texts by focusing on metadata listing.
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 recommends using at least one filter to avoid arbitrary results. However, it does not explicitly compare to the sibling tool search_texts, leaving some ambiguity about when to use which. Still, the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simple connectivity test. Returns a greeting to confirm the server is running.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name to greet | world |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it returns a greeting and confirms the server is running, which provides additional behavioral context beyond the annotation.
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 sentence that is concise, front-loaded, and contains no redundant information. Every word contributes to understanding.
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 tool with 1 optional parameter, annotations, and an output schema, the description is complete enough. It covers the purpose, behavior, and usage context without missing critical information.
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 100%, with the parameter 'name' already described as 'Name to greet' with a default. The tool description does not add any further parameter semantics beyond the schema, so baseline score of 3 applies.
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?
Description clearly states the tool is a 'Simple connectivity test' that 'Returns a greeting to confirm the server is running.' This is a specific verb+resource combination and distinguishes it from sibling tools like get_book_list and search_texts.
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 when to use (to test connectivity) but does not explicitly state when not to use or provide alternatives. However, given the simplicity and clear distinction from sibling tools, the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 4.6 million classical philosophy and humanities texts from Archive.org.
The collection contains public domain books (pre-1928) covering:
Philosophy: Aristotle, Plato, Kant, Hegel, Nietzsche, Schopenhauer, Descartes, Spinoza, Locke, Hume, Mill, Wittgenstein, Aquinas and many more
Ethics, metaphysics, epistemology, logic, political philosophy
Sacred and religious texts, stoicism, neoplatonism, existentialism
Classical literature, history of ideas, social theory
Sources: Internet Archive (americana, europeanlibraries, gutenberg)
Texts are in original languages — primarily English, German, Latin, French, Italian, Greek, Russian. Queries in any language work due to multilingual embeddings.
Args: query: What you are looking for, e.g. 'Nietzsche will to power eternal recurrence', 'Kantian categorical imperative duty ethics', 'Platonic theory of forms and the Good', 'Stoic virtue and the sage', 'Aristotle eudaimonia flourishing', 'Hegel dialectics spirit history', 'free will determinism compatibilism' author: Optional — filter results to a specific author/creator, e.g. 'Kant', 'Nietzsche', 'Aristotle'. Case-insensitive substring match. language: Optional — filter by language code, e.g. 'eng', 'ger', 'lat', 'fre', 'ita', 'gre', 'rus' limit: Number of results after reranking (default 5, max 20)
Returns: List of relevant text excerpts with metadata, reranked by relevance. Each result includes rerank_score, vector_score, title, creator, date, language, subject and the full text chunk.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you are looking for, e.g. 'Nietzsche will to power', 'Kantian categorical imperative', 'Platonic theory of forms', 'Stoic virtue and the sage' | |
| author | No | Filter results to a specific author/creator, e.g. 'Kant', 'Nietzsche', 'Aristotle'. Case-insensitive substring match. | |
| language | No | Filter by language code: 'eng', 'ger', 'lat', 'fre', 'ita', 'gre', 'rus' | |
| limit | No | Number of results after reranking (default 5, max 20) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations (readOnlyHint, openWorldHint): it specifies the collection scope, multilingual support, reranking behavior, and result structure. No contradictions 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 well-structured with bullet points and sections, but it is somewhat lengthy. Every sentence contributes value, and the main purpose is front-loaded.
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 has 4 parameters and an output schema, the description is comprehensive: it covers the collection size, languages, parameter examples, and return format. It leaves no important gaps.
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 100%, so the baseline is 3. The description repeats some parameter info but adds value with examples and additional details (e.g., author substring matching, language codes).
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 explicitly states the tool's purpose: searching '4.6 million classical philosophy and humanities texts from Archive.org.' It uses a specific verb ('Search') and resource, and clearly distinguishes from siblings (get_book_list, ping).
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 context on when to use the tool (searching philosophy texts) and includes example queries. It does not explicitly state when not to use it, but the context is clear and implies usage scenarios.
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.
v1.0.3get_book_listpingsearch_textsScored across 3 tools
ping is clearly a health check, while search_texts and get_book_list serve distinct purposes: one returns text excerpts, the other lists book metadata. The overlap is minimal and the descriptions clearly differentiate them.
All tools use lowercase with underscores and follow a verb-based pattern (ping, search_texts, get_book_list). The pattern is consistent enough, though the noun structure varies slightly.
With 3 tools, the server is minimal but well-scoped for its search-focused purpose. ping is a standard utility, and the two search-related tools cover the core functionality without excess.
The server supports searching and listing books, but lacks operations like fetching a full text by identifier or retrieving detailed metadata for a single book. This leaves notable gaps for a library-like service.
Search 15K rare pre-modern texts translated to English: philosophy, religion, science, literature.
Complete classical & world literature — search + cite exact passages, facing sources, 50+ languages.
Semantic quote search with 600K quotes. Find quotes by meaning, verify attributions.
Search a billion+ documents — papers, books, code, legal cases, forums, Wikipedia, and more.
