2만 개 이상의 고전 철학 및 인문학 저작물에서 추출한 460만 개의 텍스트 청크에 대한 의미론적 검색을 제공합니다. HTTP 기반의 FastMCP를 사용하여 AI 에이전트용으로 구축되었습니다.
모든 텍스트는 퍼블릭 도메인(1928년 이전)이며, Internet Archive(americana, europeanlibraries, gutenberg 컬렉션)에서 가져왔습니다.
철학: 아리스토텔레스, 플라톤, 칸트, 헤겔, 니체, 쇼펜하우어, 데카르트, 스피노자, 로크, 흄, 밀, 비트겐슈타인, 아퀴나스, 아우구스티누스, 라이프니츠, 루소, 볼테르, 마르크스 등 수백 명
주제: 윤리학, 형이상학, 인식론, 논리학, 정치철학, 신학, 스토아학파, 신플라톤주의, 실존주의, 사상사
언어: 영어, 독일어, 라틴어, 프랑스어, 이탈리아어, 그리스어, 러시아어
Related MCP server: Nordic Financial MCP
원격(호스팅):
claude mcp add --transport http alexandria https://alexandria.aidatanorge.no/mcpMCP 설정 사용:
{
"mcpServers": {
"alexandria": {
"type": "http",
"url": "https://alexandria.aidatanorge.no/mcp"
}
}
}search_texts자연어를 사용하여 컬렉션을 검색합니다. 크로스 인코더 리랭킹(cross-encoder reranking)을 포함한 하이브리드 밀집+희소 검색(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 HTTPalexandria 컬렉션이 채워진 Qdrant 인스턴스가 실행 중이어야 합니다.
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.
