Семантический поиск по 4,6 миллионам текстовых фрагментов из более чем 20 000 произведений классической философии и гуманитарных наук. Создан для ИИ-агентов с использованием FastMCP по протоколу HTTP.
Все тексты являются общественным достоянием (до 1928 года) и получены из Internet Archive (коллекции americana, europeanlibraries, gutenberg).
Философия: Аристотель, Платон, Кант, Гегель, Ницше, Шопенгауэр, Декарт, Спиноза, Локк, Юм, Милль, Витгенштейн, Аквинский, Августин, Лейбниц, Руссо, Вольтер, Маркс и сотни других.
Темы: Этика, метафизика, эпистемология, логика, политическая философия, теология, стоицизм, неоплатонизм, экзистенциализм, история идей.
Языки: Английский, немецкий, латынь, французский, итальянский, греческий, русский.
Related MCP server: Nordic Financial MCP
Удаленно (хостинг):
claude mcp add --transport http alexandria https://alexandria.aidatanorge.no/mcpЧерез конфигурацию MCP:
{
"mcpServers": {
"alexandria": {
"type": "http",
"url": "https://alexandria.aidatanorge.no/mcp"
}
}
}search_textsПоиск по коллекции с использованием естественного языка. Использует гибридный плотный+разреженный поиск (dense+sparse retrieval) с переранжированием через кросс-энкодер.
Параметр | Тип | Описание |
| string | Что вы ищете |
| string | Опциональный фильтр языка: |
| int | Количество результатов (по умолчанию 5, максимум 20) |
Примеры запросов:
"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"
Каждый результат включает: title, creator, date, language, subject, text (фрагмент), rerank_score, vector_score.
pingПроверка соединения.
philosopher_analysis(philosopher) — глубокое погружение в ключевые идеи философа
topic_exploration(topic) — исследование темы через труды различных мыслителей
compare_philosophers(philosopher_a, philosopher_b, 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 HTTPТребуется запущенный экземпляр Qdrant с заполненной коллекцией alexandria.
pip install -r requirements.txt
python alexandria_mcp_server.py
# Server starts at http://localhost:8005/mcpПеременные окружения (опционально):
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.
