This MCP server connects AI assistants to the ETH Library Zurich's catalogue of over 30 million resources, enabling bibliographic search and discovery across books, archives, maps, images, and more.
Comprehensive full-text search across 30M+ resources with flexible queries: field filters (any, title, creator, sub), operators (contains, exact, begins_with), boolean logic (AND/OR/NOT), wildcards, language and type filters, open-access filtering, sorting (rank, title, author, date), and pagination.
Retrieve full resource metadata by MMS-ID, including optional availability/loan status.
Search within specific archives: University Archives, Max Frisch Archive, Thomas Mann Archive, Graphische Sammlung, and Bildarchiv/E-Pics.
Browse by resource type: books, journals, articles, maps, images, archival materials, scores, databases, audios, videos.
Education-focused search with curated workflows for pedagogy and school history topics.
Server overview (eth_library_info) listing all available resource types and archives.
Built-in prompts for guided general research and education-research workflows.
Resource endpoints to access structured lists of archives and resource types.
Person search (currently non-functional due to API issue BUG-02).
Read-only operations: all tools perform HTTP GET requests, no data modification.
Dual transport: works over stdio or Streamable HTTP/SSE for flexible deployment.
Enriches person records with linked data from Wikidata for enhanced person search results.
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., "@eth-library-mcp Search the Max Frisch archive for manuscripts."
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.
🇨🇭 Part of the Swiss Public Data MCP Portfolio
🌐 English | Deutsch
MCP server giving AI models direct access to 30M+ resources at ETH Library Zurich – books, maps, images and archival material.
eth-library-mcp connects AI assistants like Claude to the largest natural-science library in Switzerland. It exposes full-text search, archive-level queries and resource-type filtering via the ETH Library's Discovery API – all through a single, standardised MCP interface.
6 Tools · 1 API · 2 Resources · 2 Prompts
MCP Protocol Version: 2026-07-28 (via mcp[cli]>=2.0.0,<3).
BUG-02 is resolved — by removing the tool.
eth_search_personswas documented as "currently non-functional, correct URL to be verified". It has now been verified, and there is no correct URL: the Persons API is gone from the gateway, not merely locked. The gateway routes before it checks the API key, so an existing route answers401and a missing one answers404—/discovery/v1/resourcesgives 401, every/persons/v1/*path gives 404, and so does a deliberately invented Discovery path used as a control. Offering a capability that cannot exist is the same mistake as returning an empty result, only louder. The measurement is recorded and dated intests/fixtures/api_routes.json.
Anchor demo query: "Find historical documents about Zurich school history in the ETH Library archives."
Related MCP server: swiss-cultural-heritage-mcp
🔍 Full-text search over 30M+ resources with fields, operators, and facets
📖 Resource details – full metadata via MMS-ID
🗂️ Archive search – ETH University Archives, Max Frisch, Thomas Mann, Graphische Sammlung, Bildarchiv
🏷️ Resource type filter – books, maps, images, archival material and more
🎓 Education search – curated workflow optimised for pedagogy and school history
📋 Server overview – all resource types and archives at a glance
🗣️ Built-in prompts – structured research and education-research workflows
☁️ Dual transport – stdio for Claude Desktop, Streamable HTTP/SSE for cloud deployment
Python 3.11+
A free API key from developer.library.ethz.ch
# Clone the repository
git clone https://github.com/malkreide/eth-library-mcp.git
cd eth-library-mcp
# Install
pip install -e .
# Or with uv (recommended)
uv pip install -e .# Set the API key
export ETH_LIBRARY_API_KEY=your_key_here # macOS / Linux
# $env:ETH_LIBRARY_API_KEY = "your_key_here" # Windows (PowerShell)
# Start the server (stdio mode for Claude Desktop)
python -m eth_library_mcp.serverWithout an API key the server returns a helpful error message with the registration link – no crashes.
Try it immediately in Claude Desktop:
"Find books about Swiss education history in the ETH Library." "Search the Max Frisch archive for manuscripts about Zurich."
→ More use cases by audience →
Variable | Description | Required |
| API key for Discovery & Persons API | ✅ |
| Log level ( | — |
| Comma-separated CORS allow-origins for | — |
| Comma-separated hostnames this server is reachable under. Required for a non-loopback bind ( | — |
{
"mcpServers": {
"eth-library": {
"command": "python",
"args": ["-m", "eth_library_mcp.server"],
"env": {
"ETH_LIBRARY_API_KEY": "your_key_here"
}
}
}
}Config file locations:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
For use via claude.ai in the browser (e.g. on managed workstations without local software):
python -m eth_library_mcp.server --http --port 8000The HTTP transport binds to 127.0.0.1 by default. To expose it on another
interface, pass --host explicitly:
# Only behind a reverse-proxy / firewall that terminates TLS and enforces auth.
python -m eth_library_mcp.server --http --host 0.0.0.0 --port 8000⚠️ Do not bind to
0.0.0.0without a reverse proxy. The server has no built-in auth, rate-limiting or TLS — any LAN neighbour could call your tools.
💡 "stdio for the developer laptop, HTTP for the browser — behind a proxy."
Tool | Description |
| Full-text search over 30M+ resources with fields, operators, facets |
| Full metadata for a specific resource via MMS-ID |
| Search within a specific archive (University Archives, Max Frisch, Thomas Mann, etc.) |
| Filter by resource type (books, maps, images, archival material, etc.) |
| Curated search for education topics (pedagogy, school history, etc.) |
Tool | Description |
Tool | Description |
| Server overview: all types and archives at a glance |
Item | Type | Description |
| Resource | All available resource types |
| Resource | All available archives and collections |
| Prompt | Structured research workflow |
| Prompt | Education topics workflow (Schulamt-optimised) |
The Discovery API uses structured queries:
field,operator,valueField | Meaning |
| All fields (recommended for starters) |
| Title only |
| Author / creator |
| Subject headings / topics |
Operator | Meaning |
| Term is present |
| Exact match |
| Starts with |
Examples:
any,contains,Volksschule Zürich
title,contains,Pädagogik
creator,exact,Einstein Albert
sub,contains,Bildungsforschung
title,contains,Schule;sub,contains,GeschichteIdentifier | Description |
| Institutional memory of ETH Zurich |
| Estate of Swiss author Max Frisch |
| Letters and documents of Thomas Mann |
| Prints, drawings, graphic works |
| Science/technology history, Swissair (E-Pics) |
Query | Tool |
"Find books about Zurich school history" |
|
"What's in the Max Frisch archive?" |
|
"Find historical maps of Switzerland" |
|
"Get full metadata for resource ID 991170525863705501" |
|
"Which archives does the ETH Library hold?" |
|
eth-library-mcp/
├── src/
│ └── eth_library_mcp/
│ ├── __init__.py # Package init, version
│ └── server.py # FastMCP server, all tools
├── tests/
│ └── test_server.py # Unit tests
├── CHANGELOG.md
├── CONTRIBUTING.md # Contribution guide (English)
├── CONTRIBUTING.de.md # Contribution guide (German)
├── SECURITY.md # Security posture (English)
├── SECURITY.de.md # Security posture (German)
├── LICENSE
├── README.md # This file (English)
├── README.de.md # German version
├── claude_desktop_config.json # Example Claude Desktop configuration
└── pyproject.toml # Build configurationThis server speaks two protocol eras over the same endpoint. The client's first request on a connection decides which one applies; a later claim from the other era is refused.
Era | Revision | Who reaches it |
|
| What today's clients speak. The server answers with the revision asked for, or with the |
Per-request envelope |
| A request carrying the |
Both revisions are pinned in
tests/test_protocol_version.py and asserted
against the installed SDK, so a Dependabot bump of mcp cannot move either one
silently. The handshake ceiling is measured against a live initialize through
the assembled ASGI stack, not read off a constant name.
Note that the SDK's LATEST_PROTOCOL_VERSION is an alias for the modern
era, not for the handshake era — pinning against it alone would leave the era
that current clients actually negotiate free to drift.
Update policy. When the gate fails, do not edit the constant blindly: read
the spec changelog between the two revisions, verify the server still behaves,
then move the constant, this section, README.de.md and
CHANGELOG.md together.
# Unit tests (no API key required)
PYTHONPATH=src pytest tests/ -m "not live"
# Integration tests (API key required)
# Live checks against the gateway — these need NO API key
PYTHONPATH=src pytest tests/ -m "live"
# Re-record the route census (writes tests/fixtures/PROVENANCE.md)
python scripts/record_fixtures.pyUntil 2026-08-08 this repository had no live tests at all — pytest -m live
collected zero. Nothing in it had ever been held against the source.
The Discovery payloads still cannot be recorded: the API requires a key, and
tests/fixtures/PROVENANCE.md lists them explicitly as NOT RECORDED rather
than giving them a date they never had. What is recordable is the contract the
source gives up without a key — which routes the gateway serves — and that is
exactly what the finding hangs on. The two control_* entries are part of the
measurement, not decoration: without them the recording only proves that someone
got a 404; with them it proves what the gateway distinguishes.
The two live tests need no key and say something anyway: they report if the Persons API comes back (then the tool should return) or if Discovery loses its route (then five tools are affected).
Read-only: All tools perform HTTP GET requests only — no data is written, modified, or deleted.
No personal data: The APIs return bibliographic metadata (titles, authors, subjects, identifiers). No personally identifiable information (PII) is processed or stored by this server.
Authentication: A free API key from developer.library.ethz.ch is required. The key is read from the ETH_LIBRARY_API_KEY environment variable and never logged or transmitted to third parties.
Rate limits: The ETH Library API enforces rate limits per API key. The server enforces a 30-second timeout per request. Use limit and offset parameters conservatively.
Data freshness: Results reflect the ETH Library catalogue at query time. No caching is performed by this server.
Terms of service: Bibliographic metadata is published as Public Domain — free for all uses. API access is subject to the ETH Library Developer Portal terms.
No guarantees: This is a community project, not affiliated with the ETH Library or ETH Zurich. Availability depends on upstream APIs.
Contributions are welcome! See CONTRIBUTING.md (Deutsch) for guidelines.
Read-only, no PII, a single upstream API key, and a fixed egress allow-list of ETH Library endpoints. See SECURITY.md (Deutsch) for the full security posture and accepted-risk decisions.
See CHANGELOG.md
Server code: MIT License — see LICENSE
Bibliographic metadata: Public Domain (no restrictions)
API documentation: developer.library.ethz.ch
Hayal Oezkan · github.com/malkreide
Powered by Model Context Protocol • 1 API • 6 Tools • 2 Resources • 2 Prompts
Run via uv's uvx — no clone or manual install needed. Add to your MCP client config (mcpServers for Claude Desktop, Cursor and Windsurf; use a top-level servers key for VS Code in .vscode/mcp.json):
{
"mcpServers": {
"eth-library-mcp": {
"command": "uvx",
"args": [
"eth-library-mcp"
]
}
}
}Ruft eine einzelne Ressource der ETH-Bibliothek anhand ihrer MMS-ID ab.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so description adds minimal behavioral context beyond the operation type. Consistent 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?
Single sentence, front-loaded with verb and object, no redundancy.
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 retrieval tool with good annotations and schema, description is adequate. Could mention system (Alma) but not essential.
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 descriptions fully cover each parameter with language, ID example, and availability toggle. Tool description adds no extra parameter info.
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 the tool retrieves a single resource from the ETH library using its MMS-ID, which is specific and distinguishes from search or info sibling tools.
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?
No explicit guidance on when to use versus alternatives, but the verb 'abrufen' implies direct retrieval by ID, contrasting with search tools. Missing when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gibt eine Übersicht über den ETH Library MCP Server zurück.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so the safety profile is clear. Description adds basic context (returns overview) but doesn't elaborate on behavior beyond 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?
Single sentence, front-loaded, no wasted words. Appropriately sized for a simple info tool.
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?
Minimal description for a tool with no params and an output schema. Sufficient but could be more informative (e.g., what the overview includes).
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 schema description coverage is 100%. Description doesn't need to add parameter info; baseline 4 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?
The description 'Gibt eine Übersicht über den ETH Library MCP Server zurück.' clearly states the verb (returns) and resource (overview). It distinguishes from sibling search/get tools by being a general info endpoint.
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?
No guidance on when to use this tool versus siblings. Implicitly it's for server info, but no explicit when/when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Durchsucht ein spezifisches Archiv oder eine Sammlung der ETH-Bibliothek.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. However, the description adds no behavioral context beyond the basic search action, such as pagination, result format, or scope.
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, which is concise, but it is too brief and omits important context like available archives or usage notes. It achieves efficiency at the cost of completeness.
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 complexity (multiple archives, pagination options, and an output schema), the description is inadequate. It does not mention the archive choices, search behavior, or return format, relying entirely on the schema and annotations.
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?
The schema already provides detailed descriptions for all parameters (archive with enum meanings, query format, limit, offset). The tool description adds no additional parameter information, so it meets the baseline for high schema 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?
The description clearly states the verb 'Durchsucht' (searches) and the resource 'Archiv oder eine Sammlung der ETH-Bibliothek', distinguishing it from sibling tools that search resources, persons, or education.
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?
No guidance is provided on when to use this tool versus siblings like eth_search_resources or eth_search_by_type. The description does not mention alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sucht Ressourcen eines bestimmten Typs (Karten, Bilder, Archive, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds no behavioral details beyond these, such as data scope, pagination behavior, or authentication needs. With annotations covering safety, the bar is lower, but the description does not provide additional transparency.
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, efficient sentence that front-loads the core purpose. However, it could be slightly more structured (e.g., adding parameter hints) without losing conciseness.
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?
With 5 parameters, an output schema, and 6 sibling tools, the description is too minimal to be complete. It does not explain return values, pagination, or how this search differs from others, leaving the agent with insufficient context.
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?
The description does not mention any of the 5 parameters (resource_type, query, limit, offset, open_access_only). Schema description coverage is 0%, so the description should compensate but fails to add any meaning beyond the schema.
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 the tool searches resources by type (maps, images, archives, etc.), aligning with the tool name. However, it does not differentiate from sibling tools like eth_search_resources or eth_search_archive, which may have overlapping functionality.
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?
No guidance is provided on when to use this tool versus alternatives such as eth_search_resources or eth_search_archive. The description lacks context for tool selection in a multi-search environment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kuratierte Suche nach bildungsrelevanten Ressourcen in der ETH-Bibliothek.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds the nuance of a 'curated' search, but does not disclose other behavioral traits like result ordering, pagination, or potential restrictions.
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 efficiently conveys the tool's purpose with no extraneous words. It is appropriately concise.
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 presence of an output schema and rich annotations, the description is minimally complete. However, it does not mention the expected output format or any additional context like the curated nature's implications, leaving room for improvement.
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?
The description provides no additional parameter information beyond the input schema. However, the schema itself has detailed descriptions for each parameter (topic, limit, resource_type, open_access_only), so the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 the tool's purpose: 'Kuratierte Suche nach bildungsrelevanten Ressourcen' (curated search for education-relevant resources). It specifies the verb 'search' and the resource type (education resources at ETH Library), distinguishing it from sibling tools like 'eth_search_resources' which likely handle general searches.
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 usage for education-related queries but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or prerequisites are mentioned, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sucht Personen in der ETH-Bibliothek Persons API.
⚠ HINWEIS BUG-02: Der Persons-API-Endpunkt (/persons/v1/persons) gibt aktuell HTTP 404 zurück. Die korrekte URL muss via developer.library.ethz.ch verifiziert werden.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint(true), idempotentHint(true), destructiveHint(false). The description adds a specific bug note about the Persons API returning HTTP 404, which is useful behavioral context beyond annotations. No other traits (auth, rate limits) are mentioned, but annotations cover safety adequately.
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 very short (two sentences) and front-loaded with the purpose. The bug warning is important but could be more structured or separated. However, it remains concise with no unnecessary content.
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 has good annotations and a known output schema, but the description lacks information about return values, pagination, or error handling beyond the bug note. For a search tool, it should mention what properties are returned or how to interpret results. The bug notice is important but incomplete overall.
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?
The input schema provides descriptions for both parameters (e.g., 'Anzahl Ergebnisse (1–50)' for limit, and 'Name oder Stichwort zur Personensuche' with examples for query). The tool description adds no additional parameter meaning 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?
The description states 'Sucht Personen in der ETH-Bibliothek Persons API', which clearly indicates the tool searches for persons. The annotations title further clarifies. However, it doesn't differentiate from sibling tools like eth_search_resources or eth_search_archive, leaving ambiguity about when to use this specific person search.
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 alternatives. It only includes a bug warning about a possible HTTP 404, which is operational but not about usage context. No explicit 'when to use' or 'when not to use' statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Durchsucht den Katalog der ETH-Bibliothek mit über 30 Millionen Ressourcen.
Nutzt die Discovery API (api.library.ethz.ch/discovery/v1/resources). Unterstützt Freitextsuche, Feldsuche, Facetten-Filter und Pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so no contradiction. The description adds the API and feature list (full-text, field search, facets, pagination), but does not provide deeper behavioral context like rate limits or return format. Adequate but not exceptional.
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 three short sentences that efficiently convey purpose, underlying API, and supported features. No wordiness or redundancy; each sentence adds distinct value.
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 complexity (multiple parameters, pagination) and presence of an output schema, the description covers the core purpose and features but omits details on error handling, auth, or rate limits. Adequate for a straightforward read-only search tool.
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?
Despite the context signal indicating 0% schema description coverage, the actual input schema includes detailed descriptions for all parameters (e.g., query format with field, operator, value). The description only adds a high-level summary of features, which does not significantly enhance what the schema already provides. 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?
The description clearly states the tool searches the ETH library catalog with over 30 million resources, mentioning the specific API and supported features. This distinguishes it from sibling tools like eth_get_resource (single resource) and eth_search_archive (archive-specific).
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 does not provide explicit guidance on when to use this tool versus alternatives. No 'use this for general search; use eth_search_archive for archives' or similar advice. Usage context is implied but not clarified.
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.3.3eth_get_resourceeth_library_infoeth_search_archiveeth_search_by_typeeth_search_educationeth_search_personseth_search_resourcesScored across 7 tools
Each tool targets a distinct search aspect: info, general resources, specific resource by ID, archive, type, persons, education. There is no ambiguity between them.
All tools use 'eth_' prefix and follow verb_noun pattern except 'eth_library_info' which uses noun_info instead of a verb. Minor inconsistency but overall predictable.
7 tools is well-scoped for a library catalog MCP server, covering essential search and retrieval operations without excess.
The tool set covers general search, specific retrieval, and specialized searches (archive, type, persons, education). Missing features like search by author or date but core workflows are covered.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
AI governance MCP server for EU AI Act compliance and jurisdiction verification
